大規模なプログラミングチームで働くのはどうですか？

私はいつも小さなプログラミングチームで働くことができて幸運だと感じてきました。私が取り組んできたのは、11人のプログラマーだと思います。何百人もの開発者がいるプロジェクトに取り組むのはどうですか？何千？スケールとは何ですか？

編集：すべての応答をありがとう！ポジティブなものはほとんどないようです：

• 巨大なコードベースで作業可能
• より良い社内キャリア開発
• 虐待的な管理に対する従業員の保護（これは、大規模な+ veよりも小規模な-veの方が多い）

大規模なチームに他の利点はありますか？

官僚主義の規模は実にうまくいくと思います。

それ以外は、全体ではありません。大規模なプロジェクトには大規模なチームがあります。他の方法はないからです。開発者ごとに効率が上がるからではありません。非効率の観点から2人目をミックスに追加するとすぐに、コストを支払います（つまり、知識の伝達とコミュニケーション）。

私が取り組んだ最大のプロジェクトには、5つの異なるサイトに70人ほどの開発者がいました。1行の変更でも1日以上かかりましたが、これは、チューリッヒからロンドンまでのネットワークリンクを介してビルドが45分以上かかり、アプリの起動にさらに45分かかったためです。チェックインはファイルごとに約5分かかりました。冗談じゃないよ。ロンドンの開発者は、ほんの少しの時間でこれを行うことができました。

とにかく、あなたが見つけやすいのは、大規模なプロジェクトでは、あまりやり取りしないチームメンバーがたくさんいるということです。それは、ミニプロジェクトの緩やかに関連するコレクションのようなものです。Microsoftの開発は、Microsoft Officeのような大規模なプロジェクトであっても、プロジェクトを5〜7人の開発者のチームに分割する傾向があることを一度読んだことがあります。

違いの一部は、中小企業と大企業の違いでもあります。大企業はプロセスが増え、ルールが増え、柔軟性が低下する傾向があります。しかし、それは決して保証されません。

しかし、それはキャリア開発に適しています。小さな会社では、昇進する前に誰かが退職するか死ぬ必要があります（または、会社が成長してチームが拡大し、上に移動する必要があります）。

さらに、あなたは自分自身を愛し、そこから学ぶ優秀な人を見つけることができます。小規模な企業では、非常に孤立し、自立していると、プログラマーがやや「奇妙」になり、隠者のようになります。

コミュニケーションは、チームの規模が大きくなるにつれて低下し始める最大の問題であることがわかりました。コミュニケーションをとることが難しくなり、全員が同じページにいることを保証するのが難しくなります。私は約75人の開発者からなるチームで間接的に働いており、共通のコードベースを使用していますが、75人の多くは個々の「アクティビティ」のために小さなグループに分かれています。私たちにとって、コミュニケーションはまったくの悪夢です。

大規模なグループの管理も難しくなります。8〜12人の管理者が追加された後のほとんどの環境では、残念ながら、個々のサブセットが途切れ始める「サイロ」タイプの環境を作成するため、コミュニケーションの問題を誇張するだけです。大規模なグループとそのグループ内の知識を維持しようとします。

武器システム用のソフトウェアを作成したとき、ソフトウェア開発者の大規模なチームがいました。誰も要件（一部は分類されている）に頭を包むことはできないため、それはすべてチームとチーム同士の相互作用に関するものでした。

1. 構成管理-夜間のビルドプロセス-は非常に大きな問題でした。当時は、毎晩世界を再コンパイルするために大規模な分散コンピューティングクラスターが必要でした。

2. 作業の承認、およびプロジェクト全体のマスタースケジュールで正しいラインアイテムに時間を請求することは、大きな苦痛でした。0.1時間まで 増分。

しかし、最大の問題は変更通知でした。特にインターフェースの変更。

これはとても重要で、彼らはこのクレイジーな2層プロセスを発明しました。努力の大部分は、インターフェース変更通知要求（通知自体ではなく、通知要求）がデータベースとレポートなどを備えた精巧なサポートソフトウェアを持っていることを確認することに費やされました。

要求が承認されると、実際の通知は多かれ少なかれ言うまでもありませんでした。これは実際には1層プロセスであり、リクエストは事実上通知であったことを意味します。しかし、ウォーターフォール開発を行う場合、開発者が登場するまでにすべてを長時間考慮する必要があります。

非常に多くの人々が並行して働いているため、構成管理委員会がありました。さまざまなチームマネージャー全員と、仕事をする人々のグループは、単に変更を調整するだけでした。

私の最初の「本当の」プログラミングの仕事は、他の軍隊と協力して国際航空交通管制システムを開発することでした。これは非常に成功した取り組みであり、Capability Maturity Model Level 5環境と見なされました。それ以来、中小の店に行ってきました。それで、どちらがベストな場所ですか？個人的には、私はいつでも巨大な店よりも小さな店を選びます。レベル5を聖杯と見なす人もいるかもしれませんが、私にとっては息が詰まるようなものでした。誤解しないでください、特に航空交通管制と同じくらい重要なシステムの場合、私は間違いなくその価値を見ますが、問題はあなたがどのように過ごしたいかです日？あなたは物事を思い描いてそれを実装できる自由を望んでいますか？または要件に書き込みたいですか？おそらく、ATCシステムを長く使用していた場合は、設計と開発ができるレベルにまで上昇したかもしれませんが、それでもX年、Y承認、Zプロモーションが必要です。逸脱する可能性はありません。息苦しかった。

最後に、一般的に私は、中小企業では隠れることができないという理由だけで、開発者の質がはるかに高いと感じています。非常に大規模な会社では平凡であるのは難しくありませんが、小さな会社では痛々しいほど明白になり、多くの場合、長続きしません。

少なくとも数百人の開発者がいる組織で（簡単に）働いてきました。しかし、もちろん（？）、組織は内部的に分割されているため、1人の従業員として、他のすべての従業員と直接連絡を取ることはできません。

その特定の場所で、ソフトウェアはコンポーネントに分割され、コンポーネントの周りにチームが形成されました。一部のチームは単一の（大規模な）コンポーネントのみで作業しますが、多くのチームは多数の（小規模な）コンポーネントを担当していました。

もちろん、これは非常に大きなコードベースでの作業が行うすべてを意味します。構成管理、構築、統合などのようなものは、重要な大きなものになり、専門の専任部門によって順番に行われます。すべての開発部門の出力を収集し、定期的に（私が働いていた週に1回）実際に機能する1つのまとまりにまとめて統合できるため、彼らはfor敬の念を抱きます。

プログラマの大規模なチームで働いたことはありませんが、組織の規模が大きくなった結果、通常はルールが増えます。これは必ずしも悪いことではありません！すべての人の生活を困難にする規則に加えて、従業員を保護し、良好なプロセスを確保するための規則もあります。

小規模な組織のマネージャーが、企業の人事部門によってすぐに解雇されてしまうような事態に対処するのを見てきました。

大きなプロジェクトで私が気づいた1つの違いは、オフィスの政治です。プロジェクトが大きいほど、政治は支配的です。

私が学校を出た最初のプロジェクトは、数百人の開発者でした。生意気で素朴なデベロッパーとして、学校に行ったばかりの私はその準備ができていませんでした。私hineyを保存した唯一のものは、（それがされます唯一のものです今まで本当にあなたを守る）私が作った友人の量でした。

それは私がそこから学んだ最大の教訓です。みんなと仲良くしよう。ジャークでさえ。特に、仕事を1分間停止し、今まで話したことがない人と会話する機会がある場合は、それを行います。

私はかつて、1年に500人以上のチームで働いていましたが、そのうちの約200人は開発者でした。EOAを提供し、いくつかの異なるSOAソリューションを統合していました。

実際には、30人から50人のチームがあり、それぞれがさまざまな数のプログラマ（私たちのチームでは3人）を持ち、それぞれが成果物全体の異なる側面を担当しています。

私がこれまで取り組んだ最大のチームは約15人でした（これは、異なる会社で3か月または4か月のみでした）。私はチームのテクニカルリードであり、午前7時に仕事を始めました。他の全員が参加するかなり2時間前になりました。それが、自分のタスクを完了する唯一の方法でした。

8人または10人以上の開発者がいるチームには働きたくありません。15人は1つのチームには多すぎます（チームは残念ながら2人に簡単に分割できたはずですが、残念ながら3人または4人の開発者は素敵な快適なサイズ私見