チームに新しい開発者を追加する方法
私はわずか2人の開発者で構成される小さな会社を経営しています。私たちは、クライアントの1つに非常に大きなアプリケーションを構築しています。このプロジェクトの開発は1.5年続いています。
現在、このクライアントは重要なスポンサーシップを確保しており、このプロジェクトに関連するイベントを開催しています。ですから、今では2か月で期限があり、それを逃すことはできません。
私たちはチームに新しい開発者を加えることを考えています、そして私は彼の統合を助けるために私たちが何ができるか疑問に思っています。
これは状況です：
- ブルックスの法則 -新たな開発者を追加することは逆効果になります。
- アプリケーションは比較的よく設計されていますが、実装はいくつかの点で混沌としています（特に古いコード）。
- 最新のコードのみの単体テストがあります。このプロジェクトが始まったとき、私たちは定期的にテストを実施していませんでした。
- ドキュメントとコメントは不完全です。
- アプリケーションは大きくて複雑です。
- クライアントは、彼のプロジェクトに関するほとんどすべての詳細を、非常に明確で「プログラマーフレンドリー」な方法で書き留めました。
今すぐ人を追加するのは良い考えですか？もしそうなら、新しい開発者がチームに統合するのを助けるために私たちは何ができますか？
編集：
スポンサーは来春のためにインターネットベースのスポーツイベントを企画しています。年の特定の日に開始する必要があります。変更できません。
開発者（私は2人のうちの1人）が行う必要があるのは、
既存のアプリケーションを完成させる（やるべき作業の約25％）。
このイベントの組織に不可欠な新しいモジュールを作成する（行う作業の約75％）。この新しいモジュールは、メインプログラムのAPIを理解しないと開発できません。
正確な時間を推定することはできませんが、危険な状況にあります。
最善の方法は、新しい開発者を火の中に投げ込むことではなく、代わりに、開発者が問題なくジャンプできる機能やバグ修正を切り分けることです。アーキテクチャ全体、要件、コードベースを一度にすべて把握する必要のない作業が必要な領域を見つけます。システムをより早く学習するために、彼または彼女に文書化の作業を依頼するかもしれません。
新しい開発者をチームに追加するのではなく、経験豊富なコンサルタントを2〜3か月間追加して、会社のワークロードの一時的な増加に対処することを検討してください。アイデアは、ほぼゼロの起動時間を処理できる誰かを雇うことですが、同時に、必ずしもチームに最良の追加であるとは限りません。
ワークロードの増加が一時的ではないと思われる場合でも、今はおそらくチームを有機的に成長させるのに最適な時期ではありません。3人目の開発者を追加することは、プロジェクトの期限からのプレッシャーがなくても、チームにとってストレスの多いことです。厳しい締め切りは移行を悪化させるだけです。
トレードオフは、一時的な支援と引き換えに、部外者によって書かれたコードを取得することです。このリスクを軽減するために、両方の人が彼と一緒にすべてのコードレビューを行うようにしてください。彼の単体テストもすべて確認して理解するようにしてください。
今すぐ人を追加するのは良い考えですか？
いいえ。可能な場合は、代わりにクライアントにスコープの縮小について同意してもらいます。
この遅い時間に人を追加すると、重大なリスクが発生し、締め切りを遅らせることはできません（私が理解している限り）。
しないでください。
まだ。
トラディショナルビュー
あなたの質問では、 Mythical Man-Month からBrooksの法則を参照しています。
後期のソフトウェアプロジェクトに人員を追加すると、それが遅れます。
ブルックの法則を無視するには代償が伴います。マルチタスクしないでください。最小実行可能製品（MVP）の配信に焦点を当てます。次に、新しいチームメンバーの採用、リソース調達、トレーニング、および管理に力を注ぎます。
2ヶ月はとても短いです。バーンダウンリストを使用して採用を計画すると、どれだけ時間がかかるかがわかります。
ラリーペイジとセルゲイブリンは、2年間かけてGoogleの初期チームを選びました。従業員番号3の選択も慎重に行う必要があります。
アジャイル、新しいミレニアムビュー
競争は、神話の人月が書かれた時代（1960年代半ば）よりも、今やダイナミックなチーム化を推進しています。 1つの会社での長いキャリアはなくなりました。現在、私たちはプロジェクトと企業の間を頻繁に移行しています。迅速なチームビルディングは成功を生み出します。スローアップは深刻な制限要因です。優れた例は、オープンソースプロジェクト、スタートアップ、およびコンピューターサイエンスコースでのチームプロジェクトの使用の増加から来ています。
潜在的に、アジャイルチームはスケジュールに制約を考慮します。利用可能なリソースに合わせて最適化されているため、遅れることはありません。新しいスタッフの統合はもう1つの制約であり、短期的目標と長期的目標の間のトレードオフと見なされます。アジャイルチームは継続的にコードを統合しているので、なぜ人々もそうしませんか？
新しいスタッフのためのアジャイルチームの技術的および社会的統合は、以下を使用できます。
- 毎日のスクラム
- ペアプログラミング
- リファクタリング
- 不足している単体テストを追加する
- 無駄のないドキュメントの肥大化
- コードレビュー
犠牲の子羊
「 アジャイルソフトウェア開発の組織パターン」 で、James Coplienはグループのダイナミクスと新しいチームメンバーを追加するコストについて説明しています。彼のパターン「犠牲の子羊」は、メンタリングとトレーニングをすべて1人に割り当て、チームの他のメンバーが中断されるのを防ぎます。
これは、実装を検討したい戦略です。
別の戦略は、毎日特定の時間の新規採用者からの質問をカバーする新規採用メンターを割り当てることです。もしあなたがたった一人の男を惜しむことができないならば、おそらく彼は午前または午後に中断することなく働き、午後または午前にそれぞれ質問に答えます。私が参加しているグループには、昨年の夏に10人のインターンがいたため、多くの人がたくさん中断されました。
現在、メンタリングは1人で、主に朝のスクラムの最中と直後（午前8時30分から午前9時15分頃まで、合計）、午後の12時から3時30時まで（午前7時から3時30分まで働いています）午後）。
あなたがブルックの法則に言及したことを心から嬉しく思います。よくできました。別の開発者を追加することの主な問題は、開発者をスピードアップするためのオーバーヘッドと、プロジェクトのどこにいるかについて状態を同期するためのオーバーヘッドです。したがって、3番目の開発者を取得することにした場合は、これを試してみます。
- 新人に最高速度のコストが低く、彼ができるだけ早く進むことができる領域を与えてください。これは、あなたが雇う人と彼らがどんなスキルを持っているかに大きく依存します。
- 同期のオーバーヘッドが少なくなるように、この領域がアプリケーションの他の領域と疎結合されていることを確認してください。激しいDB作業を行うために彼を派遣し、テーブルを再編成することは多すぎるかもしれません。
- 士気を維持するためにできることをしてください。他の人が指摘しているように、新しいチームメンバーを追加することはストレスになる可能性があるため、発泡性飲料への投資が役立つ可能性があります。
ブルックの法則に厳密に従っていると、チームを成長させることはできません。
トリックは、現在のチームであまりにも多くの減速に打たれることなく新しい人をもたらすことです。結局、新しい人はスピードを上げて、こぶを乗り越えることができます。
あなたの場合？私は新しい人にそれらすべての欠けているユニットテストを書くように勧めます。
- これらは、どんなブルックスの減速よりも速くあなたを燃やす回帰エラーに対する保護手段として切実に必要とされています。
- 新しい人はあなたのシステムの根性を学びます。これはちょっとした試練ですが、その出力は本番用コードには含まれないため、リスクはほとんどありません。
- 他のチームメンバーがどれだけの時間を取ることができるかについて、ハードリミットを設定します。たとえば、質問をキューに入れ、期限が切れるまで1日30分だけ他のチームメンバーとやり取りできるようにします。
また、それに直面しましょう：新しい人をもたらすかどうかに関係なく、スコープとクライアントの期待を管理する必要があります。見返りは次のサイクルになります。
エド・ユアドンはブルックの法則について素晴らしいコメントをしました。彼は言った：もちろん、人々を追加することはあなたを遅くするでしょう-しかし、プロジェクトが危険にさらされているとき、経営陣が新しい人々をもたらす唯一の時間です。だから：それらを取り、現在のリリースへの影響を最小限に抑え、パフォーマンスの悪い人をできるだけ早く排除してください。このようにして、時間をかけて強力なチームを構築できます。
元の作業の25％と新しい作業を完了する必要があると言います。これを2か月で行う必要があります-作業の75％を行うのに18か月かかりました。非常に率直に言えば、これはあなたの推定能力がコードに焦点を当てたプログラマにとってほぼ平均的であることを私に示します-つまり、あなたは物事が本当にそうである限り、あなたは物事があなたに約1/2から1/3かかると思います。
Heroicsは、契約した製品を提供することを許可する場合がありますが、それはあなたやあなたの顧客に好意を与えるものではありません。これらの条件下では、それは見掛け倒しでバグに覆われ、煙で走ることになります。
採用に費やす時間も可用性に大きな影響を与えることに注意してください。これは週末だけでできることではなく、適切な人材を見つけるのに時間がかかります。少なくとも数週間は検索、面接などに費やすことを期待してください。あなたとあなたの既存の従業員は、検索中に週に約10時間の生産的な時間を失うことを期待してください。
私の推薦：
顧客と一緒に腰を下ろし、頭の中にいることを説明し、彼と協力して範囲を最小限に減らします。
編集ここで日付を見ただけです。それで、それはどのように終わったのですか？ （3か月前の質問を投稿してくれたArs Technicaに感謝;）
あなたが彼に与えることができる他のプロジェクトに取り組んでいる場合、2人の現在の開発者が役立つかもしれない大きな締め切りの成果物に集中する時間を空けることができます。
調査を検討する方法はいくつかあります。
ドメインの知識を新しい人に渡すことに集中するのが簡単になるように、締め切りが過ぎるまで新しい開発者を雇うことを控えてください。これは、いくつかの点で少し難しいかもしれないので、私の好みです。
新しい開発者を招いて、既存のコードを変更しないドキュメント、単体テスト、およびその他のものに取り組みます。これは、現在の作業負荷への影響を最小限に抑えるために新しい人を連れてくる場合に私が提案するものです。
日付はすでに過ぎていますが、後でこれを読む人にとっては。
考慮すべき重要なことは、この状況のクライアントには、あなたが失うよりもはるかに多くを失うということです。彼らはすでに多くのお金を費やしており、彼らのビジネスを成功または失敗させるかもしれない重要なイベントが近づいています。あなたはすでに彼らのお金を持っています、そして単一のクライアントを失うことはあなたのビジネスを壊すべきではありません。もしそうなら、あなたはひどいプロジェクト管理を超えた他の深刻なビジネス上の問題を抱えています。
あなたの最善の策は、機能の本質的なサブセットを交渉し、それを達成するために残業することです。小さなサブセットを実現できない場合や、そのような状況で残業したくない場合は、おそらくビジネスに参加すべきではありません。これは他のクライアントを保留にすることを意味するかもしれませんが、他のクライアントが3人年相当の時間を支払っていないので、お金がどこにあるかにリソースを置きます。
彼らがスコープを交渉する気がないなら、あなたは失敗するように設定されています。
このプロジェクトを期間内に完全に提供する可能性はありません。これまでに18か月かかったプロジェクトの25％が残っていると思う場合、少なくとも6か月（〜2人の開発者）が残っています。別の人を追加しても、これは大幅に変更されません。
指摘されているように、採用には時間がかかります。私の経験では、最低でも1か月かかります。次にトレーニングを追加すると、時間がなくなります。
これがうまくいったことを願っています。