專案執行的過程中，經常需要透過各種圖表來向利害關係人說明進展，針對不同的階段或對象，所使用的圖表也有所差異。在敏捷軟體開發專案中，常用一種稱之為「燃盡圖(Burndown Chart)」的方式來展示進度。
燃盡圖是用來表示剩餘工作量的圖示。以下圖為例，藍色線段代表基準線表示每一天預估的剩餘工作時數，假設完成某一項任務所需的時間為300小時，在不考慮任何變數影響的情況下，剩餘工作時數會隨時間等量遞減，直到表定完成的日期時，剩餘時數等於零。紅色線段為實際運作後所繪製的曲線，每天消耗的時數不固定(如藍色長條圖所示)，因此線段會出現波動，在起初的5天內，紅色線段位在藍色下方，代表實際的情況較預期落後，直接第5天後，進度開始超前，並且在最後一天完成任務。
專案執行過程難免會遇到各種阻礙和困難，甚至不同專案之間的資源排斥，導致實際能投入的工作時數會經常變化，因此基準線和實際線出現差異是非常正常的現象，只是，利用工作時數來估算工作量及完成度，本身就存在不少盲點，要畫出像上方漂亮的示意圖並不容易，大部分的時候我們可能會得到更加扭曲的結果。
這張是我從過去實際運作的專案中，擷取一段時間(約兩周)所繪製的燃盡圖。灰色是所謂的基準線，紅色則是實際的剩餘時數。為什麼和上方的示意圖有如此巨大的落差? 紅色線段在大部分的時間內為何不減反增? 要解釋這個現象，可以從幾個面向來看
1.預估工時的誤差
首先要理解剩餘工作時數的定義，來自於我們先預估了某項任務所需的工作總時數，或者距離Dedline之前所擁有的時間，預估值本身就會存在誤差，當實際執行之後，發現複雜程度比預期高，就必須投入更多的時間與資源。
2.任務數的變化
燃盡圖所繪製的通常是許多任務的集合，也就是說，工時是來自各個任務工作包的加總，我們理解每一項任務的估算會有些偏差時，就能理解這些偏差的集合只會更加明顯。再者，如果工作包未能適當拆解、分類，執行過程中可能就會衍生新任務、產生新的估算工時，以圖中的May22-May24為例，由於多了新任務且尚未被執行，因此剩餘工時的總數就出現了反向增加的情況。
3.工時填報不準確
我們都知道，填報工時對團隊而言是一項不討喜的作業，大部分的成員一天內可能同時執行二至三項工作，甚至更多，有時候是任務之間彼此關聯性高，因此必須同時處理，有時則是被他人打斷，不得已在不同任務之間轉換，不論是何種情況，要能確實填報耗費的工時都不容易，而這又會讓實際工時的計算結果產生新的誤差。從上圖我們可以很清楚發現May12到May23左右的時段，實際剩餘時間幾乎是沒有變動的，但綠色Time Spent曲線卻不斷上升，表示工時雖然持續增加，與目標的距離卻沒有拉近，是一個非常不健康的現象。
既然利用剩餘工時來繪製的燃盡圖，有需要被克服盲點，在說明專案進展時，或許可考慮以「任務數」替代剩餘工時，以下是我用相同時間的資料所繪製的範例。
圖中我們可以發現曲線的變化相較前一張圖表平滑了一點，剩餘工作數雖然偶有停駐，但整體仍是逐漸降低，顯示團隊正在努力消化任務，在第一天甚至有超前的跡象，此時若有新增的任務數可供參考，或許就更能看出專案的進展。
回歸到敏捷管理的精神來看，通常一個(組)執行的週期約為兩周左右，以7-8人左右的敏捷團隊編制，這樣的時間和人力規模，每個周期能處理的任務數並不會太多，因此範疇也理當要被適當控管，不應該出現大幅變化，前述兩張圖表很明顯在需求的管控上出現了問題，後續就出現各種連鎖反應，圖表的可信度當然就大幅降低。
如果繪製圖表的目的，是在評估專案估算工時、拆解任務的準確性，那麼上方兩張燃盡圖雖然醜了點，卻還是可以讀出透露不少訊息，團隊們可以先從上述幾個面向中找出需要修正的方向，持續進行改善，直到燃盡圖的結果漸漸趨於正常，就代表大家對專案任務的掌控性越來越高，漸漸邁一個成熟的敏捷團隊。
反之，如果上述的燃盡圖想用來表達專案進展，那麼PM勢必還需要多做一些加工。於是我試著將圖表增添一些視覺效果，並且附上參考資訊，讓它看起來更易閱讀，各位也可以依據自身專案的需求，適度調整圖表，讓你的簡報更有說服力。
留言列表
