程序員軟件項目預估的寶貴經驗
我最近參加了一個關于軟件預估的課程。對于這種本質上就是非精確的科學，我一向都非常謹慎，因為我深信預估可以創造價值。在這個歷時兩個小時的課程中，我發現了如何提醒大家進入預算而不必過度分析和思考的方法。
非常常見的例子
我們經常能聽到項目經理和開發人員之間類似于這樣的對話：
PM：“你能不能給我一個開發某某功能所需要的預估時間？”
程序員：“一個月”
PM：“一個月時間太長了，我們只有一周時間！”
程序員：“最好三周”
PM：“我只能最多給你兩周時間”
程序員：“好吧，成交！”
呵呵！猜猜接下來是什么情況？如果你在下決定之前能快速考慮一下預算與目標之間的差距，那你就不至于這樣草率，也不至于在接下來的時間里焦頭爛額。
結論截然不同的簡圖
在課程中有這么一張圖片，它強調了精確預估的重要性。我粗略地照著原圖重新畫了一張：
圖片表達的中心思想為，我們需要將精確預估作為目標。對此我不置可否。事實上，我想說的是，我們的預估永遠達不到100%的精確。
為什么呢？因為預估本身就是一種并不精確的科學。雖然有很多很多方法（可能甚至比我們需要都要多）可以讓我們擅長估計，但是總會有一些不確定性。沒錯，100％精確自然是最好的，但是在實踐過程中，這是不可能的。
不僅如此，低估時間的成本也是不可承受之重。先看看例子：
- 項目可能會失敗（最壞的情況）。
- 不斷地通宵達旦
- 高壓和焦慮
- 項目可能會延遲
- 質量會受影響
- 成本增加
- 用戶表示不滿
有時候預估時間結果是非常重要的。因為如果你估高了，功能依然可以完成，其代價為耗費的時間多。但是如果你估低了時間，那么可能指定功能你甚至就完成不了。
預估后項目出現異常的原因之一
軟件項目中的混亂源于精確的預估。
你知道是什么原因造成一個軟件項目出現混亂的嗎？原因就是項目進度落后于計劃！我們將這種現象稱之為正反饋效應（不要望文生義，正的反饋并不都是好的）。
還有一個預估方法是給出一個范圍。這么做的效益/成本我們暫時不考慮，下面是使用范圍估計最后卻發現低估的例子：
下面是高估的例子：
曲線下面的陰影部分代表需要付出的努力、成本和計劃進度，看上去明顯比上圖高估所需要的少得多。
當然100%的預估精準度自然是最為理想的，但是在實際操作中，其錯誤成本太高。
你的團隊是否需要常常加班熬夜？下面這句話是我在一篇文章中看到的，印象非常深刻：
大多數軟件開發，項目總是落后于原定計劃。這樣團隊中的人就沒有時間偷懶。
這種思想在我們這個行業非常普遍。我真心是想舉雙手雙腳反對！這種想法顯然是不公平不公正的。
因為很多開發人員在預估時，大多會有20％-30％樂觀余度，換言之就是，開發人員普遍性會低估實際完成項目所需要的時間。這一點我深信不疑。
由此看來，精確的預估精度很有必要。但是結合這些簡圖，更重要的是，寧可高估啊！
譯文鏈接：http://www.codeceo.com/article/programmer-estimating.html
英文原文：A developer's thoughts on estimating software development
翻譯作者：碼農網 – 小峰