どのような状況下で、開発は少数の貢献者と比較して多くの貢献者でより速く進行しますか？
Joel Spolskyとのインタビューを見ました。彼は、Fog Creek Softwareがチームを意図的に小さくしていると言っています（私は45人の男と同じように信じています）。これは、チームが大きい場合にチームメンバー間で必要となる多くのコミュニケーションを回避するためです。これをオープンソースプロジェクトと比較すると、数百（または数千？）の貢献者がいる可能性があります。しかし、彼らがチームであるかどうかは議論の余地があります。 20人の開発者のチームサイズで、おそらくその間に何かの例もあります。
私の質問は、どのような種類のソフトウェアが小さなチームによって開発されるのに最も適しているのか、そしてどのような種類のソフトウェアが大きなチームに適しているのかということです。
Linuxカーネル（多くの開発者によって行われた膨大な量の作業）などの大規模なプロジェクトに取り組んでいる人たちと話すと、彼らはゆるく編まれた小さな「チーム」で働いていることがわかります。既知の貢献者のセットは、通常5未満の特定の機能に取り組んでいます。
そのチームのうち、1つは機能の所有者であり、より大きな機能のチームの一部であり、以下同様に、製品の所有者であるLinusに到達するまで続きます。
それを小さなコマンドーチームと考えてください。これは、ソフトウェアの「分割統治」パターンの組織バージョンです。問題を取り上げて、管理しやすくなるまで小さな問題に分割します。
チームの数とサイズは、機能/製品の「所有者」の経験によって常に決定される必要があります。実行している機能に対して十分な経験を積んだ人がいない場合は、チームを増やすためにもう少し取得するか、タスクを実行するのに十分な時間があるようにプロジェクトをスケジュールします。
チームが大きすぎると、長期的には深刻な問題が発生します（Vistaの開発を調べてください）。
（チームの規模やソフトウェアの種類に関係なく）私が見た実践に関するいくつかの一般的な考え：
- 継続的インテグレーションの姿勢
- 層全体のクリーンなインターフェース（SOAなど）
- 強力なリーダーシップ
- テスト駆動文化
- オートメーション
- 成熟した大人（（必然的に）「古い」ではなく、未熟なジャークではない）
Amazon.comには「2つのピザチーム」があると思います。2、3のピザを食べられるほどの大きさではありません。また、サービス（SOA）にも精通しており、エンドツーエンド（dev＆ops）でサービスを所有しています。 Amazon.comのページは、これらのサービスを何十も利用しています（UIに集約されています）。それらのために働きます。管理しやすい一口サイズのチャンクで構成された巨大なアプリ。
一部のソフトウェアプロジェクトは、その性質上非常に大きいため、小さなチームでは妥当な時間内に実行できませんでした。この例としては、大規模なオペレーティングシステムやデータベース製品があります。
それは本当に数学の問題です。たとえば、今日の標準のオペレーティングシステムでは、250万行のコードが含まれていたかなり単純なものを覚えています。プログラマーが1日あたり100行のデバッグ、テスト済み、および本番用のコード行を生成できると仮定すると（非常に楽観的）、これには1人で25、000日、つまり週7日で約68。5年かかります。
プロジェクト管理には、コストを最小限に抑えるためにチームサイズとプロジェクト期間を最適化する方法があります。もちろん、迅速に市場に参入する必要があるため、企業はプロジェクトをより早く完了させるために、コストの見通しから最適な数よりも多くの人をプロジェクトに参加させることがよくあります。
小規模なプロジェクトで可能な場合は、通常、チームを大きくするよりも小さくする方がよいでしょう。これにより、管理や会議などで無駄になる時間が減り、全員がビジョンを理解して同じページにとどまることが容易になります。
これらの問題を議論する独創的な作品は、Fredrick Brooksによる本 The Mythical Man-Month：Essays on Software Engineering です。