BurndownChart_ideal.PNG專案執行的過程中,經常需要透過各種圖表來向利害關係人說明進展,針對不同的階段或對象,所使用的圖表也有所差異。在敏捷軟體開發專案中,常用一種稱之為「燃盡圖(Burndown Chart)」的方式來展示進度。

燃盡圖是用來表示剩餘工作量的圖示。以下圖為例,藍色線段代表基準線表示每一天預估的剩餘工作時數,假設完成某一項任務所需的時間為300小時,在不考慮任何變數影響的情況下,剩餘工作時數會隨時間等量遞減,直到表定完成的日期時,剩餘時數等於零。紅色線段為實際運作後所繪製的曲線,每天消耗的時數不固定(如藍色長條圖所示),因此線段會出現波動,在起初的5天內,紅色線段位在藍色下方,代表實際的情況較預期落後,直接第5天後,進度開始超前,並且在最後一天完成任務。
 

專案執行過程難免會遇到各種阻礙和困難,甚至不同專案之間的資源排斥,導致實際能投入的工作時數會經常變化,因此基準線和實際線出現差異是非常正常的現象,只是,利用工作時數來估算工作量及完成度,本身就存在不少盲點,要畫出像上方漂亮的示意圖並不容易,大部分的時候我們可能會得到更加扭曲的結果。

BurndownChart_RemainTime.PNG

這張是我從過去實際運作的專案中,擷取一段時間(約兩周)所繪製的燃盡圖。灰色是所謂的基準線,紅色則是實際的剩餘時數。為什麼和上方的示意圖有如此巨大的落差? 紅色線段在大部分的時間內為何不減反增? 要解釋這個現象,可以從幾個面向來看

1.預估工時的誤差
首先要理解剩餘工作時數的定義,來自於我們先預估了某項任務所需的工作總時數,或者距離Dedline之前所擁有的時間,預估值本身就會存在誤差,當實際執行之後,發現複雜程度比預期高,就必須投入更多的時間與資源。

2.任務數的變化
燃盡圖所繪製的通常是許多任務的集合,也就是說,工時是來自各個任務工作包的加總,我們理解每一項任務的估算會有些偏差時,就能理解這些偏差的集合只會更加明顯。再者,如果工作包未能適當拆解、分類,執行過程中可能就會衍生新任務、產生新的估算工時,以圖中的May22-May24為例,由於多了新任務且尚未被執行,因此剩餘工時的總數就出現了反向增加的情況。

3.工時填報不準確
我們都知道,填報工時對團隊而言是一項不討喜的作業,大部分的成員一天內可能同時執行二至三項工作,甚至更多,有時候是任務之間彼此關聯性高,因此必須同時處理,有時則是被他人打斷,不得已在不同任務之間轉換,不論是何種情況,要能確實填報耗費的工時都不容易,而這又會讓實際工時的計算結果產生新的誤差。從上圖我們可以很清楚發現May12到May23左右的時段,實際剩餘時間幾乎是沒有變動的,但綠色Time Spent曲線卻不斷上升,表示工時雖然持續增加,與目標的距離卻沒有拉近,是一個非常不健康的現象。

既然利用剩餘工時來繪製的燃盡圖,有需要被克服盲點,在說明專案進展時,或許可考慮以「任務數」替代剩餘工時,以下是我用相同時間的資料所繪製的範例。
BurndownChart_issue.PNG

圖中我們可以發現曲線的變化相較前一張圖表平滑了一點,剩餘工作數雖然偶有停駐,但整體仍是逐漸降低,顯示團隊正在努力消化任務,在第一天甚至有超前的跡象,此時若有新增的任務數可供參考,或許就更能看出專案的進展。

回歸到敏捷管理的精神來看,通常一個(組)執行的週期約為兩周左右,以7-8人左右的敏捷團隊編制,這樣的時間和人力規模,每個周期能處理的任務數並不會太多,因此範疇也理當要被適當控管,不應該出現大幅變化,前述兩張圖表很明顯在需求的管控上出現了問題,後續就出現各種連鎖反應,圖表的可信度當然就大幅降低。

如果繪製圖表的目的,是在評估專案估算工時、拆解任務的準確性,那麼上方兩張燃盡圖雖然醜了點,卻還是可以讀出透露不少訊息,團隊們可以先從上述幾個面向中找出需要修正的方向,持續進行改善,直到燃盡圖的結果漸漸趨於正常,就代表大家對專案任務的掌控性越來越高,漸漸邁一個成熟的敏捷團隊。

反之,如果上述的燃盡圖想用來表達專案進展,那麼PM勢必還需要多做一些加工。於是我試著將圖表增添一些視覺效果,並且附上參考資訊,讓它看起來更易閱讀,各位也可以依據自身專案的需求,適度調整圖表,讓你的簡報更有說服力。

BurndownChart_fix.PNG

arrow
arrow
    創作者介紹
    創作者 victor 的頭像
    victor

    電影與生活中的管理學

    victor 發表在 痞客邦 留言(0) 人氣()