不少時候,咱們感受什麼都沒幹一天就過去了,但對領導者來講,事情最好已經提早作完了,並且是越快越好。聰明的管理者知道,「時間」是須要花大功夫去把控的限制因素,只有掌握了更多關於時間和工做的數據,咱們才能更好地執行計劃,在預算範圍內按時完成項目。ide
燃盡圖就是用來反映此類項目數據的工具,經常使用於敏捷軟件開發中,如Scrum。它能夠呈現剩餘工做量和可用剩餘時間,並經過可視化的圖示表述繁複文字沒法表述的意思。工具
燃盡圖能夠呈現團隊處理用戶故事進度,是一種對工做完成狀況可視化展現的工具,燃盡圖可顯示每次迭代工做總量中仍需完成的工做餘量。3d
燃盡圖的橫軸顯示工做天數,縱軸顯示剩餘工做,反映了項目啓動以來的進度狀況,它讓每一個團隊成員都可以看到當前的進度,團隊需按期更新燃盡圖以保持其準確性。blog
目前存在兩種形式的燃盡圖,Sprint燃盡圖用於顯示迭代中的剩餘工做量,而產品燃盡圖則用於說明整個項目的剩餘工做量。ci
燃盡圖有下面幾個要點,它有一個X軸,表明項目或迭代的時間;有一個Y軸,表明須要在項目中完成的工做,用戶故事剩餘的工做量也由該軸表示。項目管理
項目起點位於圖表左側最高點,發生在項目或迭代的第0天。項目完結點位於最右側,標誌着項目或迭代的最後一天。開發
燃盡圖中的計劃曲線是一條鏈接起點和終點的直線。由於表明了須要完成的全部預估任務的總和,計劃曲線的終點應穿過X軸,表示已經不存在任何剩餘的工做。但鑑於它以估算值爲基礎,所以並不老是準確的。get
燃盡圖中還存在一條實際曲線,顯示項目或迭代中實際剩餘的工做量。在起點,計劃剩餘工做量和實際剩餘工做量是相同的,但隨着項目或迭代的進行,實際剩餘工做曲線將在計劃工做線的上下方波動。實際的剩餘工做線天天都會添加一個新的點,直至項目或迭代完成,以確保儘量準確。博客
若是實際工做線高於計劃曲線,則意味着剩下的工做量比預期多,換句話說,意味着項目進度落後於計劃。但若是實際曲線低於計劃曲線,則意味着剩餘工做量少於預計,項目進度快於既定計劃。團隊協作
燃盡圖最顯著的好處是,能提供關於項目進度和更新狀態的最新報告,並對這些重要數據進行直觀展現,能夠確保每一個人都統一進度。
此外,將燃盡圖展現到全部人面前,可以讓團隊全部成員都積極參與項目,並激勵成員提早處理可能出現的問題。所以圖表越大越顯眼就越好。燃盡圖應該成爲辦公室的視覺焦點,進而引起對項目和進度的相關討論。
簡潔明瞭的燃盡圖十分有用,由於它是查看項目歷史速度(Velocity)的最佳工具。速度(Velocity)是一個敏捷術語,表示迭代期間完成的用戶故事相關的預估工做量總和。
例如,它僅顯示已經完成的用戶故事工做量,沒法預知任何變化,例如在工做範圍內估算待辦列表(backlog)的全部points。所以,咱們很難判斷燃盡圖中的變化是因爲已經完成的backlog,仍是因爲故事點的增長或減小引發的。在燃盡圖中增長一個專門顯示backlog總量的圖表能夠解決這個問題。
可是,燃盡圖(向下或向上線條顯示)都沒法顯示哪些產品backlog已經完成。燃盡圖能顯示項目的進度,但沒法顯示團隊是否在作正確的事,也沒法判斷團隊是否在交付正確產品backlog。
燃盡圖的另一個問題是理想剩餘工做線。實際工做線是高於仍是低於理想工做線須要取決於對任務原始時間估計的準確性。所以,若是團隊太高估計時間要求,則項目實際進度可能會看似正常或略超前。但若是低估了時間要求,則看起來會落後於計劃。
將效率因素歸入燃盡圖能夠解決這個問題。所以,在項目的第一次迭代以後,從新計算效率因素可以得到更高的準確性。
燃燒圖表是從Scrum社區開發出來的,而且在2000年左右首次用於管理軟件項目和其餘相關工做。Ken Schwaber首次對燃盡圖進行了描述,所以也被認爲是燃盡圖的發明者。當時正在Fidelity Investments工做的Ken Schwaber建立了燃盡圖,來爲Scrum團隊提供一個能夠幫助他們繪製項目進度圖的簡單工具。
到2002年,燃盡圖在Scrum社區中愈來愈受歡迎。從那之後,燃盡圖開始運用於scrum以外的其餘領域,成爲了管理者控制項目進度的有用工具。
Worktile提供專業的敏捷項目管理模板工具,包括需求管理、迭代規劃、缺陷追蹤、報表統計、團隊協做等功能,能實時查看和監控項目進度,提升團隊成員工做效率。10人如下團隊可無償使用,免費註冊Worktile。
文章來源:Worktile敏捷博客
歡迎訪問交流更多關於技術及協做的問題。
文章轉載請註明出處。