通常迭代长度会在2-4周，但是如何确定具体的迭代长度取决于如下内容
1.项目发布的总时间长度，这个长度决定了软件以什么频度向用户展示，开发进度以什么频度来度量，交付路径以什么频度来进行修正，作者建议至少一个项目至少需要4-5次来收集迭代结束时的反馈、度量进度和调整开发路径，那么迭代的长度就是发布周期除以4或者5.
2.不确定性的多少，一般来说，不确定越多，迭代的周期就应该越短，短的迭代周期可以给团队更多的机会来度量自己的进度和客户的反馈，以尽可能的减少不确定性。
3.获得反馈的难易程度，选择迭代长度时，应尽可能让团队获得反馈的数量、频度和及时性都最大化。根据利益相关者或客户反馈的容易程度，来选择合适的迭代长度。
4.优先级可以保持多久不变，PO迭代期间不仅不改变优先级，还要帮助团队免受其他试图改变优先级的人的影响，因此优先级保持不变的时间是选择迭代长度需要考虑的因素。
5.没有外部反馈之下进行工作的意愿，如果团队接受外部反馈的频度越低，就可能误入歧途，造成的损失也就会越大。
6.迭代的系统开销，如，每次迭代都需要进行完整的回归测试，这些都是迭代的成本。因此尽可能消除与每次迭代联系在一起的系统开销。
7.紧迫感的维持，团队会觉得结束日期在将来，因此要解决紧迫感的问题，就需要将压力平均，选择一个适当的迭代长度。
那么最后怎么确定迭代长度呢？目标之一是鼓励每个人在迭代中按照稳定的步幅进行工作。建议两周，一周太短，没有补救的时间，四周则太长，会有开始、中间和结尾的感觉。因此，作者建议2周是最理想的迭代长度。
网友评论