共计 2786 个字符，预计需要花费 7 分钟才能阅读完成。
一旦你开始理解麻利开发和 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 助力开发者扬帆远航，期待与你一路同行！