敏捷迭代周期的探讨
您目前处于:敏捷  2015年06月20日

我们的迭代计划安排是这样的,迭代周期是10个工作日(去除周末和假日),计划会议和 Review、Retro 不计算在迭代周内,每个迭代结束后的第二天召开Review和Retro,再下一天召开 Planning Meeting。

但是发现,团队的故事有时在迭代结束后仍没有完成,导致 Review、Retro 和 Planning Meeting 延后。或由于其他原因(如没有预定到会议室)没有即时召开会议,这样导致迭代之间团队变得非常混乱和散漫。

调整一

为了解决会议不能即时召开的问题,我们调整了迭代计划,变成了固定2周迭代,第一周的周一召开迭代计划,第二周的周五召开Review和Review。一个迭代结束之后马上开始第二个迭代。

这样的调整解决了会议的问题,我们如此实践了3个迭代(1个半月)!

但是发现,我们又遇到了新的问题,虽然会议时间固定了,但是迭代时间变短了,不仅时间固定了2周(可能不足10个工作日),还包含进了 Planning Meeting 和 Review、Retro!

这样的结果就是团队不得不将任务拆分的足够小,很难安排大的任务!要知道敏捷交付的有价值的故事,可又很尴尬的是小故事有时很难承载足够大的价值。

由于发现固定2周的迭代造成团队不能交付足够大的故事,所以把迭代之间由固定2周调成了固定3周,这样就解决了团队可以有足够的迭代完成大的故事。

调整二

但是发现,我们又遇到了新的问题(哈哈,上面重复用过了),迭代时间真的变长了,虽然只是多了一周(可能不足15个工作日),但是3周的迭代产生2个严重的问题,一是 Planning Meeting 评估的故事出现很大的偏差,造成这样的原因一是由于团队已经习惯2周的评估,二是时间长了就会造成评估失准。

第二个问题是3周的迭代里,团队会把故事拖到第二周和第三周里完成,这种变化来源于之前是2周里,第一周设计开发、第二周测试交付,而变成3周之后,就是第一周结束还有第二周和第三周。

还有一点,迭代之间的缓冲也没有了,这感觉就是团队拼命的冲刺!不管是之前的2周还是现在的3周,这导致的影响就是团队冲刺不起来了!

因为一个迭代马上开始下一个迭代,团队就没有在冲刺喘息的时间!

调整三

从第一次调整到第二次调整,过去了大约3个月,我们最后又调整回了最开始的迭代计划!发现还是最开始的还是最适合团队的。

你可能会问,团队需要缓冲么?  回到之前,不会出现之前的问题么?现在认为这其实是一条不断试错的过程,找到一个最合适的方法。毕竟,规定是死的,人是活的。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)