一些有趣的觀點出現在我所關注的郵件列表中。下面是其中的一些。原始評論將以藍色字體顯示，下面是我的回應。這不是對相關問題的徹底看法，只是我所想到的一些相關的回應。注：我已加以編輯，以改善流程（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》一書吧。

　　估算是一個很重要的技能，應該在初級開發人員中廣泛教學

　　我提出了一個替換方案：我們需要教給初級開發人員的是完成的意義。如果估計問題已經夠糟糕了，在一些不確定的點找出未完成的某些東西（也許是匆忙地兌現承諾…我的意思是估計判斷！）不僅會打亂時間的估計，還會打亂所進行的工作的日程。這是常有的事，并且會給一個開發團隊的地位造成重大損失。

　　譯文出處：伯樂在線- 職場博客 - 程序員
　　譯文鏈接：http://www.jobbole.com/entry.php/744

　　原文：Ashley Moran　　文章推薦：關關　　翻譯：伯樂在線敏捷翻譯 - 高志翔

　　如需轉載，但請注明原文/譯文出處、譯文超鏈接和譯者等信息，否則視為侵權，謝謝合作！