Scrum of Scrums——问题和价值

Mike Cohn （《敏捷估计与规划》一书的作者）认为，Scrum of Scrums（SoS）会议“是把 Scrum 扩展到大型项目团队的一件利器。这些会议可以让多个团队讨论他们的工作，尤其关注工作重叠和集成的领域。”

Allan Shalloway 正在写一本新书《 Lean Software Development: Scaling Agile to the Enterprise 》， 他在以下方面征求过大家的经验："使用 Scrum-of-Scrums 协调团队（我已经有成功经验），把 Scrum 扩展到企业级别（很多人告诉过我由于多 种原因，他们没有成功）。”Alan 发现，当大型团队（有个例子中多达 350 人）使用 Scrum 时，问题悄然出现。这个案例中，多个产品共用一些通用的组 件。他引用了发生的 3 个问题作为例子：

• 技术方面。由于我们采用迭代开发，团队满怀信心地遵守自然设计（emergent design）的原则。这意味着我们编写高质量的代码，但是只有必要的时候才会增加功能或者设计结构。团队 A 可能写了一个加密器，因为只有一个地方在用， 他们就没有使用接口。团队 B 可能后来也需要一个加密器，但与团队 A 的稍微不同。对组织来说最好的办法是让团队 A 修改代码，使用接口——而这在以前是不需要 的。首先，很可能团队 B 并不知道已经有了这个东西。即使他们知道，团队 A 也未必乐意修改代码帮助他们。
• 跨团队方面。当不同的团队有不同的产品负责人和 Scrum Master 时，团队见如何一起工作并不是那么显而易见。再说一次，着眼大局会很有用。当一个组件团队同时支持其他数个团队时尤其有用。驱动商业价值需要所有的产品负责人参与。他们可能相互合作，也可能不合作。
• 团队结构方面。当 多个 Scrum 团队参与交付端到端的功能时，会遇到严重的问题。我曾见过 3 个独立的团队，一个负责用户界面，一个负责中间层，另外一个负责数据库。当他们 根据功能重组成 3 个不同的团队时，他们变得有效率得多。组织里面的人仍然干差不多相同的活，但是现在能够关注整个功能，而不是某一层上功能的一部分。这虽 然会引起团队间一些集成的问题，但是会使端到端的功能实现得更快。这也是 Bas Vodde 和 Craig Larman 在“ Choose Feature Teams over Component Teams ”这篇文章中推荐的。

Mike Dwyer 说，应该由 SoS 和 Meta Scrums：“负责协调故事的分解，这样多个团队就不会有相同的问题了。这些事情应该由各个层次上的日常对话解决。”他的经历是，团队经过良好的训练，关注基础结构、数据和架构，最终共享部分的代码做得很好。最后他说, 最关键的是让管理层和产品负责人共同工作，并定义发布的主题，这样需要时可以给团队指导和支持。

Ilja Preuß说，SoS 给他的团队带来了这些价值：“它让我们了解系统中其他团队发生了什么；它确定什么条件下我们互相帮助；它确定什么条件下团队需要协调；它还让我们同舟共济，并保证每天每个团队的至少一个人能够看到任何其他团队的一个人，保持大家互相联系。”

Christophe Louvion 也使用 SoS 来管理跨项目团队的每日集成，由子项目的高级工程师组成 meta team，并负责：

• 设置标准（应用程序接口、服务水平协议、错误日志、代码库结构、自动编译流程、所有团队使用的自动部署脚本等等。）
• 每日集成测试（自动的）
• 跨子项目的代码 / 架构检查
• 主要版本发布的早期，该团队应就未知的解决方案，在多个团队间发起一套基本的设计测试

SoS 团队实际上启动得最早，并准备好 Scrum 扩展的环境。这个团队的成员非常高级。随着时间推移，SoS 中的每个成员成为子项目团队的带头人，同时在 SoS 层和子项目层工作。

最后 Walter Bodwell 分 享了 SoS 的成功秘诀：“保持会议简短，最长 15 分钟；抓住重点，别人最想 / 需要听的是什么？SoS 会议中回答的前两个问题，可以让别人了解你正在做什 么，非常有助于合作。他们可以给一些建议，让你注意一些事情等等。但是讨论应该分成单独的会议，使它简短、有重点。每次 SoS 会议上都提出被阻塞的问题， 直到解决为止。识别、敦促被阻碍的人是 SoS 最大的好处之一”。由于 SoS 经常跨时区举行，并且可能有口音问题，他发现事先准备简短的记录给大家会很有帮 助。

查看英文原文： Scrum of Scrums - Issues and Value