導讀：原文作者ley Moran發表的一篇博客《Why Can't Developers Estimate Time?》。譯文由伯樂在線整理編譯成《爲什麼開發人員不能估算時間？》，Ashley Moran是一名軟件開發人員，最近在其關注的郵件列表中看到了一些有趣的觀點，所以他做出了相應迴應。
編者按：Ashley Moran 是一名軟件開發人員，最近在其關注的郵件列表中看到了一些有趣的觀點，所以他做出了相應迴應。（以下是全文）
一些有趣的觀點出現在我所關注的郵件列表中。下面是其中的一些。原始評論將以藍色字體顯示，下面是我的迴應。這不是對相關問題的徹底看法，只是我所想到的一些相關的迴應。注：我已加以編輯，以改善流程（flow），並加以闡述。
在軟件開發中，我們不能對任何單獨的任務作出時間的估算，是由於工作性質是創造新知識。
軟件開發的目標是實現流程（Process）自動化。只要一個流程實現了自動化，便可以針對大多數情況在可預期的時間內反覆運行。源代碼就好像生產藍圖，而電腦就好像生產工廠，輸入（數據）好像原材料，輸入（數據）就像製成品。而使用另一種類比，星巴克可以重複迅速地製作咖啡的原因就在於他們花費很多時間在流程的設計上，使得該流程成爲了一個複雜且昂貴的作業。星巴克的個人經營者不必再去重新研究該流程，只需買下此藍圖便可。我會讓各位讀者練習推斷我對COSTA咖啡製作過程的意見。
事實上，不可預期的開發時間並不總是壞事，因爲它所帶來的價值也是如此。一款成功的軟件可以製造或節省的價值遠超過其成本。Tom DeMarco之所以贊成關注高成本項目，正是基於這個原因。能注意到這點，需要一種價值增長的理念，而不是廣泛而又普遍的成本控制理念。這是很重要的問題。
目前爲止，Don Reinertsen的《Principles of Product Development Flow / 產品開發流程原理》，是我所看過的對可變性與爲價值而開發的最好解釋，該原理在日常流程管理中大量使用PatchSpace Bible。我所說的“目前爲止最好的”是指超越我所看過的其他解釋一個檔次，不包括約束理論（Theory of Constraints）的著作。
這就是我的最近開發項目的數據。直方圖中的R表示5個小時的量：橫軸表示的是User Case 的持續時間——0-5小時，5-10小時，等等；縱軸表示的是佔此時續時間的User Case數量。我以90分鐘爲間隔，工作並將其記錄在Wave上，這樣我們就能清楚地知道任務持續時間。
我們這麼做既爲了與客戶溝通，又爲了賬單。結果是：我們的開發時間的可預知程度跟放射性衰變一樣，但卻是始終如一的輻射。可估計的相關數據少得可憐，我拒絕估計個別任務的的時間，因爲這會產生誤導，但是我們有足夠數據進行合計。
經驗法則：接受開發人員的估算意見，但是要在兩倍的基礎上再加一點時間
兩倍加一點法則很有趣。經理開始運用此法則時，多長時間他會提前完成一次？我們通常太過注重超支。如果一個團隊未能提前完成任務的一半。他就要增加估計時間，這意味着拿開發週期與項目進度做交易。週期往往比可預測性更重要，因爲它意味着更早地進入市場。同樣看看Reinertsen的作品，數字會以與數量級不同的規律出現。
並且，這是關鍵鏈（Critical Chain）項目管理的基礎，這會將項目估計時間二等分，把剩餘時間（添補單獨項目）放在最後，作爲“項目緩衝時間”。這就意味着帕金森定律不會導致單獨任務無規律地擴張。儘管我不覺得關鍵鏈是軟件行業的一個合適的方法，但作爲開發工作的內容，它可作爲反饋與學習提高的工具，可明顯改善計劃。
通常人們只是估計時間
不僅開發人員估計不好。每個人都會遇到臨場發揮（即興應付）的問題，因爲那是他們沒從未做過的事，所以在完成之前，他們無法準確地作出判斷。
作爲一個羣體，我們應避免這一點。不知道就是不知道，一定要說出來。相比於無法估計，那些能夠定期瞭解任務進度，從而意識到風險（並選擇繼續投資）的客戶，會給予團隊更多的信任。這是事實！我是認真的，不用只相信我的話，看看David Anderson的《Kanban》一書吧。
估算是一個很重要的技能，應該在初級開發人員中廣泛教學
我提出了一個替換方案：我們需要教給初級開發人員的是完成的意義。如果估計問題已經夠糟糕了，在一些不確定的點找出未完成的某些東西（也許是匆忙地兌現承諾…我的意思是估計判斷！）不僅會打亂時間的估計，還會打亂所進行的工作的日程。這是常有的事，並且會給一個開發團隊的地位造成重大損失。