後期プロジェクトに人を追加すると、なぜそれが後になるのですか？

遅いプロジェクトにプログラマを追加すると事態が悪化するというのはかなり一般的な格言です。どうしてこれなの？

導入オーバーヘッド

新しい開発者はそれぞれ、コードベースと開発プロセスを紹介する必要があり、新しい人の時間だけでなく、[a]シニア開発者からの支援も必要です（ビルドプロセスのガイド、テストプロセスの説明、支援コードベースの落とし穴、より詳細なコードレビューなど）。

したがって、プロジェクトに追加する新しい開発者が増えるほど、プロジェクトに実際に貢献できるポイントに到達するまでに多くの時間が費やされます。

他の答えに加えて、考慮すべきもう1つの要素はコミュニケーションです。

チームのコミュニケーションチャネルの量の最悪のケース（珍しいことではありません）は、完全なグラフです。ご想像のとおり、1人の開発者を追加するだけで、コミュニケーションチャネルを大幅に増やすことができます。より合理化された通信方法を使用すると、影響は少なくなりますが、それでも増え続けます。

この法律で最初に公布された本「神話の男月」に引用されている問題はコミュニケーションです。彼は言うことから始めます：

男性と月は、タスクを多くのワーカー間でコミュニケーションなしで分割できる場合にのみ交換可能な商品です。これは小麦の刈り取りや綿の摘み取りにも当てはまります。システムプログラミングについてもほぼ当てはまりません。

彼は問題の一部としてトレーニングに言及しています：

コミュニケーションの追加の負担は、トレーニングと相互コミュニケーションの2つの部分で構成されています。各従業員は、テクノロジー、取り組みの目標、全体的な戦略、および作業計画についてトレーニングする必要があります。このトレーニングは分割できないため、作業のこの部分はワーカーの数に比例して変化します。

...しかし、相互通信がはるかに大きな要因であることに注意してください：

ソフトウェアの構築は本質的にシステムの努力であるため（複雑な相互関係の演習）、コミュニケーションの努力は多大であり、パーティション分割によってもたらされる個々のタスク時間の短縮をすぐに支配します。男性を追加すると、スケジュールが短くなるのではなく、長くなります。

フレッドブルックス（著者）が彼が何について話しているかを知る背景を持っていることも注目に値します。この本の大部分は、IBMのOS / 360プロジェクトの管理経験に基づいています。何十年もの支持者があらゆる方法で「改善された」管理方法を説き、一部の人はそれに慣れるとクールな名前（eXtreme、Agile、Scrumなど）を思いつきますが、それ以来本質¹はほとんど変わっていないようです。

¹「本質」の定義については、The Mythical Man-Month ^20th Anniversary Editionに含まれている同じ著者の「No Silver Bullet：Essence and Accident in Software Engineering」を参照してください。

単なる格言ではありません。検証可能です。ブルックスの「The Mythical Man-Month」をご覧ください。

この問題に関するいくつかの考えがあります...

• 現在のリソースを使用して、プロジェクトで何が行われているかについて新しいリソースをスピードアップする必要があります。
• 新しいリソースはコードベースに慣れていない可能性があるため、コードに慣れるにはさらに時間が必要です。

現在、テスト用の新しいリソースを追加することは悪い考えではないかもしれません...テストプロセスを高速化する可能性があります（テストケースが適切に記述されている場合）。テストツールを使用することも役立ちます。

プログラミングは基本的な生産ラインの仕事ではないからです。ソフトウェアプロジェクトの速度を上げるには時間がかかります。新規の人々は、否定的な生産性につながる多くの質問をする必要があります（すなわち、新しい人が学習し、古い人がそれらを教える->実際の作業が完了しない）。

それを単純化するために、1週間行く予定の比較的単純な1人のプロジェクトを想像してください。その時点で別のプログラマーを追加する場合、プログラマー1と少なくとも数時間または1日程度作業する必要があり、多くの質問をして速度を上げるなどする必要があります。週の残りの期間の純生産性。新しいプログラマーは（プログラマー1と同様に既存のコードも知らないので）いくつかの余分なバグを導入する可能性があります。そのため、実装とテストのサイクルがあと1、2日で吹き飛ばされます。このプロジェクトは、元のプロジェクトの代わりに2週間で簡単に継続します！

フレッド・ブルックスは、この質問に答える本「The Mythical Man-Month」全体を書きました。

クイックアンドダーティバージョンは次のとおりです。

1）より多くのプログラマーに割り当てるために、プロジェクトを個別の部分に分割できる量には制限があります。

2）プロジェクトをより多くの人に分割すると、アプリケーションのすべての部分を調整するために必要なコミュニケーションの量が増えます。より多くのコミュニケーション=より多くの仕事。

3）プロジェクトに追加するすべての人に対して、チームにナビゲートする必要がある複数のコミュニケーションチャネルを追加します。この数は幾何学的に増加し、発生しなければならないコミュニケーションの量を増やします。より多くのコミュニケーション=より多くの仕事。

4）各チームメンバーを追加すると、「Jカーブ」があります。つまり、既存の生産的リソースは、新しい人々がプロジェクトに取り組むのに費やす可能性のあるスピードに時間を費やす必要があります。最終的には容量を増やすことができますが、プロジェクトが一時的に遅くなります。プロジェクトの後半で学習する必要があるものが多いほど、効果がより顕著になります。

私が言及しなかった別の要因は、いくつかのタスクが特定の順序で実行される必要があるということです。タスク3は3に依存しているため、タスク3が完了するまでタスク4を実行することはできません。誰かがタスク3を実行すると同時にタスク4を実行する人を雇うことは何の役にも立ちません。 、他のタスクを最初に完了する必要があるタスクが残りのタスクです。

また、多くの場合、実行が必要な最も複雑なタスクの一部であり、すでに完了したものを壊さないように設計全体を最もよく理解する必要があるタスクです。また、通常、最も広範なビジネスドメインの知識も必要です。プロジェクトに数ヶ月取り組んだ後、1​​週間以内にタスクを実行できるようになるかもしれません。新しい人は1週間以上かけてスピードを上げ（質問に答えるためにその時間に十分な注意を払ってタスクから引き離します）、非常に熟練していてもタスクを実行するのに時間がかかります。彼または彼女は有能ではありませんが、プロジェクトまたはデータベースバックエンドの実際の構造に不慣れなためです。

私のためにいつも働いている格言は、1か月で9人の女性に赤ちゃんを作ることはできないということです。

DeMarcoとListerの「Peopleware」もお勧めします。

そして、DeMarcoによる「The Deadline」は、これと、他の多くのソフトウェアプロジェクト管理の病気と誤fallを、軽快で非常に読みやすい方法で提示します。

また、プロジェクト/チームワークを行う人々のダイナミクスを掘り下げ、コミュニケーションや紹介のようなものがチームの利用可能な労働時間をどのように枯渇させるかについても詳細に説明します。

これらの本は非常に安いので、入手して（AmazonまたはThe Book Depositoryにある）読んでもらうことをお勧めします。ここでの短い答えは、質問に対する正義を実際に行うことはできません。

誰もプログラマーを雇用、トレーニング、開発、監督するだけでなく、特定のプロジェクトでスピードアップするために、熟考、計画、テストされたプロセスを持つ時​​間がありません。

あなたが開発者のチームを管理している場合、あなたはあなたがオープニングを持っている場合、あなたが雇いたいと思う人々の今いくつかの連絡先を持っている必要があります。開発者グループに参加します。

まったく新しい開発マシンのセットアップをどれくらい早く取得して、すぐに使用できますか？

別のプロジェクトの開発者に見せることで、プロジェクトのドキュメントと仕様をテストしたことがありますか？彼らはそれを見て、必要に応じてプロジェクトの作業を開始できると判断しましたか？

プロジェクトのスケジュールはどのくらい最新ですか？

プロジェクトが遅れると、ハリケーンのようになるため、雨の日のために節約しましょう。

コミュニケーションの問題（他のすべての答えが話していると思います）以外に、プロジェクトに追加された人がバグを作成する可能性もあります。彼らはまだコードをよく知らないからです。

プロジェクトに追加されるたびに、常に物事を壊さないように一生懸命努力します。これは、最初は物事を修正するのがはるかに遅いことを意味します。

他の回答ではこれまで完全に無視されていたものを指摘したいと思います。

人々が後期プロジェクトに追加される頃には、通常、組織全体で多くの問題が発生しています。管理者とクライアントは満足していません。人々はそれに取り組むよう圧力をかけられています。物事はかなり緊張しています。

今、あなたがそのチームにいると想像してください。明らかにこれはあなたのせいではありません。計画（どれもあなたのものではありませんでした）は楽観的すぎました。すべての間違った決定は、あなたに相談することなくなされました。あなたはそれを最大限に活用しようとしていますが、突然多くの新しい人々が巻き込まれています。これはどのようなメッセージを伝えていますか？

2階の人々は明らかにあなたに対する信頼を失っています。彼らはあなたが台無しにしたものを補うために大きな男の子を呼びました。

あなたはまだこれを成功させる意欲がありますか？または...あなたはこれまでよりもイライラし、結局すべてがクラッシュするのを見るでしょうか？

ゆっくりしてください ：-）。