我是一家中型网络托管公司的产品经理，除了网络托管之外，我们还提供各种补充服务。
今天，我们公司有大约 3-6 个开发团队，每个团队致力于不同方面的网络托管（即 DNS 注册、共享托管、云计算、专用服务器、转售等）。
我们已经非常有机地成长，因此用户界面极大地反映了我们公司的组织，而不是我们的客户会觉得直观的内容组织。
除了这个问题，许多后端系统属于每个团队的领域，但也需要被其他团队使用。例如，共享主机团队需要在其面板上使用 DNS 注册服务。另一个例子，一键式网络应用程序安装程序等网络托管功能是由共享托管团队开发的，但我们也希望将它们提供给专门的托管客户。
仅供参考，我们有一个非常注重敏捷方法和极限编程 (XP) 的编程环境。
对于那些拥有与我类似的公司工作/编程环境的人，您有什么解决方案/建议可以使这种安排发挥作用，以便我们可以改善用户体验以及代码的协调和共享，同时也让团队保持独立?
即这里有人用过Scrum of Scrums。如果是这样，您对实施它有什么建议？
Scrum of scrums 的任何替代解决方案？
在编写代码之前，应明确定义接口。如有必要，可以稍后更改接口定义，但这只能通过开发和使用该接口的所有团队的协作来完成。拥有一致的、定义良好的接口有助于封装系统的各个部分，并且可以更容易地重用通用组件或库。良好的封装和模块化是独立团队之间有效代码重用的必要先决条件（我假设使用了某种版本控制系统）。
必须轻松访问最新文档。对于敏捷/XP 环境，我个人的建议是建立一个项目 wiki 以用于中央文档中心。在创建或修改特性/接口/功能时，开发过程的一部分应该是创建或更新该组件的文档。一个开发人员花半个小时来充分记录某件事可以为其他六个开发人员节省半个小时，每个开发人员都试图自己弄清楚。使用 wiki 作为文档可以更轻松地进行快速编辑，允许多个编辑器对一个页面进行编辑，并确保每个人都使用最新的文档（没有可能过时的“本地”文档副本）。
我们已经非常有机地成长，因此用户界面极大地反映了我们公司的组织，而不是我们的客户会觉得直观的内容组织。
当接口不被视为单独的模块化组件时，就会发生这种情况。接口应该插入它下面的功能，但不一定代表底层组织的结构。当通过“黑客”构建界面时，我经常看到这种事情；也就是说，开发人员构建一个新功能并修改 UI 以支持他们的功能，然后下一个开发人员做同样的事情，等等，直到整个 UI 拼凑在一起，没有总体设计目标或原则。不要低估用户界面的重要性或创建高质量、一致的界面的难度。从客户的角度来看，让工程师（或大型项目中的小团队）来设计和维护用户界面可以极大地提高产品的价值。由于客户通常只看到用户界面而看不到任何内部工作，因此界面应该超过团队 1% 的劳动成果。
如果您让所有单独的团队都在同一条轨道上，那么实施“scrum of scrums”结构是相当容易的。每天，每个小组/团队都会举行简短的状态报告/scrum 会议，之后每个小组指定的“领导者”会在“食物链上游”的下一个级别举行另一个 scrum。由于这可以在多个层次结构中重复，因此当小组 scrums 发生在早上的第一件事时，它往往效果最好，并且每个级别的 scrum 都有一个严格而快速的时间限制（通常是 15 分钟，或 2-3 分钟）每个人就足够了）。时间限制有助于防止一个团队超时并延迟他们的领导者参加下一级别的 Scrum 会议等。
我遇到了一些成功运行 Scrum of Scrums 的 CSM，但除非你已经熟悉 Scrum，否则很难管理。
“scrum of scrums 的任何替代解决方案？”
是的。一位建筑师。
架构师的工作——在这种情况下——不是决定架构。
架构师的工作是在团队之间进行协调。定期与大家见面。参加 Scrums，在需要帮助的地方提供帮助。
最重要的是：
充当对变更请求的治理。
在各个团队之间建立共同的愿景。
这需要技术深度来了解正在发生的一切，以及确保每个人都被听到的政治技能。
最后，它需要管理层的支持来执行决策。例如，如果所有开发团队之间的共识是技术 X，而一个团队坚持技术 Y，那么可能是时候让一个团队在另一家公司找到新工作了。
让每个开发人员不断地分配到系统的同一部分会增加产品之间的差异。通过在这些团队中移动开发人员来减少这种情况。它还将减少信息孤岛，并增加他们对他们正在开发的作品如何适应业务的理解。你也不应该过度这样做。
关于系统集成。这些是具有不同需求的不同服务，它们都有自己的上下文。这些应用程序可以专注于自己的上下文，因为这可以减少很多其他问题。
您要做的是确保服务之间有明确定义的集成点。它是关于系统将如何交互以及所涉及的信息合同达成一致。这应该在应用程序级别运行，而不是在数据库级别。它还与操作和信息/情报有关，而不是数据。这是一篇关于企业架构的非常好的文章。
首先，您需要一个版本控制（我假设您已经在使用一个）。确保为每个开发人员设置正确的权限，这样他们就不会“意外”破坏事情。这应该使团队 A 的开发人员能够访问团队 B 的代码。
其次，为了确保 A 团队没有使用来自 A 团队的不可用/不完整的代码，A 团队需要发布一个“可用/良好”的代码供其他团队使用。这可以通过从特定的“可用/良好”修订版分支或仅发送“可用/良好”修订号来完成。
最后，这一切都是为了在团队之间建立诚实和开放的沟通。确保明确定义所有接口和角色。
我同意 S. Lott 的观点。你需要一个有能力的信息/用户体验架构师。这个人应该因为以前从事过创新项目而受到开发人员的尊重。