正確な状況は明らかにプロジェクトに非常に固有のものです（開発チーム、管理スタイル、プロセスの成熟度、主題の難易度など）。これをもう少しうまくスコープ付けして、過度の単純化以外のことについて話せるようにするために、あなたの質問をもう一度述べます。
どんな状況下で、もしあれば、遅れて実行しているソフトウェア開発プロジェクトにチームメンバーを追加すると、既存のチームが完了するまで作業を許可した場合と同等の品質レベルで実際の出荷日が短縮されますか？
必要なと思うものがいくつかありますが、これが起こるには十分ではありません（順不同）：
- プロジェクトに追加される提案された個人は以下を持たなければなりません：
- プロジェクトの問題領域を少なくとも合理的に理解している
- プロジェクトの言語と、与えられるタスクに使用する特定の技術に習熟している
- 彼らの習熟度は、既存の最弱メンバーまたは最強メンバーそれぞれよりもはるかに少ないか、またははるかに大きくなければなりません。弱いメンバーは既存のスタッフに三次的な問題を引き起こしますが、力が強すぎる新人は、チームがやったことややっていることが間違っていることでチームを混乱させます。
- 優れたコミュニケーション能力がある
- 意欲が高い（例：突っ込むことなく独立して仕事ができる）
- 既存のチームメンバーには次のものが必要です
- 優れたコミュニケーションスキル
- 優れた時間管理スキル
- プロジェクトリーダー/管理者には次のものが必要です
- 優れた優先順位付けとリソース割り当て能力
- 既存のチームメンバーからの高い敬意
- 優れたコミュニケーションスキル
- プロジェクトには次のものが必要です
- 優れた、完成した、文書化されたソフトウェア設計仕様
- すでに実装されているものの優れたドキュメント
- 明確な責任の塊を切り分けられるようにするモジュール設計
- 必要な欠陥レベルの品質保証のための十分な自動化プロセスには、単体テスト、回帰テスト、自動ビルド展開などが含まれます。
- 現在、チームによって適切に使用されているバグ/機能追跡システム（例：trac、SourceForge、FogBugzなど）。
議論すべき最初の事柄の1つは、出荷日をスリップできるかどうか、機能をカットできるかどうか、および2つの組み合わせによってリリースを満足させることができるかどうかです。既存のスタッフ。多くの場合、投資と同等の価値をもたらさないチームのリソースを大量に消費する機能がいくつかあります。そのため、プロジェクトの優先順位を他よりも真剣に検討してください。
上記の段落の結果が十分でない場合は、上記のリストをご覧ください。スケジュールスリップを早期にキャッチした場合、適切なタイミングで適切なチームメンバーを追加すると、リリースが節約される可能性があります。残念ながら、出荷予定日に近づくほど、人を追加することで問題が発生する可能性が高くなります。ある時点で、「現在の開発ブランチを出荷する以外に」変更を加えてもリリースを保存できない「リターンのないポイント」を越えます。
続けることができたが、私は主要なポイントを打ったと思う。プロジェクトの外で、あなたのキャリア、会社の将来の成功などに関して、あなたが間違いなくやるべきことの1つは、あなたが遅れた理由、何かが早くあなたに警告したかどうか、そしてあなたが必要な措置を把握することです将来的にそれを防ぐために取る。通常、遅いプロジェクトは次のいずれかの理由で発生します。
- 開始する前に遅れていた（時間よりも多くのもの）および/または
- 1時間、1日1時間スリップしました。
お役に立てば幸いです！
リソース主導のプロジェクトがある場合にのみ役立ちます。
たとえば、これを考慮してください：
4 x 6メートルなどの大きなポスターをペイントする必要があります。大きなポスターで、おそらく2人か3人の人をその前に置いて、並行してペイントさせることができます。ただし、20人を前に配置しても機能しません。さらに、くだらないポスターが必要な場合を除き、熟練した人材が必要になります。
ただし、プロジェクトで封筒に既製の文字（You MIGHT has win！など）を詰める場合は、追加する人が多いほど速くなります。大量の作業を負担することでオーバーヘッドが発生するため、1人の従業員がいる時点までメリットを得ることができません。封筒、しかしあなたはちょうど2つまたは3人よりはるかに多くから利益を得ることができます。
そのため、プロジェクトを簡単に小さなチャンクに分割でき、チームメンバーがすばやく（たとえば...に）速くなれるようになった場合、さらに多くの人を追加すると、ある程度まで速くなります。
残念ながら、私たちの世界ではそのようなプロジェクトは多くありません。そのため、Mygnical Man-Monthブックに関するdocgnomeのヒントは本当に良いアドバイスです。
次の条件が当てはまる場合：
- 新しいプログラマーはすでにプロジェクトを理解しており、立ち上げ時間を必要としません。
- 新しいプログラマーはすでに開発環境に精通しています。
- 開発者をチームに追加するのに管理時間は必要ありません。
- チームメンバー間のコミュニケーションはほとんど必要ありません。
これらすべてを一度に見たときに初めてお知らせします。
Mythical Man-Monthによれば、後期プロジェクトに人を追加する主な理由は後でそれがO（n ^ 2）通信のオーバーヘッドになることです。
私はこれに対する1つの主要な例外を経験しました：プロジェクトにoneの人しかいない場合、それはほとんど常に運命づけられています。秒を追加すると、ほぼ毎回速度が上がります。それは、コミュニケーションがオーバーヘッドではないためです-それはあなたの考えを明確にし、愚かな間違いを少なくするのに役立つ機会です。
また、質問を投稿したときに明らかに知っていたように、Mythical Man-Monthからのアドバイスはlateプロジェクトにのみ適用されます。あなたのプロジェクトがまだ遅れていない場合、人を追加しても後回しにならない可能性は十分にあります。もちろん、あなたが適切にそれを行うと仮定します。
既存のプログラマーが完全に無能である場合、有能なプログラマーを追加すると役立つ場合があります。
非常にモジュール化されたシステムがあり、既存のプログラマーも非常に孤立したモジュールではstartedでさえない状況を想像できます。その場合、プロジェクトのその部分だけを新しいプログラマに割り当てると役立つ場合があります。
基本的に、Mythical Man Monthの参照は正しいですが、私が作成したような不自然な場合を除きます。ブルックス氏は、ある時点の後、プロジェクトに新しいプログラマーを追加する際のネットワークと通信のコストが、生産性から得られるメリットを上回ることを実証するために確固たる研究を行いました。
- 新しい人々がテストに集中する場合
- 新しい依存関係を作成しない独立した機能を分離できる場合
- プロジェクトの一部の側面（特に、視覚的な設計/レイアウト、データベースのチューニング/インデックス作成、サーバーのセットアップ/ネットワーク構成などの非コーディングタスク）を直交化して、他の人がアプリケーションコードを実行できるようにする場合
- 人々がお互いを知り、テクノロジー、ビジネス要件、および設計を知っている場合、お互いのつま先を踏む時期とそうすることを避ける方法を知って物事を行うことができます（これ、もちろん、そうでない場合は手配するのがかなり難しいです）
プログラマを追加するのではなく、管理ヘルプを追加することを検討できます。気晴らしを取り除き、集中力を高め、または動機付けを改善するものはどれでも役立ちます。これには、システムと管理の両方、および昼食をとるなどのより一般的なものが含まれます。
その後半の段階で、まだ誰も取り組んでいない独立した（プロジェクトの他の部分とほぼ0％のやり取りをする）タスクがあり、その領域の専門家である誰かをチームに参加させることができる場合にのみ。チームメンバーを追加すると、チームの他のメンバーの混乱を最小限に抑える必要があります。
作業の最後に人を追加すると、次の場合に物事をスピードアップできると思います。
作業は並行して行うことができます。
追加されたリソースによって節約される量は、プロジェクトの経験者に経験の浅い人に物事を説明してもらうことで失われる時間よりも多くなります。
編集：私は言及するのを忘れて、この種のことはあまり頻繁に発生しません。通常、テーブルに対して単純なCRUDを実行する管理画面のような、かなり単純なものです。とにかく、これらのタイプのツールはほとんど自動生成できます。
ただし、この種の仕事を引き継ぐマネージャーには注意してください。それは素晴らしいように聞こえますが、実際には、プロジェクトの重要な時間を短縮するのに通常十分ではありません。
明らかに、すべてのプロジェクトは異なりますが、ほとんどの開発ジョブは、開発者間である程度のコラボレーションを持つことが保証されます。これが当てはまる場合、私の経験では、新鮮なリソースは実際に彼らがスピードアップするために依存している人々を意図せずに減速させることができ、場合によってはこれがあなたのキーパーソンになることがあります（通常、それは取る「キー」ピープルですnewbを教育する時間）。彼らがareスピードアップしているとき、彼らの仕事が確立された「ルール」またはチームの他のメンバーとの「仕事文化」に適合するという保証はありません。繰り返しますが、それは良いことよりも害を及ぼすことがあります。それはさておき、これらはそれが有益かもしれない状況です：
1）新しいリソースには、他の開発者との最小限の対話と既に実証されているスキルセットを必要とする厳しいタスクがあります。 （つまり、既存のコードを新しいプラットフォームに移植し、既存のコードベースで現在ロックされているデッドモジュールを外部でリファクタリングします）。
2）プロジェクトは、他の上級チームのメンバーの時間を共有して、newbのスピードを上げ、彼らの作業が既に行われた作業と互換性があるように指導するのを支援できるように管理されます。
3）他のチームメンバーは非常に忍耐強い。
- まだ開始されていない自己完結型モジュール
- 統合可能な開発ツールがありません（自動ビルドマネージャーなど）
主に、現在開発中の人々の邪魔にならないようにすることを考えています。 Mythical Man-Monthには同意しますが、すべてに例外があると思います。
チームに人を追加すると、プロジェクト自体に追加するよりもプロジェクトをスピードアップできると思います。
多くの場合、並行プロジェクトが多すぎるという問題に遭遇します。私がそのプロジェクトだけに集中できれば、これらのプロジェクトのいずれかをより早く完了することができます。チームメンバーを追加することで、他のプロジェクトから移行できました。
もちろん、これは、大規模なプロジェクトを継承し、独立して学習できる有能で自発的な開発者を雇ったことを前提としています。 :-)
追加のリソースcomplementが既存のチームであれば、理想的です。たとえば、プロダクションハードウェアをセットアップし、データベースが実際に調整されていることを確認する場合（チームがドメインの専門家として知っている）、次のプロジェクトで働く優れたDBAから時間を借りるトレーニング費用をかけずにチームをスピードアップできます
簡単に言えば。残りの時間と生産性を比較することになります。追加のリソースがスピードアップして生産的になるまでにかかる時間を除いて、誰かから得られる生産性を比較し、既存のリソースによってそれらを教えるために費やされた時間を差し引きます。キーファクター（重要度順）：
- リソースがそれを拾うのにどれほど良いか。最高の開発者は新しいサイトに足を踏み入れ、ほとんど支援を必要とせずにほぼ瞬時に生産的なバグ修正を行うことができます。このスキルはまれですが、学ぶことができます。
- タスクの分離可能性。既存の開発者をつまずかせたり、速度を落とすことなく、オブジェクトや機能を操作できる必要があります。
- プロジェクトの複雑さと利用可能なドキュメント。 VanillaのベストプラクティスASP.Netアプリケーションであり、よく文書化された一般的なビジネスシナリオである場合、優れた開発者はすぐに立ち往生できます。この要因は、既存のリソースが教育に費やす時間を決定するため、新しいリソースの最初の悪影響を決定します。
- 残り時間。これもしばしば誤って推定されます。多くの場合、ロジックはx週間しか残っておらず、誰かが速度を上げるのにx + 1週間かかります。現実には、プロジェクトISはずれ、実際には2週間の開発者が残されており、より早くより多くのリソースを取得することが役立つでしょう。
開発者を追加することは、追加の開発者によってもたらされる生産性が、それらの開発者のトレーニングと管理で失われる生産性を超える場合に意味があります。
チームがすでにプログラミングのペアリングに使用されている場合、別の開発者ペアリングに既に熟練しているを追加しても、特に開発がTDDスタイルで進行している場合、プロジェクトの速度が低下することはありません。
新しい開発者は、コードベースをより深く理解するにつれて徐々に生産性が向上し、誤解はペアによって、またはすべてのチェックインの前に実行されるテストスイートによって非常に早期に発見されます（そして、理想的にはチェックが必要です）少なくとも10分ごとに）。
ただし、余分な通信オーバーヘッドの影響を考慮する必要があります。プロジェクトの既存の知識を薄めすぎないことが重要です。