敏捷实践

团队不需要在计划会上考虑到所有事情

几周前,我参加了一个很痛苦的迭代计划会。类似的会议你可能也参加过,团队竭尽所能试图分析出本次迭代所要完成的所有任务,并就每一个任务具体需要花费多少小时进行无休止的争论。

然而这种级别的细节讨论其实是不需要的。


迭代计划会的目的是从产品列表中挑选出本次迭代要完成的条目,并对如何完成有一个大致的想法,达到这个目的并不需要团队了解每一个任务,当然更不需要团队知道某个任务是需要花费4小时还是5小时。

请不要回答“取决于”

我经常会被问到一个团队应该花多长时间召开迭代计划会,与其闪烁其词的说“这取决于。。。”或者“时间刚好足够计划好本次迭代的内容”,有一个更实用的方法决定你是否花了合适的时间在迭代计划会上。。。

通过对成功团队的迭代计划会的多年观察,我建议团队应该在计划会上明确三分之二的本次迭代的任务,也就是本次迭代另外三分之一的任务应该在迭代过程中进一步明确。

一个例子

比如:迭代结束时,团队完成了60个任务,交付了一些产品条目,我的建议是大约三分之二的任务(这个案例中,就是40个)应该在计划会上确认,剩下的三分之一(20个任务)应该留在迭代过程中发现。

当然,如果ScrumMaster在计划会的时候关上门,要求团队更深入更长时间的思考,团队也许可以识别出另外10个任务。但是代价呢?这其实是不值得的,计划会的目的是从产品列表中选出本次迭代要完成的产品条目,第二目标是尽快开始和结束会议。

如果你的团队已经习惯于安排的很满的迭代,也许你需要稍微后退一步,让你的迭代安排不那么满,在《敏捷估算和计划》这本书里,我将这个称之为“计划外时间”。

我的观点是,团队在计划会上应该快速识别他们需要做的最重要的事情,一些小的任务可以先忽略,有一些任务也许团队可以耗时耗力想出来,但是不值得,因为反正团队也不能识别出所有的任务。

开会,散会,干活。

为计划外的工作留下资源

留一些资源给计划会上没有深入分析的任务,留一些资源给计划会上讨论了但是可能会变大的任务,留多少资源呢?给一个预估值,下一个迭代时调整这个预估值,经过几个迭代之后,这个估算值就会接近准确。

注意,我说的是迭代内的任务数,而非小时数,团队在计划会上没有考虑到的任务会变成一些更小的任务,不会有人忘记“实现某个功能”,团队只是未考虑到与之相关的更小的任务。

你认为呢?

你可以在评论中分享你的想法,你是怎么尝试缩短计划会的?哪些办法成功了?哪些办法没有成功?

作者:Mike Cohn

译者:廖希密,浙江移动教练,PMI-ACP,CSPO,CSM