我最近參加了乙個關於軟體預估的課程。對於這種本質上就是非精確的科學，我一向都非常謹慎，因為我深信預估可以創造價值。在這個歷時兩個小時的課程中，我發現了如何提醒大家進入預算而不必過度分析和思考的方法。
我們經常能聽到專案經理和開發人員之間類似於這樣的對話：
pm：「你能不能給我乙個開發某某功能所需要的預估時間？」呵呵！猜猜接下來是什麼情況？如果你在下決定之前能快速考慮一下預算與目標之間的差距，那你就不至於這樣草率，也不至於在接下來的時間裡焦頭爛額。程式設計師：「乙個月」
pm：「乙個月時間太長了，我們只有一周時間！」
程式設計師：「最好三周」
pm：「我只能最多給你兩周時間」
程式設計師：「好吧，成交！」
在課程中有這麼一張，它強調了精確預估的重要性。我粗略地照著原圖重新畫了一張：
表達的中心思想為，我們需要將精確預估作為目標。對此我不置可否。事實上，我想說的是，我們的預估永遠達不到100%的精確。
為什麼呢？因為預估本身就是一種並不精確的科學。雖然有很多很多方法（可能甚至比我們需要都要多）可以讓我們擅長估計，但是總會有一些不確定性。沒錯，100％精確自然是最好的，但是在實踐過程中，這是不可能的。
不僅如此，低估時間的成本也是不可承受之重。先看看例子：
有時候預估時間結果是非常重要的。因為如果你估高了，功能依然可以完成，其代價為耗費的時間多。但是如果你估低了時間，那麼可能指定功能你甚至就完成不了。
軟體專案中的混亂源於精確的預估。
你知道是什麼原因造成乙個軟體專案出現混亂的嗎？原因就是專案進度落後於計畫！我們將這種現象稱之為正反饋效應（不要望文生義，正的反饋並不都是好的）。
還有乙個預估方法是給出乙個範圍。這麼做的效益/成本我們暫時不考慮，下面是使用範圍估計最後卻發現低估的例子：
下面是高估的例子：
曲線下面的陰影部分代表需要付出的努力、成本和計畫進度，看上去明顯比上圖高估所需要的少得多。
當然100%的預估精準度自然是最為理想的，但是在實際操作中，其錯誤成本太高。
你的團隊是否需要常常加班熬夜？下面這句話是我在一篇文章中看到的，印象非常深刻：
大多數軟體開發，專案總是落後於原定計畫。這樣團隊中的人就沒有時間偷懶。這種思想在我們這個行業非常普遍。我真心是想舉雙手雙腳反對！這種想法顯然是不公平不公正的。
因為很多開發人員在預估時，大多會有20％-30％樂觀餘度，換言之就是，開發人員普遍性會低估實際完成專案所需要的時間。這一點我深信不疑。
由此看來，精確的預估精度很有必要。但是結合這些簡圖，更重要的是，寧可高估啊！
英文原文：a developer's thoughts on estimating software development]
程式設計師如何預估自己的專案開發時間？
作者丨愛編碼的coder 專案時間的估算對專案的成敗至關重要。專案時間管理包括了專案按時完成所需的各個過程。但是，在實際專案中，經常出現專案延期，估算嚴重不準確的現象。預估時間本身就很難。每個程式設計師的估計都會跟真正需要的時間有些差距。估計時間短了說明有些事情被忽略了 編譯，測試，提交 估計時間超...
程式設計師如何預估自己的專案開發時間？
專案時間的估算對專案的成敗至關重要。專案時間管理包括了專案按時完成所需的各個過程。但是，在實際專案中，經常出現專案延期，估算嚴重不準確的現象。預估時間本身就很難。每個程式設計師的估計都會跟真正需要的時間有些差距。估計時間短了說明有些事情被忽略了 編譯，測試，提交 估計時間超了說明任務太大，難以理解。...
程式設計師經驗
第乙個 小菜鳥實習期間的不錯感悟 第二個 作為一名非科班出身，已經在行業裡混了近三年的老鳥來說，這個話題真是感觸頗深。本人營銷專業，畢業6年 在社會上混了快3年的時候，轉行去學的c 後來做了一年多的wince，轉做unity3d。在這3年的程式生涯裡，周圍的同事大部分都是科班出身，我唯一感覺他們比我...