敏捷词汇表 -- 敏捷联盟
# 速率 Velocity
## 定义
在每次迭代结束时，团队将与在该迭代过程中完成的用户案例相关联的工作量估算值相加。该总和称为速度。
知道速度之后，团队可以根据与其余用户故事相关的估算，并假设其余迭代的速度保持大致相同，来计算（或修订）项目将花费多长时间来完成。这通常是一种准确的预测，尽管很少是精确的预测。
## 预期收益
“可行的示例：”敏捷团队已开始进行迭代工作，计划完成故事A和B（估计各为2分）和故事C（估计为3分）。在迭代结束时，故事A和B完成了100％，而故事C仅完成了80％。
敏捷团队通常只承认两个完成级别，即0％完成或100％完成。因此，C不计入速度，该迭代时的速度为4点。
假设剩余的用户故事总共代表40分；然后，团队对项目剩余工作量的预测为10次迭代。
速度还用于限制进一步迭代中的工作量。在我们的示例中，建议团队在下一次迭代中计划仅价值4点的故事。这并不一定意味着它只会完成那么多。实际上，在下一次迭代中完成故事C可能意味着相反，团队的速度会更高。
敏捷团队认为这两种事件都是警告信号：未能“完成”故事或“看到”锯齿的速度。预期的反应是寻求更精细的故事分解。
因此，速度以几种不同的方式用作调节机制。
## 常见陷阱
上面的速度定义还有其他一些后果：
- 速度是事实之后进行的“测量”；尽管它可以帮助您提前进行计划，但它本身并不是预算或预测，而诸如“设定速度”之类的短语则显示出基本的误解
- 速度是根据价值单位（用户故事）而不是工作量单位（任务）定义的
- 仅团队的总速度很重要，而“个人速度”一词则毫无意义；团队是一种旨在产生比其各个部分的总和更多的机制
- 不同团队之间的速度没有有意义的比较，因为这样的团队可能有不同的估算方法
- 为了使速度能够预测项目的结束日期，有必要以一致的方式估算组成项目的所有用户案例；这可以通过以下两种主要方法之一来实现：
- 在项目开始之前或早期（例如在前几次迭代中）估计整个用户故事集；
- 使用相对估计以确保以后进行的估计与项目开始时进行的估计一致
## 起源
“速度”可能是敏捷话语中的概念似乎并不成熟，但需要一段时间才能解决的最好例证。早期的文本（例如“规划极限编程”）通常有利于测量“个体速度”，这种做法在接下来的几年中被声名狼藉。“ 故事点 ”成为最广泛的估算单位，取代了“理想周”。这些更改（通过邮件列表，Usenet和其他论坛散列）有时很难及时确定，只有回顾后才能清楚。
- 2000年：“速度”一词是“ 极限编程 ”的相对较晚的补充，它取代了以前认为过于复杂的“负载因数”概念
- 2002年：Scrum的社会拿起测量“速度”的做法
点击看敏捷名词地铁线路全图