敏捷開發日常跟進系列之一：燃盡圖 (burndown chart)（上）

這是敏捷開發日常跟進系列的第一篇（欄目目錄）。

這個系列將涉及燃盡圖 (burndown chart)（Burndown Chart）、故事板（看板）、每日立會等內容，描述在計劃會之後，評審會之前，敏捷Team Dev內部產出與產品經理和專案經理的各種活動。

日常跟進中的某些內容比如團隊工作模型、預估會議、使用者故事跟進等在之前的松結對程式設計、團隊管理、使用者故事、產品管理等系列中有所描述。

在這個系列之前，還應該有一個敏捷計劃系列，描述敏捷開發的從版本規划到計劃會估算的詳細內容，未來將會補上，當前可以參考2.29版的《火星人敏捷開發手冊》，有5頁與其相對應。

燃盡圖 (burndown chart)

燃盡圖 (burndown chart)Burdown Chart也叫燃燒圖，是罕見的敏捷度量，以至於每當有人問起“敏捷中有度量嗎”的時候，第一反應就是它。

燃盡圖 (burndown chart)的全稱，應該是“總剩餘時間的燃盡圖 (burndown chart)”，就是本次迭代中，所有故事（或拆分的任務，以下僅稱故事）的剩餘時間總和，隨日期的變化而逐日遞減的圖。

圖中左側460是迭代開始的第一天，所有故事的未完成時間相加為460天，而在最右側則表明在第17天，所有故事的剩餘時間相加變為0，也就是所有故事都完成了。

為什麼總和會遞減呢？因為每個組員每天都要彙報一件事情：當前正在做的故事，還剩餘幾天，如果昨天剩餘3天，今天剩餘2天，那麼就為燃燒圖貢獻了1天的進度。

由於可能出現“昨天剩餘3天，又工作了一天后本以為會只剩下2天，結果感覺可能還要3天（甚至變成5天了！）”這種情況，所以燃盡圖 (burndown chart)常常有一些起伏。

燃盡圖 (burndown chart)的“指紋”

圖中的燃盡圖 (burndown chart)儘管有一些起伏，依然是屬於比較完美的燃盡圖 (burndown chart)。實際上每個團隊完成迭代的過程差別很大，常見的情況包括：

先鼓起後落下

原因是計劃會以常常漏掉一些事情，所以開工後不但不燃盡，還發現了很多新的任務。

先完美燃燒，然後突然停止燃燒

一種很常見的情況，如果任務劃分太粗，比如長達10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的時候，哎呀，好像搞不定了”。

先緩慢燃燒，然後到快燃盡的時候剩下一堆沒完成的任務，被延遲到下個迭代

之前提到過敏捷開發的MoSCoW方法，有些故事是次要的“可以不做的”，所以這種燃燒圖也很常見；但是常常有團隊沒有使用MoSCoW方法，只是被動地發現有些故事沒有完成。

……

為了改進這些不完美，有些團隊設定了一些度量項來改進燃盡圖 (burndown chart)的結果，比如“迭代按時燃盡的次數”“剩餘故事佔總故事的比例”……

其實不用因為燃盡圖 (burndown chart)的不完美而傷腦筋，在般若敏捷的“無住”中曾經提到，這些方法都非我們的目的，而只是一個中間的工具，因此為了完成我們的最終目的，這些工具和方法都可以靈活變通，而不要追求工具和度量資料本身的完美。

但是，迭代的最終目的到底是什麼呢？有哪些“靈活變通”可以應用在燃盡圖 (burndown chart)中呢？且待下回分解。