Answers:
我不是Scrum专家，但是AFAIK“集体代码所有权”是针对每个团队和每个产品的（我想您的问题并不特定于Scrum，它可以应用于任何“共享代码”开发过程）。
如果您有两个团队A，B，两个产品A，B和一个共享组件C，则可能存在不同的情况。也许共享的组件主要属于产品A（产品B的团队只是对其进行了重用，但并未演化）。在这种情况下，团队A显然负责架构构想。反之亦然：它显然属于产品B-因此，责任就在这里。如果团队A负责，则团队B可能会使用该组件的分支来进行紧急错误修复（也应该有一种将它们重新集成到C的主线中的方法），但是B应当避免对该组件进行任何较大的改进。
但是，如果产品A和B对C都有很多“驱动要求”，则您应将C作为完全独立的产品进行管理，并具有自己的版本控制，发布管理，变更管理，单元测试等，并由一个单独的团队来负责该组件的责任。该团队可能只是一个“虚拟团队”，由来自团队A，B或两者的独立开发人员组成。这个团队对C拥有“共享代码所有权”，并且对“架构远景”负有责任。试想一下，C蜂是由第三方供应商提供的组件。
Scrum或敏捷中没有“清晰的建筑视觉”的概念！
我长期以来一直是一名建筑师，对我来说很清楚，要想拥有建筑远景，就需要对未来的需求有清晰的认识。由于在大多数情况下这些要求根本不清楚，因此没有固定的愿景是没有道理的。
所需要的是一种足以适应不断变化的需求的体系结构。换句话说，事情发生了变化，架构也发生了变化-我并不是在提倡可以重新配置的“软”架构。我说的是接受今天的架构很快就会过时并且需要更改，因此没有人可以“嫁给”它。
集体代码所有权意味着，从理论上讲，每个人都应该能够更改任何内容。必须将其理解为“筒仓的对面”。换句话说，可能存在正常的和预期的技能障碍-并非每个人都是经验丰富的DBA都可以对SQL查询进行微调，以举一个例子为例-但这并不意味着只有DBA可以手动优化查询。将有一个“功能领域专家”可以帮助其他人变得精通，但是任务仍然应该落在每个人身上。
例如：如果我是功能“ A”的领域专家，那么我仍然希望其他人可以从事功能“ A”的工作，但是当需要进行重大更改或人们需要帮助时，我可能会被咨询。功能“ A”当然不是我的功能。这将是我很了解的功能。了解更多功能将是我的兴趣，了解此功能将是其他人的兴趣。
综合来说：随着需求的出现和变化，开发人员多次对体系结构进行设计和重新设计。每个人都应根据自己的技能进行必要的更改，并知道何时寻求帮助。对架构没有长远的眼光，因为我们信任人们并且我们不信任需求。
例如，spotify使用名为“系统所有者”的角色直接从文档中解决问题：
从技术上讲，任何人都可以编辑任何系统。由于小队是有效的要素团队，因此他们通常需要更新多个系统才能将新要素投入生产。该模型的风险在于，如果没有人关注整个系统的完整性，那么系统的体系结构就会混乱。
为了减轻这种风险，我们有一个名为“系统所有者”的角色。所有系统都有一个系统所有者，或一对系统所有者（我们鼓励配对）。对于关键业务系统，系统所有者是一对Dev-Ops，即一个人对开发人员的观点和一个人对操作的观点。
系统所有者是与该系统有关的任何技术或体系结构问题的“执行者”。他是协调员，并指导在该系统中进行编码的人员以确保他们不会彼此绊倒。他专注于质量，文档，技术债务，稳定性，可伸缩性和发布过程等方面。
系统所有者不是瓶颈或象牙塔建筑师。他无需亲自做出所有决定，编写所有代码或发布所有版本。他通常是小分队成员或分会负责人，除了系统所有权外，还承担其他日常职责。但是，他有时会参加“系统所有者日”，并在该系统上进行内部管理工作。通常，我们试图将这个系统所有权保持在一个人的时间的十分之一以内，但是在不同的系统之间，它的差别很大。
我真的很喜欢这个想法，在公司级别（不仅在团队级别）而且在系统所有者尝试确保某些体系结构完整性的同时拥有收益或集体代码所有权。
完整文档的链接：https : //dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf，这是一篇简短但非常有趣的文档，基于有关敏捷扩展的实际经验。
这是一个很难解决的问题，Scrum当然不能解决，Scrum是一种项目管理方法，而不是开发方法。
我发现最有效的解决方案是良好的软件包管理（nuget / gem / etc）和版本控制。在他们准备好使用另一个团队之前，切勿对其进行强制更改。当您迁移到新版本时，让他们继续使用旧版本。
确保您具有一个版本控制策略，该策略可以使哪些更改正在中断，哪些是扩展。
另外，当您进行更改时，将代码检查推送给每个团队中的某人。让他们看看在可能被迫消耗掉它们很久之前，它们才可能影响到他们，以便他们可以在顶部实现自己的更改。
而且，当事情变得非常混乱时；当一个团队需要进行更改而又不能轻易使用另一个更改时（这种情况很少见），可以分支代码，使其成为一个完全不同的程序包，但是应优先考虑尽快恢复通用代码允许。
答案并非总是那么显而易见，是让团队决定如何共享任何给定组件。
例如，我的团队最近开始开发新的产品线，该产品线与已经开发了很长时间的其他两个团队共享许多代码。我们的产品在某些方面有所不同，因此我们有时不得不找出将定制点添加到通用代码中的方法。
我们对该代码有一些冲突，并尝试了几种不同的临时方法来处理通用所有权。然后，随着一个新的大型功能的出现，我们决定需要将所有团队聚集在一起以使他们在同一页面上，这导致了一个较小的小组，由每个小组的两名成员组成，他们正在研究详细信息。
我们的团队提出的解决方案可能在其他情况下不起作用。您可能需要更简单或更正式的东西。关键是，您拥有集体所有权，并找出最适合您的方法。
我将自由假设：
如果以上假设是正确的，那么仅偶尔会有两支球队互相干扰。他们可以使用以下方式解决此问题：