Liga译文 | 管理研发团队后，我发现用「速率」做度量错得离谱……

一旦你开始了解敏捷开发和 Scrum 方法，就一定会碰到「速率 Velocity」。它表示研发团队在一个迭代周期内，能完成的所有故事点数之和；常用作度量基准，辅助长期的工作估算和迭代规划。

几年后，当我在一个优秀的软件工程师团队担任管理者，我才意识到「速率」在实际度量时存在很大的缺陷。也正因如此，我才得以找到真正正确的研发效能度量指标。

01 为什么「速率」不好用？

让我们从速率的计算公式开始：

在管理实践中，大多数团队会选用「实际速率」，所以本文也围绕它展开说明。那么，实际速率在使用中具体存在哪些缺点？

实际速率在数值上无法展示研发团队实际完成工作量的浮动情况。 下面是点数定义相同的两个团队在四个迭代内分别完成的故事点数统计：

从结果上看，两个团队的速率值都是 20，但我们能说「两个团队都能在一个迭代内完成 20 个点的工作」吗？

对第二个团队或许可行，因为它的迭代点数浮动很小（± 2 个点），但第一个团队的变化就大得多（± 18 个点）。如果只看实际速率值，管理者其实无法了解和掌握研发团队的稳定性。

更进一步地，也无法准确地估算待开发的故事和任务的工作量，或者为史诗（Epic）拟定一个预计发布日期。

研发团队和需求经常会发生变化，成员出勤率、人员变动、紧急 Bug 修复、企业培训等等都会影响实际可用资源。

但是，实际速率是基于理想的团队平均运转能力计算的。如果迭代期间有成员休假外出，那团队能否完成所有的故事？这对速率又会产生怎样的影响？团队还能准确地估算开发容量吗？

同样的，如果团队迎来一名新成员，那实际速率会变大吗？还是由于我们需要为新成员提供培训，该迭代的研发速度其实会变慢？需不需要重新评估待办列表？这些我们都毫无头绪。

用速率管理研发效能难有成效的原因还在于，它依赖于故事点数——一个被人为定义的、很难在团队内部达成统一共识的估值。 同时，研发团队也很难保证跨迭代的点数衡量标准一致，这也是当前工作估算的头号难题。

如果不能用相对标准和准确的方式估算研发工作，就很难维持稳定的开发速率。这不止会影响后续迭代的管理，也限制了估算精度的检验和改进。

最后，基于速率值设定团队的迭代目标不可避免地会让成员倍感疲惫。

相信很多团队都出现过追赶截止日期，紧急交付的情况。在临近交期的短时间内，成员们超负荷工作，每天工作 15 个小时再加上周六、周日无休，尽可能完成所有的待办事项，以达成迭代目标。

我们都不希望类似事件发生，但不可否认的是，「极限挑战」状态下的团队速率确实得到了提高。那么，在下一个迭代规划时，研发团队是否可以接受比现在更多的工作量？长此以往，工作量内卷一定会让成员们疲惫不堪。

速率不该被用来设定团队目标，而应该被管理者用来设定绩效先例并预判未来价值。

既然速率不可行，那应该用什么指标代替它度量和管理呢？

使用承诺方差（Commitment Variance，即 CV） ，它有助于增强团队自组织和提升自驱力。其计算公式如下：

使用承诺方差时，研发团队要尽可能准确地估算研发工作量，并使用相同的标准承诺一个完成目标。

而优化承诺方差的目标是尽可能将其绝对值降为 0；团队要努力完成所有任务，并使燃尽图在迭代结束时变为 0。

如果承诺方差的值

大于 0，说明超额完成目标。 团队可以根据承诺值和迭代过程，决定是否提高下一迭代的承诺值；或者结合迭代复盘，分析超额交付的具体原因，例如故事点数被高估、有计划外的人手增加等等。
小于 0，说明承诺预期过高。 基于当前的数值基准，剖析过度承诺的原因，在下一个迭代中重新调整。
等于 0，意味着团队能够准确地估算研发任务并评估交付能力。 保持这个节奏，向前冲吧！

用承诺方差代替速率管理研发交付能力，团队会得到以下收获：

对团队管理者而言，承诺方差也同样意义非凡，主要体现在:

当然，使用承诺方差管理也存在一些潜在风险。

自我施压和内卷/内耗。 一旦成员（们）将交付工作量与绩效评估等联系起来，就可能产生过大的内部/个人压力，过度承诺和过度交付。管理者需要创造一个充满安全感的环境，避免成员们内耗；也要敏锐识别过度承诺，以维护团队长期健康的稳定发展。
故意减少承诺。 有些团队可能会人为地减小承诺值或只完成承诺部分的工作。管理者需要甄别伪模式的存在，避免资源浪费。

一个小建议：可以先使用承诺方差管理工作，在建立相对准确的估算标准后，再尝试用速率设立能力基准，在承诺方差的基础上建立提速缓冲区。