敏捷开发日常跟进系列之一:燃尽图(上)

这是敏捷开发日常跟进系列的第一篇(栏目目录)。

这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动。

日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。

在这个系列之前,还应该有一个敏捷计划系列,描述敏捷开发的从版本规划到计划会估算的详细内容,未来将会补上,当前可以参考2.29版的《火星人敏捷开发手册》,有5页与其相对应。

燃尽图

燃尽图Burdown Chart也叫燃烧图,是罕见的敏捷度量,以至于每当有人问起“敏捷中有度量吗”的时候,第一反应就是它。

燃尽图的全称,应该是“总剩余时间的燃尽图”,就是本次迭代中,所有故事(或拆分的任务,以下仅称故事)的剩余时间总和,随日期的变化而逐日递减的图。

图中左侧460是迭代开始的第一天,所有故事的未完成时间相加为460天,而在最右侧则表明在第17天,所有故事的剩余时间相加变为0,也就是所有故事都完成了。

为什么总和会递减呢?因为每个组员每天都要汇报一件事情:当前正在做的故事,还剩余几天,如果昨天剩余3天,今天剩余2天,那么就为燃烧图贡献了1天的进度。

由于可能出现“昨天剩余3天,又工作了一天后本以为会只剩下2天,结果感觉可能还要3天(甚至变成5天了!)”这种情况,所以燃尽图常常有一些起伏。

燃尽图的“指纹”

图中的燃尽图尽管有一些起伏,依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大,常见的情况包括:

先鼓起后落下

原因是计划会以常常漏掉一些事情,所以开工后不但不燃尽,还发现了很多新的任务。

先完美燃烧,然后突然停止燃烧

一种很常见的情况,如果任务划分太粗,比如长达10天,很容易“做了1天,剩9天;做了1天,剩8天;……到剩2~3天的时候,哎呀,好像搞不定了”。

先缓慢燃烧,然后到快燃尽的时候剩下一堆没完成的任务,被推迟到下个迭代

之前提到过敏捷开发的MoSCoW方法,有些故事是次要的“可以不做的”,所以这种燃烧图也很常见;但是常常有团队没有使用MoSCoW方法,只是被动地发现有些故事没有完成。

……

为了改进这些不完美,有些团队设置了一些度量项来改进燃尽图的结果,比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……

其实不用因为燃尽图的不完美而伤脑筋,在般若敏捷的“无住”中曾经提到,这些方法都非我们的目的,而只是一个中间的工具,因此为了完成我们的最终目的,这些工具和方法都可以灵活变通,而不要追求工具和度量数据本身的完美。

但是,迭代的最终目的到底是什么呢?有哪些“灵活变通”可以应用在燃尽图中呢?且待下回分解。

posted @   我的一天  阅读(761)  评论(0编辑  收藏  举报
努力加载评论中...
点击右上角即可分享
微信分享提示