总结

在本章中，你学习了如何利用团队结构和沟通流动对软件和系统架构的影响，来执行逆Conway机制。这有助于你实现一个松耦合的架构，构建可独立测试和部署的单元，从而对软件交付性能产生积极影响。

在接下来的章节中，我们将更多地关注“构建什么”，而不是“如何构建”。你将学习精益产品开发，并了解如何将客户反馈融入到你的工作中。

案例研究

在经历了前三个成功的冲刺之后，Tailwind Gears的更多团队被迁移到新平台。最初的团队被选中负责一个已经可以独立测试和部署的产品。尽管包含了Scrum Master、产品负责人和QA成员，这些团队对于“两比萨法则”来说有点大，但这个问题稍后会解决。接下来的团队规模则过大，他们处理的是大型的单体应用，并且有很多相互依赖。为了执行逆Conway机制，所有团队聚集在一起，自我组织下一批将迁移到新平台的团队。以下是相关的约束条件：

  • 团队不超过两比萨团队的规模

  • 负责一个可以通过StranglerFigApplication模式提取并且能够独立测试和部署的业务能力（边界上下文）

这有助于推动应用设计的演化。新的微服务是云原生的，拥有自己的云原生数据存储。它们通过API和事件驱动架构集成到现有应用中。微服务被迁移到新平台上的各自独立仓库，因为它们大多数时候是独立部署的。团队之间的同步通过功能标志来完成。

对于嵌入式软件，这种做法无法实现。团队需要一种能够构建和部署整个应用的方式。但他们也希望能够单独部署和测试各个模块。因此，团队决定将应用程序拆分成不同的仓库，并拥有一个包含其他仓库作为子模块的元仓库。这使得各个团队可以随时将他们的模块部署到硬件上，在实际场景中测试新功能——但同时保持产品处于可以随时发布的状态。

当最初的团队迁移到新平台时，他们保持了原有的三周冲刺周期。由于这些团队大致可以独立工作，因此这并不成问题。随着更多团队迁移到新平台，冲刺周期会与其他团队对齐。Tailwind Gears是一家上市公司，通常会按季度进行所有业务报告。他们还会按周进行报告，并使用标准的4-4-5日历。在每个季度的结束和开始时会有很多会议，这些会议常常与冲刺会议发生冲突。团队决定将他们的冲刺节奏调整与这一节奏同步。季度由13周组成，但其中有一周用于季度会议，所以这一周会从冲刺日历中剔除。这一周还用于季度的大房间规划。剩下的12周则分成6个两周的冲刺。

进一步阅读

以下是本章的参考资料，你可以通过它们获取更多关于这些主题的信息：