開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
優れたエンジニアを採用できないワケ | POSTD
あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
