从老板到项目成员，如何从燃尽图中洞悉团队工作？

燃尽图可以预测团队何时完成工作，也可以用于任何可测量的进度随着时间变化的项目。无论是老板还是项目成员，都要学会从中获悉团队进度，预测团队项目发展方向。

全文概要

1. 什么是燃尽图？
2. Sprint燃尽图要怎么看？
3. 我是老板，初次看到燃尽图，有点不适应。
4. Sprint和Epic燃尽图是怎么画的？
5. 还有什么方法可以衡量敏捷开发团队的工作？

一、什么是燃尽图？

燃尽图（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燃尽图

1. 确定衡量方式：在J中，工作量可以用故事价值，工作时间来衡量。
2. 估算每个任务/Issue：这一步往往在Backlog refinement的会议中由团队一起讨论确定。比如故事价值一般会用斐波那契数列， 1，2，3，5，8……来估算。Jira中，直接填在对应estimate位置。燃尽图最大的挑战正是怎么做估算！（所以在此挖个坑：估算这个坑）

2. 生成燃尽图

在Jira中，选择需要的Sprint, 点击reports, 就可以可以轻松容易的生成燃尽图啦。

3. Epic燃尽图

此外，Jira还可以生成Epic燃尽图：

1.  Epic 菜单。
2. 增加的工作：深蓝色区块体现每个Sprint加到这个Epic的工作量。这个例子以故事价值来衡量。
3. 剩余工作: 浅蓝色区块表示剩余工作量。
4. 完成工作: 浅绿色区块表示每个Sprint完成的工作量。
5. 预测项目完成进度: 报表区域会根据已有数据，自动估算出完成这个项目，还需要多少Sprint才可以完成项目。

五、还有什么方法可以衡量敏捷开发团队的工作？

敏捷开发关注两项指标;

1. 价值Value
2. 流程 Flow

大部分市面上的衡量标准都围绕着这两项。