欢迎来到
迭代速率
定义
编辑
-
迭代速率是对开发小组的速度的度量，现在也有公司称为开发小组产能。可以通过计算开发小组在某次迭代中完成的用户故事点总和来得到速率。
-
如果小组在上一次迭代完成了10个故事点，那么在小组的人数、工作时间、工作效率都不变的情况下，下一次迭代也将完成10个故事点。
-
如果把需求池中的所有故事点进行汇总，就可以通过故事点的总和除以速率来预测迭代次数，以此来规划项目时间。
实践出处
编辑
2000年："速率 "一词是相对较晚加入到极限编程中的，它取代了之前被认为过于复杂的 "负载系数 （load factor）"的概念。
2002年：Scrum社区开始采用测量 "速率 "的做法。
为什么
编辑
使用速率有三个重要的目的：
-
首先，将需求池中故事点的总数除以平均团队速率，可以计算出需要多少个冲刺才能完成这些需求，有利于输出项目时间表。
-
其次，团队可以使用速率作为诊断性指标，用来评估和提高交付能力。通过观察速率值的变化，可以评估至少两方面：1）需求是否被高估。2）开发效率是否稳定。
-
再次，可以帮助进行迭代规划，预测本迭代团队能够完成的工作量。
何时使用
编辑
-
迭代前期： 需求规划、项目规划
-
迭代中期： 进度监控
-
迭代后期： 观察数据，调整下次迭代的需求规模和开发资源
如何使用
编辑
计算速率范围
为便于做计划，速率往往是一个范围而非一个固定值。比如，该团队2周一次迭代，速率上下限为25~30个故事点。使用范围可以使我们准确但同时又不至于过分精确。
得到了团队的速率后，我们可以回答如下问题：
-
我们什么时候做完？
-
做几次迭代？
-
我们能完成多少需求？
有了这个范围，便于我们传达出不确定性。
预测速率
如果团队较为稳定，那么可以使用平均速率用来规划项目。如果团队不稳定，或者团队是新建的，那么就需要预测。
第一个迭代可以根据经验进行主观猜测，完成第一个迭代之后，就可以根据第一个迭代的实际速率来计划第二个迭代。
在3-5个迭代之后，团队的速率就会相对稳定。
输出物
编辑
团队迭代速率
参考资料
编辑
-
Cohn M. 敏捷估计与规划[M]. 北京: 清华大学出版社,2007
-
Rubin K. Scrum精髓: 敏捷转型指南[M]. 北京: 清华大学出版社,2014
-
McDaid K, Greer D, Keenan F, et al. Managing uncertainty in agile release planning[C]//SEKE. 2006: 138-143.
-
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.
-
https://www.agilealliance.org/glossary/velocity/
我们非常重视知识产权，我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚，难免会有疏漏。如果您觉得有侵犯您的权益，请联系我们。
导出迭代速率.pdf
导出迭代速率.docx
导出迭代速率.pptx分享
