燃盡圖可以預測團隊何時完成工作，也可以用于任何可測量的進度隨著時間變化的項目。無論是老板還是項目成員，都要學會從中獲悉團隊進度，預測團隊項目發展方向。

全文概要

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. 需要調整的團隊燃盡圖

“太快啦”團隊工作燃盡圖：

燃盡圖顯示團隊比預期早很多完成任務。那么有可能他們對自己的力量一無所知。

團隊完成了需求，也沒有繼續完成其他任務即使團隊有時間和精力這么做。這種情形下，需求可能被高估了，所以團隊提前完成了任務。團隊的工作速度沒有被合理的估算。

“太遲啦”團隊工作燃盡圖：

這種燃盡圖明顯在說：“你們沒有完成工作?！?/p>

這種團隊整個迭代過程都在遲到，沒能合理調整工作。燃盡圖還顯示出團隊沒有完成需求，這些需求應該被進一步分解，或者挪到下一個迭代中。

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

大部分市面上的衡量標準都圍繞著這兩項。

本文由@一條翅膀 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。