敏捷开发Sprint长度选择

大家对一个迭代周期的长度有不同的见解，有人认为4周比较好，有人喜欢3周，还有2周。我们团队之前尝试过3周，目前在使用2周一个迭代。

我们刚开始选择3周一个迭代的主要原因是觉得一个迭代周期里要开计划会、回顾会，甚至评审会，如果2周一个迭代的话，感觉剩下的开发时间就没有了多少了。而且3周可以安排更多的任务，大家进度压力小一些。

但是试了几个迭代后，发现一个严重的问题就是大家在迭代的第一周比较放松，毫无压力，然后从第二周开始进入干活状态，从第三周开始进入加班状态，因为发现迭代要结束还有很多任务没有完成。同时因为进度不合理，迭代初期测试人员没有事情可干，迭代后期测试压力很大，活都压在最后了。

为了改变现状，我们开始尝试2周一个迭代，这样每个迭代完成的任务相对少一些，任务比较清晰，同时因为下个周就要交付，所以从一开始就进入了干活状态，明显比之前专注多了。

所以短迭代相对于长迭代的一个主要优势就是整个团队可以一直保持专注，同时因为每个短迭代就是一个小的里程碑，可以持续的为开发人员增加成就感，提升团队士气。但是短迭代对团队要求相对较高，任务划分、优先级安排要非常合理，团队之间配合要比较默契，否则很容易造成一个迭代无法完成任务，造成团队混乱。