回答:
私はスクラムの専門家ではありませんが、AFAIKの「集団的コード所有権」は、チームごとおよび製品ごとのものです（そして、あなたの質問はスクラムに固有ではなく、「共有コード」開発プロセスに適用できると思います）。
2つのチームA、B、2つの製品A、B、および共有コンポーネントCがある場合、考えられるシナリオは異なります。おそらく、共有コンポーネントは主に製品Aに属しています（そして、製品Bのチームによって再利用されていますが、進化していません）。この状況では、チームAは明らかにアーキテクチャのビジョンに責任があります。あるいはその逆：それは明らかに製品Bに属します-したがって、責任があります。チームAが責任を負う場合、チームBはコンポーネントのフォークを使用して緊急のバグ修正を許可する可能性があります（Cのメインラインに再統合する方法もあるはずです）が、Bはコンポーネントのより大きな進化を行わないようにする必要があります。
ただし、製品AとBの両方にCに対する多くの「駆動要件」がある場合は、Cを完全に別個の製品として管理し、独自のバージョン管理、リリース管理、変更管理、単体テストなどと、そのコンポーネントの責任。そのチームは、チームA、B、またはその両方の別々の開発者で構成される単なる「仮想チーム」である可能性があります。このチームには、Cの「共有コードの所有権」と「アーキテクチャビジョン」の責任があります。Cがサードパーティベンダーから提供されたコンポーネントであると考えてください。
スクラムやアジャイルには、「明確な建築ビジョン」という概念はありません。
私は長い間建築家でしたが、建築のビジョンを持つためには、将来の要件を明確に把握する必要があることは明らかです。ほとんどの場合、要件はまったく明確ではないため、固定されたビジョンを持つことは意味がありません。
必要なのは、変化する要件に十分に適応できるアーキテクチャを持つことです。言い換えれば、物事が変わり、アーキテクチャが変わる-私は、再構成可能な「ソフト」アーキテクチャを主張しているのではない。私が今日持っているアーキテクチャはすぐに時代遅れになり、変更する必要があることを受け入れることについて話しているので、だれもそれと「やりとりする」べきではありません。
集合的なコードの所有権とは、誰もが-理論的には-何でも変更できる必要があることを意味します。これは「サイロの反対」として理解する必要があります。言い換えれば、スキルバリアが存在する可能性がありますが、これは正常で予期されることです-誰もがSQLクエリを微調整して、例を示すことができる経験豊富なDBAであるとは限りません-しかしこれからは、DBAだけが実行できるとは限りませんクエリを手で最適化します。他の人々が熟練するのを助けることができる「機能ドメイン専門家」がいますが、タスクはまだ誰にでも落ちるはずです。
たとえば、私が機能 "A"のドメインエキスパートである場合でも、他の誰かが機能 "A"で作業することを期待していますが、大きな変更が必要な場合や人々の助けが必要な場合は、相談を受ける可能性があります。機能「A」は確かに私の機能ではありません。それは私がよく知っている特徴でしょう。もっと多くの機能を知ることは私の興味であり、この機能を知ることは他の人の興味です。
合成では、要件が出現して変化するにつれて、開発者はアーキテクチャを何度も設計および再設計します。誰もが自分のスキルに応じて必要な変更を行い、いつ助けを求めるべきかを知っていることが期待されています。私たちは人々を信頼し、要件を信頼していないため、アーキテクチャに関する長期的なビジョンはありません。
たとえば、spotifyは「システム所有者」という名前のロールを使用して、ドキュメントから直接問題を解決します。
技術的には、誰でも任意のシステムを編集できます。チームは実質的に機能チームであるため、通常、新しい機能を実稼働させるには、複数のシステムを更新する必要があります。このモデルのリスクは、システム全体の整合性に誰も焦点を当てないと、システムのアーキテクチャがめちゃくちゃになることです。
このリスクを軽減するために、「システム所有者」と呼ばれる役割があります。すべてのシステムには、システム所有者またはシステム所有者のペアがいます（ペアリングをお勧めします）。運用上重要なシステムの場合、システム所有者はDev-Opsペアです。つまり、開発者の視点を持つ1人と運用の視点を持つ1人です。
システム所有者は、そのシステムに関連する技術的またはアーキテクチャ上の問題の「後任者」です。彼はコーディネーターであり、そのシステムでコーディングする人々がお互いにつまずかないように指導します。彼は、品質、ドキュメント、技術的負債、安定性、スケーラビリティ、リリースプロセスなどに焦点を当てています。
システム所有者は、ボトルネックや象牙の塔の建築家ではありません。彼は個人的にすべての決定をしたり、すべてのコードを書いたり、すべてのリリースを行う必要はありません。彼は通常、チームのメンバーまたはチャプターリーダーであり、システムの所有権に加えて、他の日常的な責任も持っています。ただし、時々彼は「システム所有者の日」をとり、そのシステムのハウスキーピング作業を行います。通常、私たちはこのシステムの所有権を1人の時間の10分の1未満に維持しようとしますが、システムによって大きく異なります。
私はこのアイデアが本当に好きで、会社レベル（チームレベルだけでなく）でメリットやコードの所有権を共有していますが、このシステムの所有者はアーキテクチャの整合性を確保しようとしています。
完全なドキュメントへのリンク：https : //dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf、これはアジャイルのスケーリングに関する実際の経験に基づいた、短くて非常に興味深いドキュメントです。
これは解決するのが難しい問題であり、開発方法論ではなくプロジェクト管理方法論であるスクラムでは確かに解決されません。
私が見つけた最も効果的なソリューションは、優れたパッケージ管理（nuget / gem / etc）とバージョン管理です。他のチームが変更を使用する準備ができるまで、変更を強制しないでください。新しいビルドに移行する間、古いビルドを使い続けさせます。
どの変更が壊れているか、どの変更が拡張であるかを明確にするバージョン管理戦略があることを確認してください。
また、変更を加える場合は、コードレビューを各チームの誰かにプッシュします。彼らがそれを消費するように強制されるずっと前に、彼らが彼らに影響を与える可能性があることを彼らに見てもらいましょう。
そして、物事が本当に乱雑になると、あるチームが変更を行う必要があり、別の変更を簡単に利用できない場合（これは本当にまれなケースです）、コードを分岐し、まったく別のパッケージにしますが、できるだけ早く共通のコードに戻ることを優先します許可します。
常に明確であるとは限らない答えは、特定のコンポーネントをどのように共有するかをチームに決定させることです。
たとえば、私のチームは最近、長い間類似の製品を開発してきた他の2つのチームと多くのコードを共有する新しい製品ラインの開発を始めました。当社の製品はいくつかの点で異なります。そのため、共通のコードにカスタマイズポイントを追加する方法を見つける必要がある場合があります。
そのコードについていくつかの衝突があり、共通の所有権を扱ういくつかの異なるアドホックな方法を試しました。次に、大きな新機能が登場したため、すべてのチームをまとめて同じページを表示する必要があると判断しました。その結果、詳細を検討している各チームのカップルメンバーで構成される小さなグループができました。
私たちのチームが考え出したソリューションは、別の状況では機能しない可能性があります。もっとシンプルなもの、またはもっとフォーマルなものが必要かもしれません。重要なのは、あなたは集団的所有権を取り、自分にとって何がうまくいくかを理解することです。
私は自由に仮定します：
上記の仮定が正しければ、2つのチームが互いに干渉することはまれにしかありません。彼らは次の方法を使用してそれを解決できます：