速率驱动 Sprint 计划 vs. 承诺驱动 Sprint 计划

对于主持 Sprint 计划会议，有着各种不同的意见。长期以来，就速率驱动 Sprint 计划还是承诺驱动 Sprint 计划一直存有争议。 Mountain Goat 软件的创始人 Mike Cohn，最近在他的一篇名为 为什么我喜欢承诺驱动Sprint 计划的博客上分享了他的想法。

Mike 在他的博客上描述了两种方法，速率驱动 Sprint 计划是基于一种前提，即当前迭代团队的工作量与前几个迭代团队平均的工作量大致相当。

速率驱动 Sprint 计划的步骤如下：

• 确定团队历史平均速率。
• 选择产品待办目录的一些条目，使得工作量与平均速率相当。

在承诺驱动 Sprint 计划中，团队通过粗略的识别和估算需要做的任务，团队依次承诺产品待办列表的条目，每次承诺一条，直到他们感觉这个迭代满负荷为止，就像 Mike 所说：

因为“承诺”经常被误解成 “保证”，因此这种方法越来越普遍地被称为基于能力的 Sprint 计划方法。

Mike 说，在计划的时候，对一个用户故事不需要深入探讨有关它的所有任务。

不要求或期待团队在迭代中考虑所有要做的每一个任务。不止是因为这不可能做到，而且没必要这么做。

团队应该考虑足够的任务，他们觉得这些任务是认真考虑过的。但重要的是要意识到这个会议的真正目的是认真的思考。而确定任务和小时数其实是相对次要的。

Mike 说他喜欢承诺驱动 Sprint 计划是因为以下原因：

• 速率是变化的，所以对于长远的计划是好的。
• 估计的锚定效应，容易被早期信息过度影响。

如果你已经做了速率驱动 Sprint 计划，并且对你有效，那就不要再换了。然而，如果你的团队刚刚接触 Scrum 或者你的团队正在面临一些问题，那么我推荐使用承诺驱动 Sprint 计划。

对于以前连一个迭代都没有一起做过的新团队来说，能力驱动计划会产生更好的结果。因为实验性证据估算会更强，并且经常基于团队的某个人已经做完的事情进行估算。

Thomas Henson 在 Diqus 上分享了他的观点：

我认同你的评价，关键是团队保持每一个迭代相同用户故事点数的趋势。承诺驱动可以让团队进行自我挑战。第二点是，承诺驱动可以让团队自己管理自己的工作，并且 Scrum 的关键就是让团队变成自组织的。

查看英文原文： Velocity-Driven Versus Commitment-Driven Sprint Planning

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。