燃盡圖（burn down chart）是在項目完成之前会涎，對需要完成的工作的一種可視化表示砸彬。我們經(jīng)常用到的燃盡圖有兩種類型椅亚，一是基于任務(wù)（task）的燃燒；另一種是基于故事點（Story point）的燃燒民傻。燃盡圖經(jīng)常用在敏捷項目里，如果從迭代周期的維度看场斑，還可以分成Sprint的燃盡圖漓踢，用來記錄Sprint的進度；也可以是release的燃盡圖漏隐，用來記錄整個scrum項目的進度喧半。
上圖是一個典型的sprint（iteration）燃盡圖，如果迭代的Burndown Chart一直是上升狀態(tài)青责，或當Sprint進行一段時間之后挺据，Sprint Burndown Chart上當前點的Y值仍然與Sprint剛開始時相差無幾，就說明這個Sprint中的任務(wù)過多脖隶，要拿掉一些story以保證這個迭代能順利完成扁耐。如果Sprint Burndown Chart下降得很快，例如Sprint剛過半時Y值已經(jīng)接近零了产阱，則說明為這個Sprint分配的任務(wù)太少婉称，還要多加一些任務(wù)進來。在迭代計劃會議上构蹬，如果團隊對即將要做的任務(wù)理解和認識不充分王暗，就很可能導致這兩種情況的出現(xiàn)∽玻總之俗壹，燃燒曲線是衡量團隊進度的重要工具。
雖然大家對燃盡圖都很熟悉藻烤，但我們在實際使用燃盡圖的過程中策肝，仍然有過如下三個疑問：
1. 在繪制燃盡圖的時候肛捍，什么時候選擇基于task度量，什么時候選擇基于story point度量之众？
2. 誰來給出起始的故事點或者任務(wù)的estimation拙毫？
3. 在使用一些項目管理工具的時候，對于task的estimatoin棺禾，remaining time以及correction缀蹄，這些不同的field代表什么意思？誰來給出這些值膘婶？何時修改這些值缺前？
疑問1：在繪制燃盡圖的時候，什么時候選擇基于task度量悬襟，什么時候選擇基于story point度量衅码？
想要找到這個問題的答案，必須理解這兩種燃盡圖各自側(cè)重的意義脊岳。雖然兩者都是用來表示項目或者迭代進度逝段，但story point更多體現(xiàn)的是業(yè)務(wù)價值的完成，比較宏觀割捅；而task關(guān)注的是具體任務(wù)的完成奶躯，較為微觀。所以亿驾，基于story的燃盡嘹黔，是在記錄燃燒了多少業(yè)務(wù)價值，離最終交付給客戶業(yè)務(wù)價值還有多遠莫瞬。我們知道衡量一個story是否完成還依賴于DOD（definition of Done)儡蔓， 不同的團隊對DOD有不同的定義，例如有的團隊認為story必須經(jīng)過showcase才算完成疼邀，那么會明顯影響到基于story point的燃盡曲線浙值。但task關(guān)注的是敏捷團隊內(nèi)部的開發(fā)情況，是基于person day的檩小，只要這個開發(fā)或者測試的任務(wù)完成就算DONE开呐。由此可見，story point的燃盡圖體現(xiàn)的敏捷流程规求，關(guān)注業(yè)務(wù)價值的交付筐付，可以暴露諸如測試滯后，協(xié)作子系統(tǒng)之間的依賴等問題阻肿；task（Person day）燃盡圖體現(xiàn)的是開發(fā)和測試進度瓦戚，關(guān)注團隊內(nèi)部的完成風險。
所以這兩種方式有各自的側(cè)重點丛塌，可以同時使用较解。但對于一個成熟度不是很高的團隊來講畜疾，使用task的burn down chart似乎更加現(xiàn)實；如果團隊足夠成熟印衔，可以均勻地拆分user story啡捶，且每個story都比較小，整個組織也比較敏捷的話奸焙，就以用story burn down chart來取代task的burn down chart瞎暑。也可以將兩圖合并, 同時從基于task working hours的burn down與基于story points的burn up兩個視角關(guān)注項目進度。
疑問2： 誰來給出起始的故事點或者任務(wù)的起始estimation与帆？
對于誰來給出起始故事點數(shù)來說了赌，答案比較明顯，那就是團隊給出玄糟。但對于誰來給出具體任務(wù)的初始estimation勿她，不同的團隊有不同的做法，我們的實踐也是團隊給出阵翎。
在迭代開始的計劃會議里逢并，有很大一部分時間是團隊一起拆分story，并且給出每個task的estimation贮喧。由于person hour和個體關(guān)系很大，不同的人對同一個任務(wù)預估的時間也不相同猪狈，也就說團隊一起給出的這個estimation可能是取了一個平均值箱沦。
那么問題來了，這樣做到底什么意義雇庙？平均值會不會不準呢谓形？其實計劃會議上所做的所有預估都是為了更好地在團隊內(nèi)達成對業(yè)務(wù)和工作量上的一致理解，團隊不應(yīng)該把關(guān)注點放在準確或不準確上疆前。無論是故事點還是任務(wù)的PH寒跳，都應(yīng)該建立在團隊每個人對問題的一致理解之上。實際上竹椒，根據(jù)集體智慧的原理童太，多人一起預估會更加接近將要發(fā)生的實際值，也更能幫助團隊做為整體對客戶做出承諾胸完。
疑問3：在使用一些項目管理工具的時候书释，對于task的estimation，remaining time以及correction赊窥，這些不同的field代表什么意思爆惧？誰來修改這些值？何時修改這些值锨能？
首先要理解扯再，敏捷里所有BVC（big visual chart）芍耘，首要考慮的就是，這些圖形或圖表能夠真實地反映項目與團隊的實際情況熄阻，基于task的燃盡圖也是如此斋竞。通常當進入實際開發(fā)，task的owner才會被確定饺律，那么這個owner就可以根據(jù)自己實際的開發(fā)情況來調(diào)整時間窃页。
不同的項目管理工具有不同的設(shè)置，例如IBM的RTC复濒，task有三個與時間相關(guān)的field脖卖，其中estimation就是計劃會議上大家一起給定的那個person hours，這個值不會再去修改巧颈；第二個是remaining time畦木，這個值相當關(guān)鍵，它直接影響到燃盡圖的實際曲線砸泛，owner應(yīng)該頻繁地對剩余時間進行修改十籍，以便真實地反應(yīng)任務(wù)的實際進度，一般至少是在下班前或者任務(wù)切換時修改唇礁；第三個值是correction勾栗，代表實際可能要花費的時間，越是接近任務(wù)完成的尾聲盏筐，值越接近實際围俘。這是一個非常令人迷惑的field，因為它十分容易讓人聯(lián)想到事后度量琢融，甚至是績效評估界牡，而敏捷是反對這類度量的。實際上漾抬，correction本意是為了真實的得出remaining hours宿亡，在實際的開發(fā)過程中，隨著時間的推進纳令，owner越來越清楚可能的實際時間花費挽荠，這個值也許比計劃會議上預計的estimation大，也許比estimation小平绩，owner通過不斷調(diào)整correction坤按，將它與已經(jīng)耗費的小時數(shù)做減法，從而得出剩余時間馒过，使得燃盡圖始終保持能夠真實反映迭代進度的能力臭脓。此外，IBM RTC 自動生成的燃盡圖也會有一條線是專門反映預估與實際的差距腹忽，可以用于幫助團隊逐漸改進自己的計劃會議来累。所以砚作，correction也應(yīng)該是隨時可以修改的，并且修改的人是task owner嘹锁。
舉一個極端的例子來說明一下葫录，假設(shè)一個迭代有6天，這個迭代里只有一個任務(wù)领猾，estimation是24ph米同。進行到第三天的時候（已花費12小時），程序員突然意識這個任務(wù)要比原來想象中復雜摔竿，于是調(diào)整correction為30ph面粮，remaining time變成18ph （correction - 已花費）。由下圖一可知继低，更改correction是會影響planned以及Remaining這兩條曲線熬苍。當然在實際的操作上，尤其是團隊采用物理看板袁翁，由人工去維護燃盡圖的時候柴底，通常只需要簡化成圖二。當然粱胜，一個迭代是由多個task組成柄驻，那么整個燃盡圖實際上是所有task不斷更改correction與remaining time的效果疊加，籍此將Risk和Progress透明化焙压，指導團隊及時做出適應(yīng)與調(diào)整鸿脓。
一個敏捷團隊在開始使用燃盡圖的時候，容易陷入一個誤區(qū)冗恨，就是將注意力放在生成漂亮的曲線上答憔，而不是項目本身味赃，這就失去了燃盡圖的意義掀抹。所以作為管理層絕對不能過分依賴它作為監(jiān)督和考核的依據(jù)，否則就會產(chǎn)生bed smell心俗。
