迭代速率

2000年："速率 "一词是相对较晚加入到极限编程中的，它取代了之前被认为过于复杂的 "负载系数 （load factor）"的概念。

2002年：Scrum社区开始采用测量 "速率 "的做法。

使用速率有两个重要的目的：
* 首先，将需求池中故事点的总数除以平均团队速率，可以计算出需要多少个冲刺才能完成这些需求，有利于输出项目时间表。
* 其次，团队可以使用速率作为诊断性指标，用来评估和提高交付能力。通过观察速率值的变化，可以评估至少两方面：1）需求是否被高估。2）开发效率是否稳定。
* 再次，可以帮助进行迭代规划，预测本迭代团队能够完成的工作量。

| 阶段 | 使用 |
| --- | --- |
| 前期 | 需求规划，项目规划 |
| 中期 | 进度监控 |
| 后期 | 观察数据，调整下次冲刺的需求规模和开发资源 |

#### 计算速率范围
为便于做计划，速率往往是一个范围而非一个固定值。比如，该团队2周一次迭代，速率上下限为25~30个故事点。使用范围可以使我们准确但同时又不至于过分精确。
得到了团队的速率后，我们可以回答如下问题：
1. 我们什么时候做完？
2. 做几次迭代？
3. 我们能完成多少需求？
有了这个范围，便于我们传达出不确定性。

#### 预测速率
如果团队较为稳定，那么可以使用平均速率用来规划项目。如果团队不稳定，或者团队是新建的，那么就需要预测。

第一个迭代可以根据经验进行主观猜测，完成第一个迭代之后，就可以根据第一个迭代的实际速率来计划第二个迭代。

在3-5个迭代之后，团队的速率就会相对稳定

1. Cohn M. 敏捷估计与规划[M]. 北京: 清华大学出版社,2007
2. Rubin K. Scrum精髓: 敏捷转型指南[M]. 北京: 清华大学出版社,2014
3. McDaid K, Greer D, Keenan F, et al. Managing uncertainty in agile release planning[C]//SEKE. 2006: 138-143.
4. Saleh S M, Huq S M, Rahman M A. Comparative study within Scrum, Kanban, XP focused on their practices[C]//2019 International Conference on Electrical, Computer and Communication Engineering (ECCE). IEEE, 2019: 1-6.
5. https://www.agilealliance.org/glossary/velocity/