何百人もの開発者が単一のソリューションに取り組んでいるときの開発方法論？

私たちは約200人の開発者で構成される組織であり、特定の日にリリースされる予定の1つの製品（リビジョン管理Gitを使用）で継続的に作業しています。

開発者が非常に多いため、各チームに約10人の開発者がいる「クロスファンクショナル」チームを作成しようとしています。その結果、組織内に約20の開発チームができます。

メインリポジトリ内の製品の継続的な「高水準」（開発者がプルするとき、製品が少なくともコンパイル可能であることなど）を維持したいので、何らかの品質ゲートを使用したいと思います。

質問の言い方が少しわかりませんが、単一の製品に取り組んでいるこのような大規模な開発者グループの開発方法論に関するアドバイスを得ることができるかどうか疑問に思っています。

私たちの意見では、スペクトルの一端は各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があることを恐れていますコミットごとに厳しい「品質ゲート」を持つことはできません。

スペクトルのもう一方の端は、（メインリポジトリ）に3つのプルソースのみがあり、これら3つに少数の信頼できるプルソースのみがあるツリーまたはピラミッド構造のようなものです（Linus Torvalds / Linuxが行うと思います）しかし、そのような構造では、変更が「メインリポジトリ」に入るために登るには長いチェーンがあると感じています。さらに、マージの競合が発生した場合、「元の開発者」以外の別の開発者に問題が発生します。

この背景情報と意見をすべて述べた上で、非常に多くの開発者に推奨される開発方法論をどのように学び、読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのように開発を構成していますか？

確かに、製品をモジュールに分割して、それらを構成するモジュールを製品に統合するインターフェイスチームを検討する必要があります。これは、モジュールのパーティションと階層に一致するようにリポジトリを分割することを意味します。これができないと思われる場合、プロジェクトはおそらく、貢献している開発者の数を考慮して、マージに起因する停止に粉砕されます。

バージョン管理にGitを使用する場合は、コードレビューシステム（Gerritなど）を使用して、各リポジトリの透明性を高め、品質を確保することをお勧めします。そうすれば、すべての作業を承認されたリポジトリにマージする前に承認する必要があります。このシナリオでは、特定の信頼できる個人に、コードレビューシステム下のレポから別のリポジトリ（おそらくコードレビューシステム下）にプッシュする許可を与えることは理にかなっています。正しく使用すれば、これは開発プロセスを妨げない、高速で非常に有益なプロセスになるはずです。

ビルド検証に関しては、コードの自動ビルドと検証を目的とする継続的統合（CI）サーバーが必要です。コードを検証するということは、コードが正常にコンパイルされ、テストに合格することを意味します。Infact Jenkins（CI Server）は、Gerrit検証段階の一部としてGerritコードレビューシステムにリンクして、プロセスを完全に自動化できます。

これらの統合ツールに加えて、開発方法論の一部として頻繁な統合に努め、時間のマージを最小限に抑えることが重要です。

スクラムのようなアジャイル開発プロセスを検討する価値があるかもしれません。その目的は、複雑な製品を管理可能な製品増分のチャンク（スプリントと呼ばれる）に分割することです。これらは、リポジトリ間の統合の機会を提供します。

明らかに、200人の開発チームで、ある種の階層構造が必要です。個人または少数の人々が、ソフトウェア製品の設計について決定を下しています。開発プロセスにはこれを反映する必要があります。作成するソフトウェアが実際に作成したいものと一致することを確認するために、コードレビューとテストを実施する必要があります。

小規模なチームでさえ、個々のコンポーネントを開発する際にチームを導き、作業をレビューするリーダーが必要です。チームレベルでも品質管理プロセスを実施する必要があります。

したがって、はい、リポジトリに関して階層構造に従う必要があります。これは、プロジェクト全体の階層構造を一致させるためです。

個々のコンポーネントを構築し、それらをすべてまとめることを考える前に、ある程度の妥当性をテストする必要があります。200人の人々がメインプロジェクトに直接コミットできるようにすることは混乱です。プロジェクトのメインビルドに影響を与えることなく、個人が日々の変更をコミットできるグループごとに個別の領域を用意する必要があります。

「変更がメインリポジトリに到達するために登るのに長いチェーンを持っている」場合、このチェーンを使用すると品質を確保できるため、非常に良いことです。すべての変更がすぐにメインリポジトリに適用されると高速に見えるかもしれませんが、ソフトウェアのメインビルドが常にバグが多く使用できないため、これは大きな頭痛の種になります。

また、「マージの競合が発生した場合、問題が別の開発者に降りかかる」ことも良いことです。具体的には、競合の解決方法を決定するのは、より高いレベルの開発者でなければなりません。

大きなものがあり、（結果として）管理不能な場合は、それを小さく管理しやすい部分に分割します。

チームとプロジェクトをより良く維持するのに役立ついくつかの手順があります。

1. 機能をモジュールに分割します。機能は、高い凝集度、低い結合、および依存関係の反転原理を使用して、独立した最大限のモジュールに分割する必要があります。最初の原則は、論理的に一貫したモジュールを作成するのに役立ちます。2番目は、これらのモジュールを可能な限り独立した状態に保つのに役立ちます。3番目のものは、依存モジュールを同時に開発するのに役立ちます（モジュールAがモジュールBに依存している場合、Bは、Bが完全に準備できていない場合でも使用できるインターフェースを提供する必要があります）。

2. 明確なドキュメントがあります。一緒に働いている人がたくさんいると、物事は簡単に忘れられたり誤解されたりする可能性があります。そのため、要件からアーキテクチャソリューションまで、すべてのドキュメントに特別な注意を払う必要があります。

3. タスク用の人（人用のタスクはありません）。機能を小さなセットに分割した後、これらのセットで作業するチームを作成します。各チームが何に取り組むべきかを既に知っているので、この段階でチームを作成するのは簡単です。また、コードレビューなどのタスクは各チーム内で行われます。

4. タスクのシステムを明確にします。200人の開発者はそれぞれ、何に取り組むべきかを明確に知っている必要があります。これにより、すでに行われた作業、各担当者の作業内容、残っている作業量を追跡できます。

5. ソース管理。（私はこれが他の回答で非常によく概説されていると思います）））

そして最後に、できるだけ単純なチームとモジュールの構造を作成してみてください。このような巨大なプロジェクトでは、複雑な余裕はありません。

階層構造を示唆する他の回答に加えて、階層内でコードを上に移動して「すべてをまとめる」ことに焦点を当てる「統合」時点をスケジュールする必要があることを意味します。これは、テストとバグ修正以外の作業を行わない最終段階の小規模なプロジェクトと大差ありません。あなたは高水準を目指して大規模なグループで働いているので、そのほとんど（心の枠組み）はおそらく既に整っているでしょう。

hotpotatoの答え（これはIMHOのマークに直接記載されています）に加えて、いくつかのソースコントロールゲートを実装することもお勧めします。大規模なチームとコードベースをSCMのgitに移行したとき、説明したモデルに似た「慈善的な独裁者」と呼ばれる方法を使用することにしました。

このシナリオには、ソースブランチから定期的に更新される完全なコードベースのさまざまなブランチが多数ありますが、コードをより目に見える/パブリックエリアにプロモートする責任は1人（または少数の人々）にあり、通常はコードレビュープロセスに関連付けられています。よく組織化された分岐構造により、これは本当にうまく機能します。詳細については、このリンクをご覧ください。

私は、数百人の開発者が約1億5,000万SLOCで同時に作業する巨大なシステムに取り組んできました。これはメインフレーム上で行われたため、Visual Studioについて話しているわけではありませんが、原則は引き続き採用できます。

まず、Javaを使用している場合、Mavenを使用することは間違いありません。VSを使用している場合、Nugetを使用することもできますが、Mavenにまだあるかどうかはまだよくわかりません（多少異なります）。このようなシステムを使用すると、依存関係を引き出して、個別に機能させることができます。ビルドスクリプトを使用して、関連する依存関係を取得し、バッチとしてビルドします。

あなたが直接質問をするのではなく、方法論を尋ねるということを考えると、私の以前の雇用主がそれをどのように扱ったかを説明します。

システムはクラスターに分割されました。クラスターは、ビジネスエリアとシステムインフラストラクチャエリアを表しています。名前は付けませんが、巨大な小売業では、マーケティング、小売業、オンライン業務、調達、流通などを考えることができます。システムインフラストラクチャは、顧客やセキュリティなどを表しています。各クラスター内には、コンポーネントがありました。前の例えを使用すると、たとえばシングルサインオン、ディレクトリサービス、監査、レポートなどのセキュリティのコンポーネントを検討できます。各コンポーネントには、関連するルーチンが格納されていました。

名前空間またはパッケージとして、たとえばOrganisation.Security.DirectoryServicesがあります。関連する領域にすべてのロジックを含めることにより、チームはかなり自律的に作業しました。明らかに、複数のチームからの入力を必要とする大規模なプロジェクトが発生しましたが、それらは主にスムーズな運用でした。

これがお役に立てば幸いです。