BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷团队运用“Scrum of Scrums”进行协调与合作

| 作者 Ben Linders 关注 20 他的粉丝 ,译者 李彬 关注 1 他的粉丝 发布于 2014年3月12日. 估计阅读时间: 10 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

当项目或产品开发过程中涉及到多支团队的时候,可以使用Scrum of Scrums来扩展每日立会——其用途在于,帮助敏捷团队面向其他团队协调与合作其工作。针对Scrum of Scrums,许多作者分享了各自的看法以及使用的经验。

Charles Bradley撰写了一篇关于拯救备受争议的Scrum of Scrums的博客文章,在其中描绘了对于同一个产品开发中共事的多支团队,Scrum of Scrums如何帮助他们(重新)规划并协调开发工作:

我相信并且亲身体验过专注于开发团队的方法:在团队层面,遵从Scrum背后的原则,遵从每日Scrum实践的原则,最终以更快的速度向客户交付了更多的价值。在我的经验中,针对开发团队并由其进行实践的高效的Scrum of Scrums,将极大的提升开发团队的自组织技能,更快速地消除阻碍,产出更高质量的产品,并在更短的时间内交付更高的价值。

对于Scrum of Scrums,Charles在他的博客文章中收集了来自Ken Schwaber、Mike Cohn、Craig Larman、Bas Vodde以及Jesse Houwing等人的观点。他的结论是,Scrum of Scrums应该专注于帮助开发团队的成员们按照自组织的方式协调与合作,而不应该成为Scrum Master们的状态会议。

在我辅导Scrum团队的时候,特意强调了在扩展Scrum时要遵从其基本原则。我鼓励Scrum Master们(如果他们参加Scrum of Scrums的话)站在开发团队成员的“圈子之外”,并避免与开发团队成员进行目光接触——因为后者正在进行协作。我相信基于原则的扩展,因此针对各支开发团队的每日Scrum,我在面向Scrum Master们进行培训时也贯彻了相同的技术。我希望开发团队成员能够得到授权,在其协调与合作的努力中真正进行自组织。是的,当然我也会指导Scrum Master成为“仆人式领袖”,以便根据需要发挥作用——但我还鼓励他们,当开发团队自身能够拥有高效的Scrum of Scrum时,尽快退居幕后。

在另一篇题为有效的Scrum产品组织机构模式(第二部分)的博客文章中,Robert Galen为大型产品开发机构提供了一套解决方案,用来将团队的Scrum of Scrums与团队栖身的产品开发机构关联在一起。在他看来,可以从三个层面建立起这样的关联:

  1. 在最低层:每支团队都拥有一位产品所有者;他们结合各自团队的能力,使用产品待办事项列表来推动其工作。
  2. 在Scrum of Scrums的层面:产品所有者们需要进行合作。这种情况下,往往存在一个“产品所有者领袖”的角色,由产品所有者之一担任。此时,他负责管理横跨各个待办事项列表的聚合视图。
  3. 而在Scrum of Scrums of Scrums层面,一般会有一位“首席”或“超级”产品所有者,负责将更高层级的业务路线图和交付承诺,与执行它们的团队联系在一起。他们往往跟踪并维护了解到的承诺与Scrum交付团队的实际速度之间的平衡。

从多个层面建立起Scrum团队和产品所有者之间的关联,将有助于在大型企业中采用敏捷:

这一模式的精髓是组织机构的转型。高效的产品组织机构将自身的构造,与其技术团队现在如何交付产品重新关联。同时,他们将学习如何构成、解构和重构待办事项列表,从而通过其Scrum团队推动工作。

Giuseppe De Simone撰写了一篇关于“Scrum of Scrums”迷思的文章,在其中提到了一个关于扩展敏捷的神话:

当需要把Scrum推广到更多的团队时,你可以使用Scrum of Scrums来处理团队之间的依赖与协调。

对于Scrum团队如何减少团队之间对协调的需求,他列出了一些可以做的事情:

实际上,在Scrum中对依赖的处理,是通过切实消除或至少最小化依赖的方式来实现的。这项任务可以在许多维度来完成,而下面是你不应该错过的五项关键点:

  1. 首先,开发团队必须具备跨功能的特点,这意味着在一个可能发布的产品增量中,对于改造产品待办事项列表中的条目,团队拥有所需的全部能力。可以引入集体代码所有制作为补充:让每个人都能够接触到任何一行代码,以便在Sprint结束时交付产品增量;否则你将会让许多外部依赖束缚住你的团队。
  2. 待办事项列表中的条目应该采用端到端用户故事的形式,从前端到后端将系统切分为各个层面,以生成可能发布的功能片:基于组件的开发产品,而不是糟糕的依赖。
  3. 用户故事应该遵循“INVEST”模式(Independent、Negotiable、Valuable、Estimable、Small、Testable:独立、可协商、有价值、可估算、小尺寸、可测试),其中,I代表着独立,它将有助于简化针对用户故事开展工作。
  4. 在扩展后的Scrum方法中,产品所有者团队开发唯一的产品待办事项列表,为所有开发团队提供输入,并确保各支开发团队尽可能独立,从而能够快速前进并减少相互之间需要协调的部分。
  5. 各支Scrum团队在一起制定计划,从而尽早探明剩余的依赖。

通过让Scrum团队执行上述事项,进行Scrum of Scrums的需求及其目的发生了变化:

这并不是让Scrum Master们汇报某些类型状态的会议,而是为遇到问题的人提供了一个抛出问题、获得来自其他团队的快速帮助的可能。

Scrum of Scrums并不意味着无数次的协调结构,相反它更多的是一种紧急程序——当某支团队已经或将要把某些事情放到其他团队身上的时候启用。

在博客文章Scrum of Scrums——沟通情况的测温表中,Morgan Ahlström分享了使用Scrum of Scrums的经验。他所描述的项目涉及了来自三个国家的七支团队,该项目定期举行Scrum of Scrums:

所有的Scrum Masters和项目经理每周举行三次电话会议,Scrum Master们依次进行状态报告(!)并对自己遇到的麻烦发出抱怨。一些Scrum Master找上了我,咨询是否应该减少会议频率,因为“没有说什么新东西。每次会议上都会抛出相同的问题。”

看起来,这些团队没能够在每次会议间隔的时间段中解决这些问题。Morgan建议Scrum Master们开始记录下问题,并着手研究它们,而不是在Scrum of Scrums上进行抱怨。他还为Scrum Master们安排了当面会晤的机会,以便使大家更好地了解彼此:

我设法筹措足够的资金,使所有Scrum Master汇聚一堂,进行回顾会议及其他研讨会。让大家彼此认识,为我们带来了美好的一天,然而这还不够。在这一天结束的时候,我问房间里的每个人,是否把其他人的联系方式存入了手机通信录中的快速联系人,然而可怕的回答是没有任何人把别人的手机号码存入自己的电话中。解决这个问题很容易,然而问题在于,让大家都使用电话号码。

在这天之后,我开始要求每个Scrum Master都以每天一次的频率,给其他所有人打电话。无论他们是否有问题需要讨论,都应该进行一次至少社交性质的通话,以了解其他人在做什么。这一举措并未立即生效;大部分人都想着他们回去以后不会这么干,然而我在一对一环节继续向他们提出了这一要求。

Morgan注意到,自从Scrum Master们在相互之间建立起关系之后,更多的问题正在得到逐步解决:

(……自此之后)Scrum of Scrums上出现的问题越来越少。相反人们开始进行社交性讨论,并谈论已解决的问题。(……)项目中依旧有大量的问题存在,但是现在他们开始在Scrum of Scrums之外解决这些问题。这些团队(或至少其Scrum Master们)已经对其他人有所关心。甚至有一支团队派遣了团队中的部分开发者,到另一支团队身处的国家中,帮助他们解决问题——甚至后者还没有鼓起勇气寻求外部帮助。

在一个多月的时间里,我们的会议就从不能够帮忙协调或解决任何问题,转变为没有问题需要协调和解决。这让我注意到每日立会和Scrum of Scrums本身或许并不是真正的解决方案,相反它们揭示了我们与其他团队(在会议以外)交流的好坏。

那么各位读者,你是否也采用了Scrum of Scrums?它如何帮助你的团队实现协调与合作?

查看英文原文:Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT