在運用敏捷的公司中，我們通常離在幾米開外的地方就可以看到團隊工作空間中有各種顏色的便箋，白板，各種圖表等。在敏捷中我們稱這些為信息發射源 Information Radiator。 它可以很好的用於項目的溝通、展示項目的狀態。其中有一種彎曲的曲線，叫做：燃盡圖，它在我們的項目中扮演著非常重要的角色，可以反映當前衝刺執行情況、進度及風險等。這也是每一位敏捷教練及團隊成員都需要能“
讀懂”的圖。那麼問題來了：- 何謂燃盡圖？
- 如何畫燃盡圖？
- 常見的燃盡圖有典型類型及反映出的問題、應對措施？
- 燃盡圖常見問題有哪些及如何處理？
- 有沒有實際項目中的實例分析？
以上，正是今天要跟大家分享的內容。
閒話不多說，艾瑞巴蒂請繫好安全帶，老司機要發車了！
何謂燃盡圖
每天都有人搬磚，然後磚頭就會越來越少。也就是總工作量每天都會隨著時間推移而減少，所以就會形成一個斜向右下延伸的直線（理想狀態）。高逼格一點的表示就是會有一個類似這個幾何特徵的圖形：y=kx+b（k<0,b>0）。
我們通常會在在一個XY座標軸的座標系表示他們。其中，X軸通常代表時間（天），Y軸代表剩餘工作量。我們把這個起名叫：燃盡圖。
理想狀態下，大家每天都按時搬磚，不打醬油。那麼它將會是一條直線，形如下圖：
但現實中，我們怎麼可能不打醬油！所以就會變成了彎彎曲曲的折現，也就有了實際曲線這麼一說。我們通常用實際曲線來標識實際每天完成的工作量。
這是個很好的進度展示的工具，想想看我們之前的項目進度計劃，要麼是存在PM的電腦裡，要麼是存在PM的腦海裡…PM不在週會上通報現在的進度，鬼知道現在進度如何了。 現在我們把這個燃盡圖放到團隊工作空間中，這樣每個人都能看到現在項目的進度狀態了。而且在Daily Meeting上也會同步更新燃盡圖，這樣可以給團隊一種緊迫感。信息透明化給團隊帶來的內部的自我刺激，遠比PM的指令式管理要好很多。所以這也是燃盡圖的非常重要的作用之一。
如何畫燃盡圖
我們在每日的Daily Meeting會議上，每個團隊成員都會介紹昨天完成了哪些事情，那這些統計數據就是實際完成的活，用總量-實際完成，就得到了當前時間的剩餘工作量了。 需要注意的是，Y軸代表的是當前剩餘的工作量，做了90%，和做了1%，都叫沒做。
常見燃盡圖類型有哪些
Kane Mar將燃盡圖分為七種情況，個人根據理解及實際情況修改如下幾種：
Case1：完美型。特徵：一條直線。圖形如下：
這種情況除非你團隊都是神，否則基本上不可能出現這種情況。如果你的團隊是這樣的圖，很可能遇到了個假的團隊：本燃盡圖純屬虛構，如有完美純屬巧合！
有的Team領導過分關注績效，看到燃盡圖不完美團隊就挨批。所以團隊就畫個完美的圖，領導一看，大呼：666，這個sprint大家都很努力，下班我請客去嗨皮！
Case2：啤酒肚。特徵：圓弧狀，且實際曲線一直在理想直線上方。圖形如下：
出現這種情況的原因：
- 前期需求估算不準確。
- 團隊遇到障礙，團隊成員能力有限。
- 團隊有很強的自我調整能力，可以完成很多額外的工作，不完成目標不回家的願景。
這種情況要注意，前期發現一直有這個問題的時候，我們處於高風險狀態，很可能這個sprint的目標無法實現。在中期SM就應當進行調整，比如：
- 當前需求，有沒有其他優化方法可以實現。
- 某一個人或某幾個人在一個問題上卡住了，移除障礙。
- 能不能跟PO協商，減少當前sprint承諾的內容，如果一定做不完那就跟PO協商，做高優先級的，其他的放到下個sprint。
Case3：大S型。特徵：前期啤酒肚，後期快速下降且在直線下方。圖形如下：
這種情況說明團隊的應變能力強，不斷調整速度來完成目標。當然，也有一種可能是大家看到現在風險比較高，然後加班（多麼痛的領悟，誰說敏捷沒加班的，那得看是誰在做…），不把曲線降下來誰都別回家！！
Case4：小S型。特徵：搖擺搖擺…我搖擺搖擺…… 圖形如下：
這種情況屬於正常情況，團隊不斷的在修正自己的速率，而且最終完成了目標。如果你的團隊實際燃盡圖與此類似，恭喜你。
Case5：TBD。特徵：沒終點，剩一些活做不完了。 圖形如下：
可能情況：
- 領導壓迫給活多，每天都有新需求。
- 團隊開黑打醬油去了，很少人做事。
- SM打醬油，無風險預估及處理能力。
- 團隊不能合理安排工作。
遇到這種問題，還是要做風險預判。實在做不完的推到下個sprint，但千萬別給這個sprint延長週期（比如2周調成3周）。規則一旦被打破，下次團隊會不再遵守Timebox（時間盒），也就沒有固有的節奏感了。
Case6：開掛。特徵：直線下降，一直處於理想曲線下方。 圖形如下：
可能情況：
- 需求被高估了，實際並沒有這麼多的活做。
- 需求被刪減了。
- 公司來了新的鼓勵師，程序員玩命工作，效率很高。
這種情況最看不下去的就是PO，通常會鼓（ya）勵（po）大家多領一些任務，同樣，作為一名專（da）業（za）的SM，也應當鼓勵團隊多搬磚多領錢，這樣才能給妹子買包包啊！ SM要優化團隊效率，保持穩定的節奏感。
Case7：上天了。特徵：一直上翹。 圖形如下：
這種情況曲線沒有下降，反而一直上升，最可能的情況是每天都有新需求加入到當前sprint中。當然，也有可能是開發人員評估工作的時候太過於樂觀，導致工作量不斷膨脹，最後的結果是當前sprint必須終止。
以上情況描述了絕大多數情況下的燃盡圖類型，SM要做的就是提前預判，風險預防，而不是等到了問題發生才去解決。
燃盡圖常見問題
Q1：不知道怎麼畫
這種情況可能有：
- 團隊成員都是新成員，沒接觸過敏捷，所以前期都是交由SM來繪製燃盡圖，但是後期，最好是讓團隊成員來進行更新。
- 沒有工時估算，也自然就沒辦法知道做了多少活，所以最好是估算每個活動的工時。
Q2：顆粒度大小問題
這種情況可能有：
- 一般來說Y軸常用小時數或者故事點數。
- 顆粒度最好是1天可以完成的事情。這樣不至於每天Daily Meeting都說同一句話：“我昨天做這部分的代碼編寫，今天繼續……”。二來，可以更好的跟蹤任務項，減少進度風險。
這裡面還有個問題是story數量的問題。如果story太少，我們畫燃盡圖的時候會發現折現非常明顯，可能會讓我們錯誤的認為當前速度及風險比較大。
Q3：測試背鍋
燃盡圖變成了Case5:TBD的情況，領導一問，開發同學異口同聲：測試不給力，我們的活都幹完了。
很多時候開發和測試是敵對的雙方。研發小夥伴在sprint最後一刻才提交給測試，測試自然就沒有時間來做測試的工作。然後就很無辜的做了背鍋俠…
又或者，開發質量不過關，測試測出來很多bug，然後開發返工，導致sprint延期，開發小夥伴同聲：你丫測試不給力，這麼晚才告訴我有問題。測試同學繼續背鍋… 這種情況，我們最好不要把所有的故事都在同一個時間完成，同樣，也要提倡團隊跨職能發展，打造T型團隊人才。
Q4：燃盡圖日期加了1天
當還差1天的工作就可以完成這個sprint的時候（此時團隊24h工作無休），你會怎麼做？很多Team會在燃盡圖加1天，這樣就可以完美的抵達Y=0的點。
切記不可這麼做！一旦規則被打破，團隊成員也會認為這個時間都是可協商的，也會破壞固有的節奏感。這次加了，那下次還剩1.5天的工作量的時候，要不要加？
Q5：只統計某個工作量
燃盡圖顯示的是整個team的工作實際統計情況，而非單獨開發或者測試的工作量（排除單一組件團隊的特例）
Q6：燃盡圖比較
如果公司有幾個敏捷項目同時在運作，領導看到A組同學的燃盡圖說到：“你看B組，他們速度多快啊，你們這速度太慢了，你們這周過來加加班吧，把速度搞上去…” 這種情況很明顯是被 “懂”敏捷的領導給坑了。遇到個完全不懂的倒還好，最怕的就是一知半解的。
不同team甚至是同一個team，燃盡圖都可能無法比較。比如有如下原因都可能導致燃盡圖不同：
- Story拆分的粒度是否統一。
- 團隊成員是否有變化。
- 時間週期是否一致。
- story point的基準是否一致。
燃盡圖實例剖析
實例1：是否會畫燃盡圖？下圖是某項目2天的執行情況，請問A B C三個點分別應該是多少？
分析：燃盡圖中Y軸代表的是剩餘工作量，掌握這個即可知道是多少數值。只有放到Done列表的，叫完成。
A=5+3+8+5+7=28 B=28-7=21 C=21-5-(8-3)=11，因為No.6這個編號的工作，8個點的活變成了3個點，所以剩餘少了5個。再加上No.5完成了。故總計完成10個點的活。
實例2：截取了IT事業部某軟件外包項目燃盡圖實例，跟大家一起分享我們出了什麼情況以及如何解決的。（2周為一個sprint，團隊已經運用敏捷一段時間）
我們在每日站會上進行數據的收集和更新，然後根據SBI（sprint backlog items）來更新數據。
迭代1分析：
- 在2.27-28這一天實際曲線不但沒有下降，反而上升。主要原因：
（a）開始第一個sprint，需求梳理的不是很清楚，有新需求新增到SPI中（團隊一開始是拒絕的，但PO比較強勢，必須得加進來…）。
（b）工作項的分解不熟悉。task重新估算之後，用時有所增加。
此時項目已經出現了風險，而且有將近30個點新增。所以為了解決問題，符合預期。在2.28-3.1，我們採用了加班的方式。
- 3.1-3.2，僅下降了10個點，主要原因：
（a）前一晚加班太晚，今天效率不高，還有幾個同事休假。也可以看出，加班過猛也不是好事…效率最重要。
（b）有個技術坑阻礙了當前的項目進度，team研究好久都沒搞定。
- 3.3-3.4 休息日。開發小夥伴順便在週末研究了一下技術難題。
- 3.5-3.9，從曲線的斜率可以看出，團隊的實際速度高於理想速度，逐步貼近我們的理想曲線。
- 到3.10號，我們還剩10個點的活沒幹完，只要原因：開發組將迭代版本提交給測試進行迭代系統測試導致。
（a）開發將迭代版本提交給測試，遇到一些重要bug需要處理，導致待開發項也沒有時間安排處理。
（b）估算存在一些問題，項目設置的冗餘時間也已經用完。
迭代2分析：
- 鑑於在迭代1中最終有故事沒有完成，而且團隊在整個sprint中工作壓力較大，所以我們在估算工作量總工時的時候，只挑選了400個點的工作，相比迭代1少了20個。這也說明在敏捷中，即使是同一個團隊，每次能完成的工作量，也會有不同。
- 3.17-3.20期間，從250點直落到150點，主要是由於抽調了部分的需求，放到下個迭代中。所以曲線直接掉到理想曲線下方。
- 3.20-3.25，速率正常，3.25剛好完成所有的工作。
總結
燃盡圖作為敏捷可視化管理的工具，發揮著重要的作用。一葉知秋，作為敏捷教練應當能夠從每一張圖表、每一條折線，分析出項目背後的問題，防範於未然。燃盡圖的數據來源於日常工作，出自於團隊本身。所以數據的準確性，直接決定了燃盡圖的價值。
怎麼樣的燃盡圖才是有價值的呢？
- 數據要真實，統計全面。這樣才能反映出task的執行情況。
- 對於工作量的預估要儘量準確，這就對團隊的技術水平有一定的要求。
- 粒度的分解要儘量落實到每一天。太大的粒度無法跟蹤，而且不利於工作的估計。
文末彩蛋：用excel畫燃盡圖的方法步驟，評論獲取
閱讀更多 一起學PMP項目管理 的文章
