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