多个 sprint，交错进行，还是同步前进？

随着项目的规模变大，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?