文章

bundownchart_aftersomeday20

如何使用Leangoo自动生成燃尽图

上一篇,我为大家介绍了如何使用Leangoo管理sprint backlog,今天我们一起来看看Leangoo是如何自动生成Scrum燃尽图的。

什么是scrum燃尽图?

燃尽图能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势,是反应项目进展的一个指示器。一般在每日站会后团队会根据任务的完成情况对其进行更新。
Read more

scrumcn_sprint

敏捷开发日常跟进:燃尽图(下)

这是敏捷开发日常跟进系列的第二篇。
迭代及燃尽图的目标

燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?

1. 按产品经理的要求,交付计划会中计划的用户故事

2. 尽量完成1

之后还会看到,这个定义还有狭隘之处,在系列后面的文章中会提到。

为什么燃尽图不能直接地达成这个目标?潜在的问题包括:

1. 如果燃尽图按时完成,有可能是为了按时完成,同时牺牲了所有故事(重要和不重要的)的质量,换取了进度。

2. 如果燃尽图未按时完成,有可能不是一个故事没有完成,而是所有故事都剩下点活没做完,导致所有故事都无法交付。

3. 如果燃尽图未按时完成,没有完成的故事中,有可能包括了极其重要的一些。

只从燃尽图的形态看,是无法提前识别这三者的,也就因此带来了很多的风险,到迭代的末尾让人大吃一惊。

怎么办呢?
“阶梯燃尽图”

之前听过这个方法,但是刚才在网络上没有找到图片。

方法就是在每个故事完成的时候才把整个故事突然剪掉,从而形成阶梯状。

阶梯状燃烧图的缺点也很明显:刚开始的时候很难看到有燃尽,甚至那些向上拱起的弧形也被掩盖了,日后回顾时,一些细节也很难记起来。

所以一种解决方案,是把普通燃尽图和阶梯燃尽图混合使用,就是同时画两条线。
“跟进图”

跟进图是一些大型团队的创造,由于团队巨大,所以不能指望在迭代的最后用2小时评审完所有工作,所以常常是做完一个评审一个,这就要给每个工作分配一个“跟进人”,他隶属产品部门,没事就盯着“跟进图”看看有没有自己关心的工作做完了。

在为一家游戏公司提供咨询的时候,他们一款产品的团队人数高达88人(另一个甚至到了200人),墙上就用手绘制了一幅巨大的跟进图,每天更新动态,甚至直接在纸上画上小图标,每月画满了,就重新打印一张。

下面这张,是火星人中的跟进图。

 scrumcn1368609297

图中绿色粗线,就是传统的燃尽图;

每当一个故事完成,就会有一个蓝色的标记及完成故事的名字,从而提醒跟进人进行现场预评审;如果长期没有故事完成,燃烧图却还在燃烧,就肯定出现了之前说过的问题了。

右下部分还有一个暗红色的细线,是“溢出时间”,就是超出预期的工作的时间,表明这段时间出现了新的任务;新任务出现的太早不好,因为一般在迭代前期都先完成最重要的故事,不应该引入新任务;但在后期随着最重要的故事完成、评审、因不满意而返工,团队会倾向于把最重要的任务更好地完成,而非草草地把所有故事都凑合完成,在产品研发中,这往往是更能提升产品价值的。

一家叫做广联达的公司在实践中把溢出时间作为负数倒着画,称为“基线下沉”,就是说要去的地方不是0了,而是那个负数,是一个类似目的的很好的实践。

我试了一下也不错,就是图表会变高,显示起来不方便,所以还是改了回来。

这样的跟进图看起来已经很强大了,但是还有一些问题没有解决:

1. 有哪些故事正在做,还没有做,已经开工了但没完成……?

2. 最后剩下了哪些故事没完成?

3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)

4. 如果有跟进人,谁负责跟进哪个?

有些问题需要后面的故事板(看板)解决,有些则需要一个叫做“跟进表”的东西,之后我们说完故事板再回来详细说明。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

 

scrumcn_sprint

敏捷开发日常跟进:燃尽图(上)

这是敏捷开发日常跟进系列的第一篇。

这个系列将涉及燃尽图(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方法,只是被动地发现有些故事没有完成。

……

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

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

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

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

使用敏捷燃尽图管理敏捷项目风险

风险管理是传统项目管理中的重要部分,也是项目管理协会(PMI)知识结构体中的知识领域。在我的很多课程中,参加培训的人会问在Scrum和敏捷项目中如何定位风险管理。一部分人顾虑Scrum或者敏捷项目中会完全忽略项目管理。让我们来看看为什么会这么理解。 Read more