私は1か月でこの赤ちゃんが必要です-9人の女性を送ってください!


185

どのような状況で(もしあれば)、プログラマーをチームに追加することで、すでに遅れたプロジェクトの開発が実際にスピードアップしますか?


あなたが作ろうとしているアナロジーを理解しましたが、それでも、より説明的で衝撃の少ないタイトルが良い考えかもしれません...
Adrian Petrescu

「カップル」を「女性」に置き換えます
ちょうどマイク

追加する男性の数は関係ありません(数値がゼロ以外であれば)、それでも9人の女性が必要です。
Windowsプログラマ、

9
女性の1人が8か月妊娠している限り、それは機能します。
Toon Krijthe、2011年

回答:


87

正確な状況は明らかにプロジェクトに非常に固有です(たとえば、開発チーム、管理スタイル、プロセスの成熟度、主題の難しさなど)。これを少し詳しく調べて、単純化しすぎないことについて話せるようにするために、質問を再説明します。

遅れているソフトウェア開発プロジェクトにチームメンバーを追加すると、既存のチームが完了まで作業を許可された場合と同等の品質レベルで、実際の出荷日が短縮される可能性があります。

これが(特定の順序ではなく)発生するために必要であるが十分ではない、と私が思う多くの事柄があります:

  • プロジェクトに追加する提案された個人は、以下を持っている必要があります。
    • プロジェクトの問題領域の少なくとも合理的な理解
    • プロジェクトの言語と、彼らが与えられるタスクに使用する特定のテクノロジーに精通している
    • 彼らの習熟度は、それぞれ、最も弱いまたは最も強い既存のメンバーよりもはるかに少ないか、またははるかに大きい必要があります。弱いメンバーは既存のスタッフに第3の問題を引き起こし、強すぎる新しいメンバーはチームがやったことややっていることが間違っていることにチームを混乱させます。
    • コミュニケーション能力が高い
    • 高いモチベーションを持っている(例:手抜きすることなく独立して仕事ができる)
  • 既存のチームメンバーには、次のものが必要です。
    • 優れたコミュニケーションスキル
    • 優れた時間管理スキル
  • プロジェクトリーダーまたは管理者は、
    • 優れた優先順位付けとリソース割り当て機能
    • 既存のチームメンバーからの高い評価
    • 優れたコミュニケーションスキル
  • プロジェクトには以下が必要です。
    • 完全で文書化された優れたソフトウェア設計仕様
    • すでに実装されているものの優れたドキュメント
    • 明確な一連の責任を切り分けられるようにするモジュール設計
    • 必要な欠陥レベルの品質保証のための十分な自動プロセスこれらには、単体テスト、回帰テスト、自動ビルドデプロイメントなどが含まれる場合があります。
    • チームが現在インプレースで使用しているバグ/機能追跡システム(例:trac、SourceForge、FogBugzなど)。

最初に検討する必要があることの1つは、出荷日遅らせることができるかどうか、機能をカットできるかどうか、および2つを組み合わせて既存のスタッフとのリリースに満足できるかどうかです。多くの場合、投資に見合う価値を提供しないチームのリソースを本当に消費している2つの機能があります。したがって、プロジェクトの優先順位を真剣に検討してから、何よりも優先してください。

上記の段落の結果が十分でない場合は、上記のリストにアクセスしてください。スケジュールスリップを早く見つけた場合は、適切なタイミングで適切なチームメンバーを追加すると、リリースを節約できます。残念ながら、予定出荷日に近づくほど、人の追加で問題が発生する可能性が高くなります。ある時点で、「現在の開発ブランチを出荷する以外の)変更によってリリースを節約できない「ノーリターンオブポイント」を越えることになります。

私は何度も続けることができましたが、私は主要なポイントを打ったと思います。プロジェクトの外で、あなたのキャリア、会社の将来の成功などに関して、あなたが間違いなくやるべきことの1つは、あなたが遅れた理由を理解することです。将来それを防ぐために取る。通常、プロジェクトが遅れるのは、次のいずれかが原因です。

  • あなたが始める前に遅れていた(時間よりも多くのもの)および/または
  • 時間に1時間、1日ずれた。

お役に立てば幸いです。


3
良いリスト。ただし、リストにすべてが揃っていないため、多くのプロジェクトが遅れるのではないかと心配しています...
sleske

1
気楽

29

リソース駆動型プロジェクトがある場合にのみ役立ちます。

たとえば、次のことを考慮してください。

大きなポスター、たとえば4 x 6メートルを描く必要があります。とても大きなポスターです。おそらく、その前に2〜3人を置いて、並行してペイントさせることができます。ただし、その前に20人を配置しても機能しません。さらに、安っぽいポスターが必要でない限り、熟練した人が必要です。

ただし、プロジェクトに封筒を印刷済みの文字で埋め込む場合たとえばあなたが勝ったかもしれません)、追加するユーザーが多いほど、処理が速くなります。仕事のスタックを実行するのにいくらかのオーバーヘッドがあるので、あなたが一人の広報を持っているところまで利益を得ることができません。封筒ですが、2〜3人以上のメリットがあります。

したがって、プロジェクトを小さなチャンクに簡単に分割でき、チームメンバーがすぐに(たとえば...すぐに)スピードを上げることができる場合は、さらに多くの人を追加すると、ある程度までは速くなります。

悲しいことに、私たちの世界ではそのようなプロジェクトはそれほど多くありません。そのため、神話のマン・マンスに関するdocgnomeのヒントは本当に良いアドバイスです。


ソフトウェアは本質的にそのようなプロジェクトではないと思います。そのため、プログラマー以外の作業(画像の作成やテキストの翻訳など)を行う人を追加しない限り、TMMMを参考にしても、役に立たないと言っても安全です
Mike Stone

17

おそらく次の条件が当てはまる場合:

  1. 新しいプログラマーはすでにプロジェクトを理解しており、立ち上げ時間を必要としません。
  2. 新しいプログラマーはすでに開発環境に精通しています。
  3. チームに開発者を追加するための管理時間は必要ありません。
  4. チームメンバー間のコミュニケーションはほとんど必要ありません。

これらすべてを一度に初めて見たときにお知らせします。


1
基本的に、誰かが彼らが残したプロジェクトに戻って追加します(十分に最近なので、何も忘れていません)
Mike Stone

1
「これらすべてを一度に初めて見たときにお知らせします。」息を止めて!!!
Stu Thompson、

チームメンバーの追加が成功するための条件をまとめようとしたのが好きです。(2)と(3)は簡単ではないと思います。(1)それらがすでに存在していたプロジェクトに戻す場合にのみ可能です。(4)他のプログラマーとの既存の関係を持つプロジェクト(以前のプロジェクトから)に切り替えられている既存の従業員である場合にのみ可能です。
匿名タイプ

11

Mythical Man-Monthによると、後期プロジェクトに人を追加する主な理由は、O(n ^ 2)通信オーバーヘッドです。

私はこれに対する1つの主な例外を経験しました。プロジェクトに1人しかいない場合、それはほとんど常に運命にあります。2つ目を追加すると、ほぼ毎回速度が上がります。その場合、コミュニケーションはオーバーヘッドではないためです。考えを明確にし、愚かな間違いを減らすのに役立つ機会です。

また、あなたが質問を投稿したときに明らかに知っていたように、Mythical Man-Monthからのアドバイスは後期のプロジェクトにのみ適用されます。プロジェクトがまだ遅れていない場合は、人を追加しても遅れることはほとんどありません。もちろん、あなたがそれを適切に行うと仮定します。


10

既存のプログラマーがまったく無能な場合は、有能なプログラマーを追加することが役立つ場合があります。

あなたが非常にモジュール式のシステムを持っていて、既存のプログラマーが非常に孤立したモジュールでさえ開始していなかった状況を想像できます。その場合、プロジェクトのその部分だけを新しいプログラマーに割り当てると役立つ場合があります。

私が作ったような人為的なケースを除いて、基本的に神話の男月の参照は正しいです。Brooks氏は、ある時点を過ぎると、プロジェクトに新しいプログラマーを追加する場合のネットワーキングと通信のコストが、生産性から得られるメリットを上回ることを実証するために、しっかりとした調査を行いました。


本当にそうでもない...それでもコードベースを学ぶだけでコストがかかる...そしてもしそれらが完全に無能なら、プロジェクトはおそらくとにかく失敗するだろう。
マイクストーン

ここでマイク・ストーンに同意します。コードベースとアーキテクチャに欠陥がある可能性があり、深刻なプロジェクトの開発者1人あたり2〜4か月の時間、技術的なリーダーシップに関するあらゆる種類の問題などがあります。
Stu Thompson

5
  • 新しい人がテストに集中する場合
  • 新しい依存関係を作成しない独立した機能を分離できる場合
  • プロジェクトの一部の側面(特に、ビジュアルデザイン/レイアウト、データベースのチューニング/インデックス作成、サーバーのセットアップ/ネットワーク構成などの非コーディングタスク)を直交化して、他の人がアプリケーションコードを実行できるように、一人で作業できるようにする場合
  • 人々がお互いを知り、テクノロジー、ビジネス要件、およびデザインを知っている場合、お互いのつま先をいつ踏むか、そうしないようにする方法(これ、もちろん、まだそうなっていない場合、手配するのはかなり難しいです)

4

その後半の段階で、誰もまだ対処していない独立した(プロジェクトの他の部分との相互作用がほぼ0%)タスクがあり、そのドメインの専門家である誰かをチームに参加させることができる場合にのみ。チームメンバーの追加は、チームの他のメンバーの混乱を最小限に抑える必要があります。


4

プログラマーを追加するのではなく、管理ヘルプを追加することを考えることができます。気を散らすものを取り除いたり、集中力を高めたり、やる気を高めたりするものなら何でも役に立ちます。これには、システムと管理の両方、および昼食をとるなどのより平凡なものが含まれます。


1
良い提案であり、Mythical Man Monthの提案の精神に沿ったものだと思います。++
Ed Guiness

3

当然、プロジェクトはそれぞれ異なりますが、ほとんどの開発ジョブでは、開発者間である程度のコラボレーションを行うことができます。これが事実である場合、私の経験では、新鮮なリソースは実際に彼らがそれらをスピードアップするために依存している人々を意図せずに遅くする可能性があり、場合によってはこれがあなたのキーパーソンである可能性がありますnewbを教育する時間b)。彼らスピード上げているとき、彼らの仕事がチームの他のメンバーと確立された「ルール」または「仕事の文化」に適合するという保証はありません。繰り返しになりますが、それは良いよりも害を及ぼす可能性があります。それはさておき、これらはそれが有益かもしれない状況です:

1)新しいリソースには厳しいタスクがあり、他の開発者との最小限の対話と、すでに実証されているスキルセットが必要です。(つまり、既存のコードを新しいプラットフォームに移植し、既存のコードベースで現在ロックダウンされているデッドモジュールを外部でリファクタリングします)。

2)プロジェクトは、他の上級チームメンバーと時間を共有できるように管理されており、newbをスピードアップし、彼らの仕事がすでに行われていることと互換性があることを保証する方法に沿って指導するのを支援します。

3)他のチームメンバーは非常に忍耐強いです。


3

作業の終わり頃に人を追加すると、次の場合にスピードが上がると思います。

  1. 作業は並行して行うことができます。

  2. 追加されたリソースによって節約される量は、プロジェクトの経験者が経験の浅い人に説明することによって失われる時間よりも多くなります。

編集:私は言及するのを忘れました、この種のことはあまり頻繁には起こりません。通常は、テーブルに対して単純なCRUDを実行する管理画面など、かなり単純なものです。最近では、これらのタイプのツールはとにかくほとんど自動生成されます。

ただし、この種の仕事を任せて引き渡すマネージャーには注意してください。素晴らしいように聞こえますが、実際には、プロジェクトの大幅な時間を短縮するのに十分ではありません。


そして、実際にはどのくらいの頻度でそうなのでしょうか?
Stu Thompson、

2
  • まだ開始されていない自己完結型モジュール
  • 統合できる開発ツールがない(自動ビルドマネージャーなど)

主に私は、彼らが現在発展している人々の道から遠ざけることができるようにすることを考えています。Mythical Man-Monthには同意しますが、すべてに例外があると思います。


2

チームに人を追加すると、プロジェクト自体に人を追加するよりも、プロジェクトをスピードアップできると思います。

並行プロジェクトが多すぎるという問題によく遭遇します。私がそのプロジェクトだけに集中できれば、これらのプロジェクトのどれでもより早く完了することができます。チームメンバーを追加することで、他のプロジェクトから移行できました。

もちろん、これは、大規模なプロジェクトを継承して自主的に学習できる、有能で自発的な開発者を採用していることを前提としています。:-)


2

追加のリソースが既存のチームを補完する場合、それは理想的です。たとえば、プロダクションハードウェアをセットアップし、データベースが実際に調整されていることを確認する場合(次のプロジェクトで作業する優れたdbaから時間を借りて(チームがドメインの専門家として知っている)良い結果を返すだけではありません)トレーニング費用をかけずにチームをスピードアップできます


これは実際にはかなり良い答えです。より一般的には、プロジェクトがABCとDの知識に依存していて、チームのプログラマーがAとBを知っている場合、CとDを理解するプログラマーを追加すると、完了までの時間を短縮できます。人々はうまくやっていく必要があり、チームには依然としてサイズ制限があります
Windowsプログラマー

1

簡単に言えば。それは、残りの時間と誰かから得られる生産性を比較することです。追加のリソースがスピードアップして生産性を発揮し、既存のリソースによるそれらの教育に費やされた時間を差し引くのにかかる時間を除外します。重要な要素(重要度順):

  1. リソースがそれを拾うのにどれだけ優れているか。最高の開発者は、新しいサイトに足を踏み入れ、ほとんど支援なしでほぼ​​即座に生産的なバグ修正を行うことができます。このスキルはまれですが、習得することができます。
  2. タスクの分離可能性。彼らは、既存の開発者をつまずかせたり、速度を落としたりすることなく、オブジェクトや関数を操作できる必要があります。
  3. 利用可能なプロジェクトとドキュメントの複雑さ。それがバニラベストプラクティスのASP.Netアプリケーションであり、よく文書化された一般的なビジネスシナリオである場合、優れた開発者はすぐに立ち往生することができます。この要因は、既存のリソースが教育に投資する必要がある時間を決定し、そのため、新しいリソースの初期の負の影響を決定します。
  4. 残り時間。これもしばしば誤って推定されます。多くの場合、ロジックはx週間しか残っておらず、誰かがスピードアップするまでにx + 1週間かかります。実際には、プロジェクトは失敗し、実際には2x週間の開発者が残っており、より多くのリソースをより早く取得することが役立ちます。

1

チームがすでにプログラミングのペアリングに使用されている場合、特にペアリングに熟練している別の開発者を追加しても、特にTDDスタイルで開発が進行している場合は、プロジェクトが遅くなることはありません。

新しい開発者は、コードベースを理解するにつれて徐々に生産性が向上し、誤解はペアまたはすべてのチェックインの前に実行されるテストスイートによって非常に早期に検出されます(理想的にはチェックがあるはずです)。少なくとも10分ごとに)。

ただし、余分な通信オーバーヘッドの影響を考慮する必要があります。プロジェクトの既存の知識を過度に薄めないことが重要です。


それであなたはそれが役に立つかもしれないし役に立たないかもしれないと言っているのですか?
Ed Guiness

多かれ少なかれ。受け入れられている知恵は、後期プロジェクトに人を追加すると後でそれができるということですが、非常に注意深く管理された限られた状況では、追加の人からいくつかの有用な追加作業を得ることができます。
ビルミシェル

1

開発者の追加は、追加の開発者によってもたらされた生産性が、それらの開発者のトレーニングと管理によって失われた生産性を超える場合に意味があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.