Scrum of Scrums——问题和价值

阅读数:1346 2008 年 12 月 22 日

话题:敏捷Scrum精益文化 & 方法

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