几周前，我参加了一个很痛苦的迭代计划会。类似的会议你可能也参加过，团队竭尽所能试图分析出本次迭代所要完成的所有任务，并就每一个任务具体需要花费多少小时进行无休止的争论。
然而这种级别的细节讨论其实是不需要的。
迭代计划会的目的是从产品列表中挑选出本次迭代要完成的条目，并对如何完成有一个大致的想法，达到这个目的并不需要团队了解每一个任务，当然更不需要团队知道某个任务是需要花费4小时还是5小时。
请不要回答“取决于”
我经常会被问到一个团队应该花多长时间召开迭代计划会，与其闪烁其词的说“这取决于。。。”或者“时间刚好足够计划好本次迭代的内容”，有一个更实用的方法决定你是否花了合适的时间在迭代计划会上。。。
通过对成功团队的迭代计划会的多年观察，我建议团队应该在计划会上明确三分之二的本次迭代的任务，也就是本次迭代另外三分之一的任务应该在迭代过程中进一步明确。
一个例子
比如：迭代结束时，团队完成了60个任务，交付了一些产品条目，我的建议是大约三分之二的任务（这个案例中，就是40个）应该在计划会上确认，剩下的三分之一（20个任务）应该留在迭代过程中发现。
当然，如果ScrumMaster在计划会的时候关上门，要求团队更深入更长时间的思考，团队也许可以识别出另外10个任务。但是代价呢？这其实是不值得的，计划会的目的是从产品列表中选出本次迭代要完成的产品条目，第二目标是尽快开始和结束会议。
如果你的团队已经习惯于安排的很满的迭代，也许你需要稍微后退一步，让你的迭代安排不那么满，在《敏捷估算和计划》这本书里，我将这个称之为“计划外时间”。
我的观点是，团队在计划会上应该快速识别他们需要做的最重要的事情，一些小的任务可以先忽略，有一些任务也许团队可以耗时耗力想出来，但是不值得，因为反正团队也不能识别出所有的任务。
开会，散会，干活。
为计划外的工作留下资源
留一些资源给计划会上没有深入分析的任务，留一些资源给计划会上讨论了但是可能会变大的任务，留多少资源呢？给一个预估值，下一个迭代时调整这个预估值，经过几个迭代之后，这个估算值就会接近准确。
注意，我说的是迭代内的任务数，而非小时数，团队在计划会上没有考虑到的任务会变成一些更小的任务，不会有人忘记“实现某个功能”，团队只是未考虑到与之相关的更小的任务。
你认为呢？
你可以在评论中分享你的想法，你是怎么尝试缩短计划会的？哪些办法成功了？哪些办法没有成功？
作者：Mike Cohn
扫一扫
1332
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
