scrum建议的sprint周期是1-4周，且sprint长度在一个周期内尽量保持不变。
大多数敏捷开发team都把迭代长度设置为2周左右，有些team使用更长的迭代周期。但2~4周是大多数team普遍接受的标准。
那么sprint到底设置多长才是最合适的呢？sprint周期的选择，受到哪些因素的影响？
在选择迭代长度的时候，应该受下列因素的影响：
1. 不确定性的多少
2. 发布日期的长短
3. 客户忍耐度
4. 客户参与度
5. 团队的敏捷经验
6. 团队的技术经验
7. 自动化能力
8. 团队的抗压能力
1. 不确定性的多少
不确定性会以多种形式出现。比如不确定的市场环境、不确定的团队、不确定的技术方案、不确定的需求等，都会存在不确定性。不确定性越多，迭代就应该越短。当有大量的不确定性的时候，短迭代周期就可以让团队更频繁的来检视、调整自己的节奏，获得更好的反馈。
2. 发布日期的长短
迭代的长度决定了能够多频繁地向客户展示潜在可交付成果、度量开发进度以及PO和团队修正自己的路线。
比如团队要在3个月后发布产品，如果采用1个月的迭代长度，那么团队用来收集迭代结束后的反馈、度量及调整开发路线的机会就只有2次。但这个次大多数情况下是不够的。可能需要5-6次的反馈，才能更好的满足客户的需求。如果产品的发布时间是5-6个月或以上，可能可以考虑4周为一个迭代周期。发布周期越短，迭代周期就应该越短。
3. 客户忍耐度
如果你的客户对项目的容忍度很低，而且是那种“暴脾气”，恨不得立刻马上就能看到交付成果的，这种情况往往要采用较短的迭代周期。这样可以更好的将成果提交给客户，并获得反馈。忍耐度越低，迭代周期就应该越短。
4. 客户参与度
如果客户在迭代周期内，能够有充足的时间提供及时的反馈，建议采用更短的迭代周期。
5. 团队的敏捷经验
如果团队拥有非常多项目的敏捷开发经验，建议采用短迭代周期
6. 团队的技术经验
如果团队技术技能十分优秀，比如擅长使用某种技术方法、编程语言，或者具备优秀的用户故事分解能力、任务的拆分与估算能力，建议采用短迭代周期。
相反，如果技能一般或很差，则需要尽量采用长的迭代周期，这样不会给团队带来巨大的交付压力，并且可以给团队提供适时的培训，提升技能。
7. 自动化能力
每次迭代都有成本。例如，对每次迭代都必须进行完整的回归测试。如果它的成本很高，团队可能会倾向于长一些的迭代周期。要想进一步提升迭代的交付效率，就需要尽量减少这种系统开销。对于那些没有使用任何自动化工具的团队，比如CI/CD、DevOps等，很多时候会出现在短迭代周期后（比如1-2周），无法交付可用的产品。
8. 团队的抗压能力
如帕金森定律，只要项目的结束日期还在遥远的将来，团队基本上就不会感到任何压力。临近结束时，压力才体现出来，才会更努力的工作。在使用4周的迭代长度中，很多team可以明显地感觉到在第一周的压力没有在第四周的压力大。
要解决这个问题，当然就是选择一个合适的迭代长度，把他们正常感受到的压力更为均匀地分布到一个适当长度的迭代中。
以上文章由@丁仿 圣略咨询敏捷教练、管理圈APP创始人
原创发布于管理圈，未经许可禁止转载。
粤公网安备 44010602010970