Scrum of Scrums——问题和价值

Scrum of Scrums——问题和价值

【整理】：Ackarlix
作者 Mark Levison译者 张晓庆

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