多个 sprint,交错进行,还是同步前进?

  • Vikas Hazrati
  • 郑柯

2009 年 12 月 30 日

话题:敏捷最佳实践文化 & 方法

随着项目的规模变大,Scrum 团队也会不断增加。将团队划分为多个团队,保证人员数目符合敏捷推荐的团队大小,这是管理不断增长的团队的推荐方式。然而,当团队们各自开始自己的 sprint 的时候,可能会出现沟通和协调方面的问题。

Mike Cohn提出:解决这方面问题,最好的方式就是同步多个 sprint。在一个类似的项目中,刚开始时,他采取了交错安排 sprint 的方式,不久后就发现这样做效果不佳。交错的 sprint 最大的问题在于:总是会有不止一个团队的工作不能完全做完、做到位,因此整个系统无法交付给客户进行部署、得到反馈。

同步不是说所有的 sprint 都要在同一天完成。他建议:同步的多个 sprint 的结束日期应该差个一、两天。

允许多个 sprint 在两到三天内结束,这让某些身处多个团队的人可以参加所有必要的评审和规划会议。而且,很多时候,这还能有机会让远程的团队成员通过旅行,进城参加这些会议。

Mike 接下来说道:同步多个 sprint 不是说不同的团队不能有长度不同的 sprint。有些团队可以采取嵌套式的 sprint。

嵌套式的 sprint 最常用的情况是:项目的不同团队无法就同一个 sprint 长度达成一致,可能有些需要两周的 sprint,有些需要四周的 sprint。

Angry Poodle 响应了 Mike 的观点,他补充道:考虑到产品的复杂度,他们必须使用同步的 sprint

在我们的公司里,我们构建的系统不但大,而且复杂,同步很困难。可另一方面,系统的规模让我们不得不采取大规模发布的方式,每年 3 次(考虑到支持的 3 个不同版本,一年要 9 次)。围绕着发布 sprint 的内部混乱状况太过难于管理,这也促使我们必须要保证多个 sprint 同步。

Jeff Sutherland却建议:在很多情况下,交错的 sprint 可能更符合现实状况

他认为:可能同时有多个交错的 sprint 在一组开发团队间运作,并建议使用元 Scrum(MetaScrum)来管理多个 sprint。他提到:

在 PatientKeeper 公司,为了管理每周或每月同时发生的 sprint,还要在每个季度发布新版本,由产品负责人牵头组织了一个 MetaScrum。MetaScrum 会议产生的工作纲要会驱动整个公司,大大减少了公司的沟通问题,降低了客户的焦虑情绪,同时让常见的混乱和迷惑状况也得以缓解。正像 Scrum 会议可以协调、巩固为 sprint 做出的所有决策一样,MetaScrum 会议可以协调、巩固为多个 sprint 做出的所有决策。

与这些观点类似,John Clifford回复一个问题的同时,建议组成“产品负责人委员会”。

我发现多个团队的项目使用“产品负责人委员会”能产生很好的效果。该委员会由“首席产品负责人”和不同团队的产品负责人构成。首席产品负责人对项目和发布负责,而各个团队的产品负责人帮助管理各个团队的 backlog 等事宜。各个团队之间的协调通过管理 backlog 完成。举个例子:如果团队 B 需要团队 A 先完成一个用户故事,产品负责人委员会就会确保:在依赖这个用户故事的工作条目进入到团队 B 的 sprint backlog 之前,该用户故事得以完成。

因此,有些情况下,同步是无法做到的。在这样的情形下,选取 MetaScrum 或产品负责人委员会应该是个不错的选择。然而,Mike 指出:多个 sprint 应该尽可能同步。他使用下面的类比来支持自己的观点:

对我来说,这样做的好处类似于随处可见的场景:父母会跟孩子说:“你们可以自己想干啥就干啥,但是每个人都要在下午 6 点前到家吃晚饭。”我们白天都会出去(从事工作、实习、见朋友等等活动),但是每天都还是要聚在一起(类似于 sprint)。

查看英文原文:Overlapped or Synchronized Sprints?

敏捷最佳实践文化 & 方法