团队速率(Velocity)

团队速率(Velocity,又称迭代速率)是敏捷开发中的一项经验度量,指一个团队在单个迭代(冲刺)中实际完成并满足完成标准的工作量总和,通常以故事点为单位,也可用完成的故事数量计。它回答的核心问题是:按团队当前的真实节奏,一个迭代大约能交付多少。

概述

速率的概念随极限编程与 Scrum 的普及而流行,是从做计划的愿望转向看历史的事实的关键工具。做法很简单:迭代结束时,把所有满足完成的定义的故事的点数相加,即为本迭代速率;取最近若干个迭代的平均值或区间,作为下个迭代规划会议上承接工作量的参考,也可据此推算某个版本范围大约还需几个迭代。因为故事点是各团队自己校准的相对单位,速率天然只在同一团队内有意义。

核心特点

• 经验导向:用实际完成的历史数据预测未来,而不是用理想人天做计划,天然吸收了会议、返工、支援等隐性开销。
• 只算完成的:未满足完成标准的故事不计入速率,哪怕只差一点,这保证了速率反映的是可交付价值。
• 区间思维:速率天然波动,成熟团队用最近几个迭代的波动区间(如 28 到 36 点)而非单一数字做承诺。
• 趋稳而非求高:速率的价值在于稳定可预测,持续稳定的团队才能做出可信的版本承诺。

应用场景

速率主要用于迭代规划(决定拉多少故事进冲刺)、版本预测(剩余总点数除以平均速率估算迭代数)和风险预警(速率骤降往往意味着技术债务、人员变动或需求质量问题)。它常与燃尽图、累积流图配合使用。

常见问题

问:能用速率考核团队或比较两个团队吗？答:不能。故事点尺度因团队而异,把速率当指标考核会立刻诱发点数通胀——团队把估算越报越大,度量随即失效,这是古德哈特定律的典型案例。

问:速率不稳定怎么办？答:先找原因而非强行拉平:常见原因包括故事拆分过大、需求频繁变更、隐藏的线上支援工作未计入。改善拆分粒度、预留支援缓冲后,速率通常会自然收敛。