我自己從2010年8月開始接觸和使用禪道項目管理軟件利职,由剛開始的只使用測試--Bug管理模塊胚膊,到現(xiàn)在的所有模塊均有在使用剪廉。
在不斷的使用過程中,加上長期混跡在禪道QQ技術交流群适揉,對禪道的使用,項目管理也有了深入的理解临梗。
在QQ群里涡扼,同樣的問題經常被問起,看起來是個小問題盟庞,其實里面卻蘊含了項目管理的一些大道理吃沪。
因此,我以禪道使用為背景什猖,再加上自己的拙見票彪,整理了“六問禪道項目”系列使用分享,希望能達到拋磚引玉的效果不狮。
歡迎吐槽指正降铸。
今天來說說燃盡圖更新的問題。
不少童鞋有在群里提問:為什么我的燃盡圖沒數(shù)據(jù)摇零,不更新呢推掸?
慣例,在回答問題前驻仅,先來看看燃盡圖的概念:
燃盡圖(Burndown Chart)是以圖表展示隨著時間的減少谅畅,工作量的剩余情況。
工作量一般以豎軸展示噪服,時間一般以橫軸展示毡泻。
燃盡圖可以非常直觀的把握項目的進度,經常被用于敏捷軟件開發(fā)中粘优,如Scrum仇味。而禪道的設計是完整支持敏捷方法scrum的。
禪道里的燃盡圖是統(tǒng)計項目中所有任務剩余工時的總和雹顺,每天計算一下丹墨,形成坐標,然后把線連接起來繪制而成嬉愧。
下面來回答開篇的問題:
1带到、燃盡圖是需要更新的,沒更新當然就沒數(shù)據(jù)。
2揽惹、如果你設置了燃盡圖的定時更新被饿,后臺--計劃任務,檢查一下定時任務是否是停止狀態(tài)搪搏,可以重啟計劃任務狭握。
3、燃盡圖的更新有以下方法:
1)根據(jù)禪道提供的更新腳本來更新疯溺。
首先參考《 初始化管理腳本》這篇文章來初始化各個腳本论颅。
然后到zentao/bin/目錄下,windows系統(tǒng)執(zhí)行computburn.bat腳本囱嫩,linux系統(tǒng)執(zhí)行computburn.sh腳本來更新燃盡圖恃疯。
2)手工更新。
首先在組織視圖中墨闲,通過權限管理給相應的用戶分配更新燃盡圖的權限今妄。
有權限即可在項目--任務--燃盡圖頁面,點擊燃盡圖“更新”按鈕鸳碧,即可計算數(shù)據(jù)繪制燃盡圖盾鳞。
3)定時更新。
windows下面可以使用計劃任務瞻离,需要在禪道界面后臺先開啟計劃任務腾仅。linux下面則可以使用crontab來設置。
注意:
1套利、大家及時更新任務工時推励。
2、燃盡圖最好在每天的同一時間更新肉迫。
3验辞、定時更新燃盡圖,建議下班后昂拂,比如晚上11點執(zhí)行定時任務受神。
在這里抛猖,給大家分享一下Dusan Kocurek對各種燃盡圖的分類和解析格侯。
分析得比較有意思,歡迎對號入座财著。
英文原文地址: http://www.methodsandtools.com/archive/scrumburndown.php
中文翻譯地址:http://blog.cnezsoft.com/blog/80103.html
1. 理想團隊工作的燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_dcf16028925757511c14d0239321f6e4.jpg)
這種燃盡圖說明該團隊可以組織好工作联四。
產品經理明白迭代的工作量,Scrum master 能夠幫助團隊完成任務撑教。
團隊沒有超負荷朝墩,并按時完成迭代工作。
該團隊可以正確估算自己的能力伟姐,迭代過程中也不需要改正收苏。
2. 很好的團隊的工作的燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_aa24f2eaf031a53b2409a355ba8b161c.jpg)
這種燃盡圖一般是具有豐富經驗的團隊的工作進度展示亿卤。
團隊按時完成工作,并且達到了迭代目標鹿霸。
這種團隊可以完成工作排吴,更重要的是可以適應迭代積壓工作的情況。
迭代后期懦鼠,團隊也有能力完成一些額外的工作钻哩。
3. 不錯的團隊的工作的燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_94f8f6585d31f74681d8d5b35ac57fa7.jpg)
這是典型的工作進度燃盡圖,在很多有經驗的敏捷團隊的工作中都可以看到肛冶。
該燃盡圖說明團隊可以按時完成任務街氢,調整以適應迭代中的積壓任務,額外努力工作以完成任務睦袖。
該團隊需要自我反省珊肃,在迭代初期看到進度減慢就應該立即討論如何變動計劃。
4. “太遲啦”團隊工作燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_0fd027e61b8741d22ff993c481e3512a.jpg)
這種燃盡圖明顯在說扣泊,“你們沒有完成工作近范。”
這種團隊整個迭代過程都在遲到延蟹,沒能合理調整工作评矩。
燃盡圖還顯示出團隊沒有完成需求,這些需求應該被進一步分解阱飘,或者挪到下一個迭代中斥杜。
5. “太快啦”團隊工作燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_64aa5c75cd986aca5c5469e278716e3e.jpg)
燃盡圖顯示團隊比預期早很多完成任務。
團隊完成了需求沥匈,也沒有繼續(xù)完成其他任務及時團隊有時間和精力這么做蔗喂。
這種情形下,需求可能被高估了高帖,所以團隊提前完成了任務缰儿。
團隊的工作速度沒有被合理的估算。
6. “休息一下吧”團隊工作燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_f47814b1eb8ffa06296359bf36c186b7.jpg)
團隊的工作進度如果如該燃盡圖所示散址,那么問題就來了乖阵。
問題在于對工作復雜度的高估,這使得工作的完成比迭代初期預估的要早预麸。
Scrum master應該及早找出問題所在沒要求產品經理給團隊跟過的工作瞪浸。
即使需求被高估,團隊至少應該繼續(xù)做下一個迭代的任務吏祸。
7.“管理層要來了”團隊工作燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_feeba103266caf6cece22a9858375a59.jpg)
這種團隊可能沒有更新自己的工作進度对蒲。
這里一種情況可能是產品經理增加了一些已經完成的工作,所以燃盡圖時機工作曲線是直線。
8.? “上天”團隊工作燃盡圖
![](http://blog.cnezsoft.com/data/upload/201702/f_b0e8ee33adc3ed1b9b67a4fc7c7ea6a8.jpg)
團隊第一個迭代一般來說都是這種燃盡圖蹈矮。
這種情況是成功之母砰逻,很明顯團隊沒有完成任務。
每天都有需求或任務添加到跌倒工作中來卻沒有記錄任何工作季度泛鸟。
![](http://blog.cnezsoft.com/1PU4o2Hu43jHBL.gif)
另一個原因可能是迭代中的任務不斷地被重新估算诱渤。