燃尽图可以预测团队何时完成工作,也可以用于任何可测量的进度随着时间变化的项目。无论是老板还是项目成员,都要学会从中获悉团队进度,预测团队项目发展方向。
全文概要
- 什么是燃尽图?
- Sprint燃尽图要怎么看?
- 我是老板,初次看到燃尽图,有点不适应。
- Sprint和Epic燃尽图是怎么画的?
- 还有什么方法可以衡量敏捷开发团队的工作?
一、什么是燃尽图?
燃尽图(Burndown Chart)是:以图表展示随着时间的减少工作量的剩余情况。
工作量一般以竖轴展示,时间一般以横轴展示。
燃尽图对于预测何时完成工作很有用,燃尽图可以用于任何可测量的进度随着时间变化的项目,包括在敏捷软件开发中,如:Scrum。
燃尽图可以用在Sprint中,也可以用在Epic中。
燃尽图可以清晰的呈现每个时间段有多少已完成工作,还剩下多少工作。以此,预测团队在剩余时间中完成工作的可能性并为当下sprint和未来sprint做出规划。
项目中的每个人都需要看得懂燃尽图。
例子:
(图片来源:http://www.agilenutshell.com/burndown)
- 横轴:显示工作天数 (星标点是当日时间。一般价值点数按日计算。)
- 竖轴:显示剩余工作 (生产价值,在每个冲刺计划会议的时候,团队就应该估算出每个故事的价值,上图例子中的160就是所有故事的价值总和。)
- 计划剩余工作曲线:该曲线实际上是一条直线
- 实际剩余工作曲线:该曲线受团队实际工作效率的影响在计划曲线上下浮动
所以,这个表中我们可以看到:
- 有多少工作已经完成?
- 有多少工作需要完成?
- 每天都干了多少价值的工作?
- 当下的工作速度是否跟得上计划?
- ……
二、Sprint燃尽图要怎么看?
清醒一点,现实中的燃尽图几乎没有办法一步两步按计划走。
很多时候,会发现和想象的不一样,比如:新的需求义无反顾的来了,理想太丰满现实完不成工期了,再或者在老板的重压下团队效率大爆发了……
(图片来源:http://www.agilenutshell.com/burndown)
这里我们来聊一聊几款常见实战燃尽图,我们可以看到什么本质。
Dusan Kocurek给了一些比较好的分析,需要强调的是:同一个图背后的故事千变万化,Dusan的分析可以作为比较好的参考,但仍然需要根据实际情况分析。
1. 优秀团队燃尽图
优秀团队:
这种燃尽图说明该团队可以组织好工作。
产品经理明白迭代的工作量,Scrum master 能够帮助团队完成任务。团队没有超负荷,并按时完成迭代工作。该团队可以正确估算自己的能力,迭代过程中也不需要改正。
哎哟不错团队:
这是典型的工作进度燃尽图,在很多有经验的敏捷团队的工作中都可以看到。该燃尽图说明团队可以按时完成任务,调整以适应迭代中的积压任务,额外努力工作以完成任务。
该团队需要自我反省,在迭代初期看到进度减慢就应该立即讨论如何变动计划。
2. 需要调整的团队燃尽图
“太快啦”团队工作燃尽图:
燃尽图显示团队比预期早很多完成任务。那么有可能他们对自己的力量一无所知。
团队完成了需求,也没有继续完成其他任务即使团队有时间和精力这么做。这种情形下,需求可能被高估了,所以团队提前完成了任务。团队的工作速度没有被合理的估算。
“太迟啦”团队工作燃尽图:
这种燃尽图明显在说:“你们没有完成工作。”
这种团队整个迭代过程都在迟到,没能合理调整工作。燃尽图还显示出团队没有完成需求,这些需求应该被进一步分解,或者挪到下一个迭代中。
3. 新手团队燃尽图
“管理层要来了”团队工作燃尽图:
这种团队可能没有更新自己的工作进度。这里一种情况可能是产品经理增加了一些已经完成的工作,所以燃尽图时机工作曲线是直线。比如:突然之间活儿有一段滑坡。理论上,是因为故事分的不够清楚,或者估算不够准确。
“上天”团队工作燃尽图:
团队第一个迭代一般来说都是这种燃尽图。
这种情况是成功之母,很明显团队没有完成任务。每天都有需求或任务添加到跌倒工作中来,却没有记录任何工作季度。另一个原因可能是迭代中的任务不断地被重新估算。
三、我是老板,初次看到燃尽图,有点不适应
初次尝试敏捷开发的团队,有一个难点是:怎么让不怎么懂技术老板更舒服地敏捷开发和燃尽图?
因为老板初次看到的燃尽图,几乎不会是优秀团队燃尽图, 而是需要调整或者新手团队燃尽图。
此时,他们的心理反应是:
- 一个冲刺过去了,KPI没有完成……
- 一个冲刺过去了,KPI没有完成……
- 一个冲刺过去了,KPI还是没有完成……
请一定给老板打好预防针,燃尽图是一个估算怎样可以更高效产出的方式的参考。
估算这件事,可能需要5个冲刺左右才会开始慢慢接近起来。
事实上,不通过估算的KPI意义也不大。
因为稍微有点经验的程序员,经过几个冲刺的适应期,可以轻轻松松控制整个图的走向。
我曾经合作的团队,程序员曾经开始有意识地控制自己可以做的任务价值数量,在花一半时间做完任务后,每天关闭一个任务,燃尽图是这样的:
再来,太快了团队燃尽图,和太慢了团队燃尽图,看上去,是太快了提前完成了任务。但也有可能太慢团队一开始估算了太多价值,即便产出了比前者更多的价值,看是没有完成之前估算的任务。
所以,燃尽图的定位不应该作为一个唯一/核心的KPI。
个人的经验是:只要可以按时完成产出,团队的工作安排合理,就可以关注其他的指标。
四、燃尽图是怎么画出来的呢?
9012年了,我们要学会用工具。
我们以功能齐全而复杂,速度不在国内也很慢的Jira为例。
1. Sprint燃尽图
- 确定衡量方式:在J中,工作量可以用故事价值,工作时间来衡量。
- 估算每个任务/Issue:这一步往往在Backlog refinement的会议中由团队一起讨论确定。比如故事价值一般会用斐波那契数列, 1,2,3,5,8……来估算。Jira中,直接填在对应estimate位置。燃尽图最大的挑战正是怎么做估算!(所以在此挖个坑:估算这个坑)
2. 生成燃尽图
在Jira中,选择需要的Sprint, 点击reports, 就可以可以轻松容易的生成燃尽图啦。
3. Epic燃尽图
此外,Jira还可以生成Epic燃尽图:
- Epic 菜单。
- 增加的工作:深蓝色区块体现每个Sprint加到这个Epic的工作量。这个例子以故事价值来衡量。
- 剩余工作: 浅蓝色区块表示剩余工作量。
- 完成工作: 浅绿色区块表示每个Sprint完成的工作量。
- 预测项目完成进度: 报表区域会根据已有数据,自动估算出完成这个项目,还需要多少Sprint才可以完成项目。
五、还有什么方法可以衡量敏捷开发团队的工作?
敏捷开发关注两项指标;
- 价值Value
- 流程 Flow
大部分市面上的衡量标准都围绕着这两项。