敏捷迭代周期的探讨
|
我们的迭代计划安排是这样的，迭代周期是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 (文／张松然) ©著作权归作者所有 |
