我自己從2010年8月開始接觸和使用禪道項目管理軟件窟社，由剛開始的只使用測試--Bug管理模塊，到現在的所有模塊均有在使用绪钥。
在不斷的使用過程中灿里，加上長期混跡在禪道QQ技術交流群，對禪道的使用程腹，項目管理也有了深入的理解匣吊。
在QQ群里，同樣的問題經常被問起寸潦，看起來是個小問題色鸳，其實里面卻蘊含了項目管理的一些大道理。
因此见转，我以禪道使用為背景命雀，再加上自己的拙見，整理了“六問禪道項目”系列使用分享斩箫，希望能達到拋磚引玉的效果吏砂。
歡迎吐槽指正撵儿。
今天來說說任務工時更新問題。
不少童鞋都有在問：禪道里記錄任務工時赊抖，輸入日期和工時后统倒，為什么還要輸入剩余，這么簡單的加減系統不會自動計算嗎氛雪？
也就是說很多童鞋對任務工時有誤讀，單純的認為任務預計剩余工時?= 最初預計工時 — 已經消耗工時耸成。
具體解答問題之前报亩，我們先來了解一下禪道里的工時概念：
最初預計：創(chuàng)建任務時的最初預計工時。
已經消耗：開發(fā)這個任務已花費的工時井氢。
預計剩余：完成這個任務還需要的工時弦追。
套用一句老話“計劃沒有變化快”，以我的個人經歷來說比較常見的任務開發(fā)狀況：
1花竞、某個任務最初預計工時是10劲件，coding了5小時后，重新估算還要9小時才能完成约急，系統自動計算剩余工時的話是3小時零远。
2、某個任務最初預計工時是10厌蔽，coding了5小時后牵辣，任務完成了，剩余工時為0奴饮，系統自動計算剩余工時的話還是3小時纬向。
3、某個任務最初預計工時是10戴卜，coding了5小時后逾条，重新估算還要1小時就可完成。系統自動計算剩余工時的話依舊是3小時投剥。
或許你會反駁我师脂，難道就不存在任務很完美的按預期開發(fā)并完成，最初預計與總消耗工時一致的情況嗎薇缅？有危彩，這種理想狀況出現的頻率足以讓我們忽略掉它的存在。
還有個類似的問題：關于任務已消耗工時的自動更新泳桦。有不少童鞋說這個任務我coding了1天汤徽，已消耗工時就應該自動記為8小時呀。
錯灸撰！鬼才知道這一天你都coding了些什么谒府。
讓系統自動更新任務已消耗和剩余工時拼坎，不僅是錯誤的認識，而且還會引發(fā)一些問題：
1完疫、不能反映出任務的真實開發(fā)狀況泰鸡，導致任務剩余工時統計有誤。
2壳鹤、項目進度和燃盡圖不能真實反映當前項目進展盛龄。禪道里項目進度（進度=項目任務總消耗工時/（項目任務總消耗工時+項目任務總剩余工時））和燃盡圖都是通過統計任務的剩余工時來繪制的。
3芳誓、錯誤的數據讓項目經理對項目全局的掌控有偏差余舶，對項目的調整和決策出現失誤。進而會導致出現項目延期锹淌，人員分工不合理匿值，沒有測試就匆忙發(fā)布，交付的產品Bug頻出等一系列問題赂摆。
所以嚴格按照任務開發(fā)實際狀況記錄工時是很有必要的挟憔，而不能簡單的讓系統自動計算掩蓋掉真實的數據。
關于任務工時更新烟号，我比較推薦的做法：
1绊谭、最初預計工時在任務開始后，就不要再做修改褥符。
2龙誊、開發(fā)人員每天及時更新任務狀態(tài)和工時。
3喷楣、更新任務工時趟大，結合實際開發(fā)狀況重新估算剩余工時并記錄。
4铣焊、允許任務的最初預計工時和總消耗工時存在偏差逊朽。任務完成后，二者對比以糾正自己的工時估算曲伊。
總結下來就是：及時更新叽讳，重新估算，真實填寫坟募。
最后岛蚤，簡短粗暴的回答：禪道里任務最初預計工時 ≠ 已經消耗工時 + 預計剩余工時。
