在敏捷开发的世界中，很少有指标会像速度一样引发如此多的争议。一方面，它承诺清晰：可预测的交付速率。另一方面，它却威胁到团队的福祉：成为微观管理的工具。当实施不当，速度追踪会从一个有帮助的指南转变为压力的来源。🛑
Scrum团队常常陷入对可预测性的需求与追求可持续节奏之间的两难境地。本指南探讨如何在不牺牲团队健康的前提下准确追踪速度。我们将分析速度的机制、测量带来的心理影响，以及如何利用数据赋能而非控制团队。
🧠 Scrum速度到底是什么？
速度是衡量Scrum团队在一个Sprint期间能够处理的工作量的指标。它通过汇总一个Sprint中所有已完成的用户故事的故事点数来计算。然而，理解定义只是问题的一半，理解其初衷才是关键。
速度并非衡量个人绩效的指标，也不是用来比较不同团队的基准。它是一种规划工具，旨在帮助开发团队预测未来Sprint中能够承诺完成的工作量。📊
当团队将速度视为关键绩效指标（KPI）时，关注点就会从价值交付转向达成某个数字。这种转变正是倦怠的开端。为了避免这种情况，团队必须重新夺回速度作为专属的私有指标，仅由开发团队拥有。
⚖️ 倦怠的关联：为什么速度会伤害团队
许多组织滥用速度数据。管理层可能会查看团队的速度并问道：“为什么上个月我们只完成了30个点？这个月需要完成40个。”这种外部压力会营造出有毒的环境。
当速度被用来评判生产力时，会引发多种负面行为：
- 过度承诺：团队承诺的工作量超过其实际承受能力，以取悦利益相关者。
- 虚报估算：开发人员夸大故事点数以制造安全缓冲，从而降低该指标的准确性。
- 忽视复杂性：为了提高数字，团队会优先选择简单任务，而忽视复杂但有价值的工作。
- 忽视质量：技术债务被忽视，因为它不会立即增加速度的数值。
这种环境会导致疲劳。开发人员不再关心代码质量，只专注于关闭任务。这就是倦怠的定义。为防止这种情况，速度必须与绩效评估脱钩。
📉 如何正确计算速度
准确计算需要纪律。仅仅简单相加点数是不够的。该过程必须保持一致且透明。以下是计算速度的标准方法，以避免引入偏差。
1. 明确“完成”的定义
只有满足“完成定义”（DoD）的故事才能计入速度。如果一个故事完成了90%，它仍然计为零。这可以防止团队基于部分工作虚报数据。DoD应包括代码审查、测试和文档。
2. 排除上一个Sprint中已完成的工作
从上一个Sprint延续下来的工作不计入当前Sprint的速度。只有在当前时间盒内完成的工作才计入得分。这确保了指标真实反映当前的承载能力。
3. 处理被打断的Sprint
如果Sprint被打断怎么办？如果由于不可预见的情况导致Sprint被提前终止，那么该期间的速度无效。不要将其平均计入。相反，应记录中断情况，并使用下一个完整的Sprint进行计算。
4. 故事点的一致性
团队必须就“点”代表什么达成一致。它应该是相对的，而不是绝对的时间。如果团队决定一个点等于某种复杂度，这一标准必须在时间上保持一致。在项目中途更改量表会使得历史速度数据失效。
📈 利用速度进行预测，而非施加压力
速度的主要用途是预测。它帮助团队回答：“完成这个待办事项列表需要多少个冲刺？”但它并不能回答：“你们是否足够努力工作？”
预测依赖于平均值的概念。单个冲刺的速度是波动的，会因假期、病假或技术挑战而变化。为了获得可靠的预测，应使用最近3到5个冲刺的平均速度。
这种平滑效应减少了异常情况的影响。它提供了对团队能力的现实看法。当利益相关者询问交付日期时，团队可以说：“根据我们平均每冲刺35个点，以及剩余待办事项140个点，我们预计需要4个冲刺。”
这种方法以数据为驱动，但并非惩罚性的。它依赖于团队自身的历史数据，而非外部期望。
🔄 替代与补充指标
速度并非唯一重要的指标。事实上，仅依赖速度可能会掩盖重要问题。高速度并不能保证团队健康或产品稳定。建议使用指标仪表板，以获得全面的视角。
| 指标 | 衡量什么 | 为什么重要 |
|---|---|---|
| 速度 | 每个冲刺的产出 | 预测未来的产能 |
| 周期时间 | 从开始到完成的时间 | 识别流程中的瓶颈 |
| 前置时间 | 从请求到交付的时间 | 客户响应速度 |
| 逃逸缺陷 | 生产环境中发现的缺陷 | 质量和稳定性 |
| 冲刺目标达成率 | 目标的实现程度 | 专注与价值交付 |
周期时间特别有助于防止过度劳累。如果周期时间增加，说明团队陷入了停滞。这表明在向队列中添加更多工作之前，他们需要帮助解决障碍。即使周期时间飙升，速度仍可能保持高位，从而造成一种虚假的健康假象。
🧘 心理安全与团队健康
可持续速度最重要的因素是心理安全。团队成员必须感到安全，可以在遇到困难时坦白，而无需担心受到惩罚。如果开发人员为了保护速度数值而隐瞒问题，这个指标就失去了意义。
领导者和Scrum主管在此扮演着关键角色。他们必须强调，速度是团队的工具，而不是管理层的工具。在回顾会议中，应公开讨论速度趋势。可以提出如下问题：
- 我们的估算准确吗？
- 我们是否遇到了意外的技术债务？
- 完成的定义是否拖慢了我们的进度？
- 我们是否感到必须提前完成的压力？
如果上一个问题的答案是肯定的，那么重点必须转向容量管理。与其匆忙行事导致问题，不如少完成一些高质量的故事。
🚫 需要避免的常见陷阱
团队在追踪速度时常常陷入一些特定的陷阱。及早识别这些陷阱，可以避免项目失败。
1. 比较团队
将团队A的速度与团队B进行比较是一个根本性错误。每个团队的技能水平、上下文环境和故事点的定义都不同。团队A可能速度很高，因为他们的点数较小；团队B可能速度较低，因为他们处理的是更难的问题。比较会引发怨恨情绪，并促使团队试图操纵系统。
2. 追求数字
当团队感觉必须达到某个具体数字时，他们就会停止关注价值。他们可能会把大故事拆分成小故事来增加数量。这会增加开销和碎片化。应关注交付的价值，而不是累积的点数。
3. 忽视容量
速度假设100%的可用性。它不考虑年假、会议或支持工作。一个5人的团队理论上可能有50个点的容量。如果两人休假，实际容量就会下降。在冲刺规划期间，必须始终根据容量进行调整。
4. 将速度用于个人评估
将速度与个人奖金或绩效评估挂钩，是导致 burnout 的直接途径。这会鼓励团队成员隐藏信息、拒绝帮助他人。工作应基于团队的整体产出进行评估，而不是个人贡献。
🛠️ 实施健康的流程
转向健康的速率追踪系统需要时间，需要思维模式的转变。以下是一种负责任地实施此流程的分步方法。
步骤1：教育利益相关方
在开始追踪之前，向利益相关方解释速度是什么，以及它不是什么。他们需要明白，速度是一种预测，而不是承诺。它是团队指标，而不是管理工具。这能尽早设定预期。
步骤2：建立基准
不要期望第一个冲刺就准确。前几个冲刺是用来校准的。利用数据找出团队的自然节奏。不要仅根据第一个冲刺的数据就做出调整。
步骤3：在回顾会议中审查
让速度成为回顾会议中的常规议题。讨论计划与实际之间的差异。如果团队计划完成40个点，但只完成了30个，就要分析原因。是估算不准吗？是否有干扰？这能形成持续改进的反馈循环。
步骤4：调整规划
使用平均速度来规划未来的冲刺。如果平均值是30，就不要计划40。计划30。如果团队持续完成更多，他们将在未来的规划会议中自然提升容量。应让团队自己推动增长，而不是由管理层推动。
步骤5：监控团队福祉
关注团队的情绪状态。如果速度很高但士气很低，说明有问题。高速度可能是过度工作的表现。应优先考虑福祉而非速度。一个休息充分的团队从长远来看能更快地交付更高质量的代码。
📉 处理速度的波动
速度会波动，这是正常的。一个团队可能在某个冲刺中表现很高，随后又出现低速。这并非失败，而是现实。影响波动的因素包括：
- 团队构成： 新成员入职会暂时降低速度。
- 技术债务： 偿还债务通常会减缓新功能的开发速度。
- 外部依赖： 等待第三方会阻碍进展。
- 冲刺周期： 改变冲刺周期会影响可用的总点数。
当出现波动时，不要惊慌。观察一段时间内的趋势。单个数据点是噪音；趋势才是信号。如果连续三个冲刺的趋势呈下降，就需要调查根本原因。工作是否变得更难了？团队是否不堪重负？
💡 Scrum主管的角色
Scrum主管是流程的守护者。他们必须保护团队免受外部压力的影响，避免人为操纵速度。如果产品负责人要求下个冲刺增加更多点数，Scrum主管应引导其关注平均速度和团队容量。
Scrum主管还确保团队不会操纵指标。他们促进诚实的估算会议。在冲刺规划中，如果工作量过高，他们鼓励团队说“不”。这种保护对长期可持续性至关重要。
🌱 建立可持续的工作节奏
敏捷关注的是可持续性。《Scrum指南》强调要保持可持续的工作节奏。这意味着团队可以无限期地维持其速度而不会精疲力尽。如果团队为了达成目标而耗尽精力，那么这个目标就是错误的。
可持续的工作节奏允许持续改进，允许学习，也允许工作之外的生活。当速度跟踪支持这一点时，它就成为一种强大的工具；当它破坏这一点时，它就变成一种负担。
关注工作的质量。关注团队的幸福感。关注为客户交付的价值。如果这三大支柱稳固，速度自然会随之提升。
🔍 关于度量的最后思考
跟踪Scrum速度是敏捷规划的必要部分，但需要谨慎对待。它衡量的是能力，而不是价值。通过将其视为开发团队的私有工具，组织可以避免微观管理的陷阱。
记住，数据只有在能带来更好决策时才有用。如果速度数据导致压力，那就是使用不当。应重新聚焦于可预测性和流程顺畅性。使用周期时间等补充指标，以获得更全面的健康状况图景。
最终，目标不是最大化某个数字。目标是持续且可持续地交付价值。当团队感到安全和支持时，速度自然会成为其能力的真实反映，而不是需要追逐的目标。🎯
采用这些实践，打造一个不仅高效而且具有韧性的团队。一个有韧性的团队是组织所能拥有的最佳资产。
