一旦你开始了解敏捷开发和 Scrum 方法，就一定会碰到「速率 Velocity」。它表示研发团队在一个迭代周期内，能完成的所有故事点数之和；常用作度量基准，辅助长期的工作估算和迭代规划。
几年后，当我在一个优秀的软件工程师团队担任管理者，我才意识到「速率」在实际度量时存在很大的缺陷。也正因如此，我才得以找到真正正确的研发效能度量指标。
01 为什么「速率」不好用？
让我们从速率的计算公式开始：
- 实际速率 = 完成的总点数 / 迭代次数
- 预期速率 = 估算产生的总点数 / 迭代次数（估算故事点数即被添加到迭代中的故事点数）
在管理实践中，大多数团队会选用「实际速率」，所以本文也围绕它展开说明。那么，实际速率在使用中具体存在哪些缺点？
1. 无法展示浮动空间
实际速率在数值上无法展示研发团队实际完成工作量的浮动情况。 下面是点数定义相同的两个团队在四个迭代内分别完成的故事点数统计：
从结果上看，两个团队的速率值都是 20， 但我们能说「两个团队都能在一个迭代内完成 20 个点的工作」吗？
对第二个团队或许可行，因为它的迭代点数浮动很小（± 2 个点），但第一个团队的变化就大得多（± 18 个点）。如果只看实际速率值，管理者其实无法了解和掌握研发团队的稳定性。
更进一步地，也无法准确地估算待开发的故事和任务的工作量，或者为史诗（Epic）拟定一个预计发布日期。
2. 不能灵活适应变化
研发团队和需求经常会发生变化，成员出勤率、人员变动、紧急 Bug 修复、企业培训等等都会影响实际可用资源。
但是，实际速率是基于理想的团队平均运转能力计算的。如果迭代期间有成员休假外出，那团队能否完成所有的故事？这对速率又会产生怎样的影响？团队还能准确地估算开发容量吗？
同样的，如果团队迎来一名新成员，那实际速率会变大吗？还是由于我们需要为新成员提供培训，该迭代的研发速度其实会变慢？需不需要重新评估待办列表？这些我们都毫无头绪。
3. 估算本身不准确
用速率管理研发效能难有成效的原因还在于，它依赖于故事点数——一个被人为定义的、很难在团队内部达成统一共识的估值。 同时，研发团队也很难保证跨迭代的点数衡量标准一致，这也是当前工作估算的头号难题。
如果不能用相对标准和准确的方式估算研发工作，就很难维持稳定的开发速率。这不止会影响后续迭代的管理，也限制了估算精度的检验和改进。
4. 成员会精疲力竭
最后，基于速率值设定团队的迭代目标不可避免地会让成员倍感疲惫。
相信很多团队都出现过追赶截止日期，紧急交付的情况。在临近交期的短时间内，成员们超负荷工作，每天工作 15 个小时再加上周六、周日无休，尽可能完成所有的待办事项，以达成迭代目标。
我们都不希望类似事件发生，但不可否认的是，「极限挑战」状态下的团队速率确实得到了提高。那么，在下一个迭代规划时，研发团队是否可以接受比现在更多的工作量？长此以往，工作量内卷一定会让成员们疲惫不堪。
速率不该被用来设定团队目标，而应该被管理者用来设定绩效先例并预判未来价值。
既然速率不可行，那应该用什么指标代替它度量和管理呢？
02 正确的管理指标：承诺方差
使用承诺方差（Commitment Variance，即 CV） ，它有助于增强团队自组织和提升自驱力。其计算公式如下：
- PointsCompleted-完成总点数：上一个迭代中，研发团队成功交付的故事点数。
- PointsCommitted-承诺总点数：团队在迭代计划中承诺能完成的故事点数，可用被添加到迭代待办列表中的点数之和表示。
1. 指标管理目标
使用承诺方差时，研发团队要尽可能准确地估算研发工作量，并使用相同的标准承诺一个完成目标。
而优化承诺方差的目标是尽可能将其绝对值降为 0；团队要努力完成所有任务，并使燃尽图在迭代结束时变为 0。
2. 结果解读
如果承诺方差的值
- 大于 0，说明超额完成目标。 团队可以根据承诺值和迭代过程，决定是否提高下一迭代的承诺值；或者结合迭代复盘，分析超额交付的具体原因，例如故事点数被高估、有计划外的人手增加等等。
- 小于 0，说明承诺预期过高。 基于当前的数值基准，剖析过度承诺的原因，在下一个迭代中重新调整。
- 等于 0，意味着团队能够准确地估算研发任务并评估交付能力。 保持这个节奏，向前冲吧！
3. 优势分析
用承诺方差代替速率管理研发交付能力，团队会得到以下收获：
- 结合每个迭代的实际情况，灵活地制定迭代承诺和目标。
- 正确定义故事点数，专注准确的工作估算。
- 正确地评估团队交付力，有的放矢地设立承诺和目标。
- 围绕自设定的承诺，调整工作状态，减少迭代冲刺中疲劳的风险。
对团队管理者而言，承诺方差也同样意义非凡，主要体现在:
- 有机会与团队合作，共同完成新功能和/或产品复杂性的估算，获得安全感和信心。
- 向利益相关者提供更准确的预计交付期限。
- 放心授权成员自组织，激励团队自驱成长。
4. 潜在风险
当然，使用承诺方差管理也存在一些潜在风险。
- 自我施压和内卷/内耗。 一旦成员（们）将交付工作量与绩效评估等联系起来，就可能产生过大的内部/个人压力，过度承诺和过度交付。管理者需要创造一个充满安全感的环境，避免成员们内耗；也要敏锐识别过度承诺，以维护团队长期健康的稳定发展。
- 故意减少承诺。 有些团队可能会人为地减小承诺值或只完成承诺部分的工作。管理者需要甄别伪模式的存在，避免资源浪费。
一个小建议：可以先使用承诺方差管理工作，在建立相对准确的估算标准后，再尝试用速率设立能力基准，在承诺方差的基础上建立提速缓冲区。
03 案例分析
下面我们通过示例，进一步讲解承诺方差的实际应用。还是开头提到的两个团队，假设他们现在使用承诺方差来完成任务估算和能力评估。
上表中，团队「迭代实际完成的平均工作量」就是实际速率。两个团队「平均承诺的故事点数」都非常接近 22（± 0.25）个点，但实际完成量却非常不同。
第一个团队在使用承诺方差后发现，当前定义的「点数」无法支持正确的工作量估算和能力评估。
于是在第四个迭代中，他们调整了「一点数工作」的定义并在内部达成共识。由于度量颗粒度变细，他们给出 28 个点的承诺值（尽管数据显示，他们在上个迭代中只完成了 12 个点）。
通过绘制两个团队的承诺方差趋势图，可以看到，优化故事点数也是一个持续改进的过程。
04 LigaAI 总结
基于相同的点数标准，承诺方差将工作量估算与能力评估有机结合，解决了速率管理中存在的灵活性和准确性不足的问题。
承诺方差的管理目标是使其绝对值尽可能降为 0。既不过度承诺，让团队耗费心力，也要避免承诺低估，造成浪费资源。
（原文作者：Michel C；文章出处：Medium）
击碎增长瓶颈，LigaAI 将持续分享研发效能度量体系的搭建经验，以及科学的度量指标管理方法。了解更多效能优化与增长干货，欢迎关注 LigaAI@SegmentFault ，我们一起做大做强！
也期待您点击 LigaAI-新一代智能研发协作平台，与我们交流 🙂
LigaAI 助力开发者扬帆远航，期待与你一路同行！
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
