どのような状況下で（もしあれば）、チームにプログラマーを追加することで、すでに遅れているプロジェクトの開発が実際にスピードアップしますか？
edg
質問する
11581 次
16 に答える
87
正確な状況は明らかにプロジェクトに非常に固有です（たとえば、開発チーム、管理スタイル、プロセスの成熟度、主題の難しさなど）。これをもう少し適切にスコープして、過度に単純化する以外の方法でそれについて話すことができるようにするために、私はあなたの質問を言い直します：
どのような状況で、遅れて実行されているソフトウェア開発プロジェクトにチームメンバーを追加すると、既存のチームが完了するまで作業を許可された場合と同等の品質で実際の出荷日が短縮される可能性がありますか？
これが発生するために必要であるが十分ではないと私が考える多くのことがあります（順不同）：
- プロジェクトに追加する提案された個人は、次のものを持っている必要があります。
- プロジェクトの問題領域の少なくとも合理的な理解
- プロジェクトの言語と、与えられるタスクに使用する特定のテクノロジーに習熟している
- それらの習熟度は、それぞれ最弱または最強の既存のメンバーよりもはるかに少ないか、はるかに大きい必要があります。弱いメンバーは既存のスタッフを三次的な問題で消耗させますが、強すぎる新しい人は彼らが行ったことや行っていることすべてが間違っていることでチームを混乱させます。
- 優れたコミュニケーションスキルを持っている
- やる気が高い（例：躊躇せずに独立して働くことができる）
- 既存のチームメンバーは次のものを持っている必要があります。
- 優れたコミュニケーションスキル
- 優れた時間管理スキル
- プロジェクトリーダー/管理者は以下を持っている必要があります：
- 優れた優先順位付けとリソース割り当て能力
- 既存のチームメンバーからの高いレベルの敬意
- 優れたコミュニケーションスキル
- プロジェクトには次のものが必要です。
- 優れた、完成した、文書化されたソフトウェア設計仕様
- すでに実装されているものの優れたドキュメント
- 責任の明確な塊を切り出すことを可能にするモジュラー設計
- 必要な欠陥レベルの品質保証のための十分な自動化されたプロセスこれらには、単体テスト、回帰テスト、自動化されたビルド展開などが含まれる場合があります。
- チームによって現在実施され、使用されているバグ/機能追跡システム（trac、SourceForge、FogBugzなど）。
最初に話し合うべきことの1つは、出荷日を遅らせることができるかどうか、機能を削減できるかどうか、そしてこの2つの組み合わせによって既存のスタッフとのリリースを満足させることができるかどうかです。多くの場合、投資と同等の価値を提供しないチームのリソースを実際に占有しているいくつかの機能があります。したがって、プロジェクトの優先順位を何よりも優先して真剣に検討してください。
上記の段落の結果が十分でない場合は、上記のリストにアクセスしてください。スケジュールのずれを早期に把握した場合は、適切なチームメンバーを適切なタイミングで追加することで、リリースを保存できる可能性があります。残念ながら、出荷予定日に近づくほど、人を追加する際に問題が発生する可能性が高くなります。ある時点で、（現在の開発ブランチを出荷する以外の）変更の量がリリースを保存できない「返品不可のポイント」を越えることになります。
私は何度も続けることができましたが、私は主要なポイントに到達したと思います。プロジェクトの外で、あなたのキャリア、会社の将来の成功などの観点から、あなたが間違いなくすべきことの1つは、あなたが遅れた理由、何かが以前に警告された可能性があるかどうか、そしてあなたが必要とする対策を理解することです将来それを防ぐために取る。後期プロジェクトは通常、次のいずれかの理由で発生します。
- 始める前に遅れた（時間よりも多くのもの）および/または
- 一度に1時間1日滑った。
お役に立てば幸いです。
于 2008-09-16T21:41:13.793 に答える
29
リソース主導のプロジェクトがある場合にのみ役立ちます。
たとえば、次のように考えてください。
たとえば、4 x 6 メートルの大きなポスターを作成する必要があります。これだけ大きなポスターなら、2～3人で並べて絵を描いてもらうこともできそうです。ただし、その前に 20 人を配置することはできません。さらに、質の悪いポスターが必要でない限り、熟練した人材が必要です。
ただし、プロジェクトが印刷済みの文字を封筒に詰める場合 (あなたが勝ったかもしれません! )、追加する人が多ければ多いほど、作業は速くなります。積み重なった作業にはオーバーヘッドがかかるため、担当者が 1 人になるまではメリットが得られません。エンベロープですが、2 人または 3 人だけでなく、はるかに多くのメリットを得ることができます。
したがって、プロジェクトを小さなチャンクに簡単に分割でき、チーム メンバーが迅速に (たとえば... 瞬時に) 作業を開始できる場合は、人員を追加することである程度までは速くなります。
悲しいことに、私たちの世界ではそのようなプロジェクトは多くありません。そのため、Mythical Man-Month 本に関する docgnome のヒントは本当に良いアドバイスです。
于 2008-09-16T20:27:50.770 に答える
17
以下の条件に当てはまる場合、可能性があります。
- 新しいプログラマーはすでにプロジェクトを理解しており、立ち上げの時間は必要ありません。
- 新しいプログラマーは、すでに開発環境に習熟しています。
- 開発者をチームに追加するための管理時間は必要ありません。
- チームメンバー間のコミュニケーションはほとんど必要ありません。
これらすべてを一度に初めて見たときにお知らせします。
于 2008-09-16T20:27:11.303 に答える
11
Mythical Man-Month によると、遅れたプロジェクトに人を追加する主な理由は、O(n^2) の通信オーバーヘッドです。
私はこれについて 1 つの主な例外を経験しました。プロジェクトに1人しかいない場合、ほとんどの場合、失敗に終わります。2番目のものを追加すると、ほぼ毎回速度が向上します。その場合、コミュニケーションがオーバーヘッドにならないためです。考えを明確にし、愚かな間違いを減らすのに役立つ機会です。
また、質問を投稿したときに明らかにわかっていたように、Mythical Man-Month からのアドバイスは遅れたプロジェクトにのみ適用されます。プロジェクトがまだ遅れていない場合、人を追加しても後で間に合わない可能性は十分にあります。もちろん、適切に行うことが前提です。
于 2008-09-16T22:33:26.587 に答える
10
既存のプログラマーがまったく能力がない場合は、有能なプログラマーを追加することが役立つ場合があります。
あなたが非常にモジュール化されたシステムを持っていて、既存のプログラマーが非常に孤立したモジュールでさえ始めていなかった状況を想像することができます。その場合、プロジェクトのその部分だけを新しいプログラマーに割り当てると役立つ場合があります。
基本的に、私がでっち上げたような不自然な場合を除いて、神話上のマン月の参照は正しいです。Brooks 氏は確かな調査を行い、ある時点以降、新しいプログラマーをプロジェクトに追加するネットワークと通信のコストが、彼らの生産性から得られる利益を上回ることを示しました。
于 2008-09-16T20:23:06.603 に答える
5
- 新しい人がテストに集中する場合
- 新しい依存関係を作成しない独立した機能を分離できる場合
- プロジェクトの一部の側面 (特に、ビジュアル デザイン/レイアウト、データベースのチューニング/インデックス作成、サーバーのセットアップ/ネットワーク構成などの非コーディング タスク) を直交化して、1 人がそれに取り組み、他の人がアプリケーション コードを実行できる場合
- 人々がお互いのこと、テクノロジー、ビジネス要件、設計をよく知っていれば、いつお互いの足を踏むのか、それを回避する方法を知っていれば、物事を行うことができます (これは、もちろん、まだそうでない場合、手配するのはかなり難しいです）
于 2008-09-16T20:29:43.373 に答える
4
その後期段階で、まだ誰も取り組んでいないいくつかの独立した (プロジェクトの他の部分とのやり取りがほぼ 0% の) タスクがあり、その分野のスペシャリストである誰かをチームに参加させることができる場合に限ります。チームメンバーの追加は、チームの残りのメンバーの混乱を最小限に抑える必要があります。
于 2008-09-16T20:38:12.103 に答える
4
プログラマーを追加するのではなく、管理上のヘルプを追加することを考えることができます。気を散らすものを取り除いたり、集中力を高めたり、モチベーションを高めたりするものは何でも役に立ちます。これには、システムと管理の両方が含まれ、昼食をとるなどのより平凡なものも含まれます。
于 2008-09-17T09:38:03.447 に答える
3
次の場合、作業の終わりに向かって人を追加すると、作業がスピードアップする可能性があると思います。
作業は並行して行うことができます。
リソースの追加によって節約される量は、プロジェクトの経験者が経験の浅い人に物事を説明することによって失われる時間よりも多くなります。
編集: 言い忘れましたが、この種のことはあまり頻繁には起こりません。通常、テーブルに対して単純な CRUD を実行する管理画面など、かなり単純なものです。最近では、これらのタイプのツールはほとんど自動生成できます。
ただし、この種の仕事を引き継ぎに頼るマネージャーには注意してください。素晴らしいことのように聞こえますが、実際には、プロジェクトからかなりの時間を削減するのに十分ではありません。
于 2008-09-16T20:43:44.900 に答える
3
明らかにすべてのプロジェクトは異なりますが、ほとんどの開発ジョブでは、開発者間である程度のコラボレーションが保証されます。この場合、私の経験では、新しいリソースは実際に、彼らが頼りにしている人々のスピードを意図せず遅くする可能性があり、場合によっては、これがあなたの主要な人々になる可能性があります (ちなみに、それは通常「主要な」人々であり、新人を教育する時間 b)。彼らがスピードを上げたとしても、彼らの仕事がチームの他のメンバーと確立された「ルール」や「労働文化」に適合するという保証はありません。繰り返しになりますが、それは良いことよりも害を及ぼす可能性があります。それはさておき、これらはそれが有益であるかもしれない状況です：
1) 新しいリソースには、他の開発者との最小限のやり取りと、すでに実証済みのスキル セットを必要とするタイトなタスクがあります。(つまり、既存のコードを新しいプラットフォームに移植し、既存のコード ベースで現在ロックダウンされているデッド モジュールを外部からリファクタリングします)。
2) プロジェクトは、他のより上級のチームメンバーが時間を共有して、新人をスピードアップし、彼らの仕事がすでに行われたことと互換性があることを確認する方法に沿って指導できるように管理されています.
3) 他のチームメンバーは非常に忍耐強い.
于 2008-09-16T22:31:26.183 に答える
2
追加のリソースが既存のチームを補完する場合、それは理想的です。たとえば、本番ハードウェアをセットアップして、データベースが実際に調整されていることを確認する場合、次のプロジェクトに取り組む優れたdbaから時間を借りて、良い結果（チームはドメインエキスパートとして知っている）を返すだけではありません。あなたに多くのトレーニングコストなしでチームをスピードアップすることができます
于 2008-09-21T21:19:48.740 に答える
2
- まだ開始されていない自己完結型モジュール
- 統合できる開発ツールがない (自動ビルド マネージャーなど)
主に、現在開発中の人の邪魔にならないようにすることを考えています。Mythical Man-Month には同意しますが、すべてに例外があると思います。
于 2008-09-16T20:24:48.190 に答える
2
プロジェクト自体に人を追加するよりも、チームに人を追加する方がプロジェクトをスピードアップできると思います。
並行プロジェクトが多すぎるという問題によく遭遇します。私がそのプロジェクトだけに集中できれば、どのプロジェクトもより早く完了することができます。チーム メンバーを追加することで、他のプロジェクトから移行することができました。
もちろん、これは、大規模なプロジェクトを継承し、独立して学習できる、有能で自発的な開発者を雇ったことを前提としています。:-)
于 2008-09-17T03:33:36.880 に答える
1
簡単に言えば。要するに、残りの時間と誰かから得られる生産性を比較して、追加のリソースがスピードを上げて生産的になるのにかかる時間を除外し、既存のリソースによってそれらを教えるために費やされた時間を差し引くことになります. 主な要因 (重要度順):
- リソースがそれを拾うのにどれだけ優れているか。優れた開発者は、新しいサイトに足を踏み入れ、ほとんど支援を受けずにほぼ瞬時にバグを修正して生産性を高めることができます。このスキルはレアですが習得できます。
- タスクの分離可能性。彼らは、既存の開発者に躓いて速度を落とすことなく、オブジェクトや機能に取り組める必要があります。
- プロジェクトの複雑さと利用可能なドキュメント。それが標準的なベスト プラクティスの ASP.Net アプリケーションであり、十分に文書化された一般的なビジネス シナリオである場合、優れた開発者はすぐに行き詰まる可能性があります。この要因は何よりも、既存のリソースが教育に費やす時間を決定し、したがって新しいリソースの初期の悪影響を決定します。
- 残り時間。これもよく間違えられます。多くの場合、ロジックは、残り x 週間しかなく、誰かが最新の状態になるまでに x+1 週間かかるというものです。実際には、プロジェクトは失敗する可能性があり、実際には 2 週間の開発期間が残っており、遅かれ早かれより多くのリソースを取得することが役に立ちます。
于 2008-09-17T04:16:05.140 に答える
1
追加の開発者によってもたらされる生産性が、それらの開発者のトレーニングと管理によって失われる生産性を上回る場合、開発者の追加は理にかなっています。
于 2011-07-22T20:35:55.083 に答える
1
チームがすでにペア プログラミングに慣れている場合、特に開発が TDD スタイルで進行している場合は、ペア プログラミングにすでに熟練している別の開発者を追加しても、プロジェクトの速度が低下することはありません。
新しい開発者は、コード ベースをより深く理解するにつれて、徐々に生産性が向上します。誤解は、ペアによって、またはすべてのチェックインの前に実行されるテスト スイートによって非常に早い段階で検出されます (理想的には、チェックインがあるはずです)。少なくとも 10 分ごとに)。
ただし、追加の通信オーバーヘッドの影響を考慮する必要があります。プロジェクトに関する既存の知識を薄めすぎないことが重要です。
于 2008-09-17T10:29:16.320 に答える