總體來說，這個預計誤差的平均水平約為30%。另外還有大量證據表明，從二十世紀八十年代開始就保持著這個誤差水平一直沒有太大的改觀（註：僅有Standish Group 得出的結論是估計精度得到了大大的改善，即估計誤差變小了，但是他們的結論並不具有普片性），評估方法也沒有很好的改進。儘管現在評估模型五花八門，佔主導地位的仍然是專家評估。
評估誤差沒有改觀並不意味著我們對軟體開發的評估水平相對二十世紀八十年代沒有進步，本文將對軟體評估中我們所獲得一些經驗進行綜述。
為了支持我的論點，我選擇了以下了七個研究結果作為論據。
1、永遠沒有最好
目前有大量的研究總是試圖在眾多的評估模型和方法中評選出誤差最小的那一個。但這樣做的問題是，一些諸如項目大小與開發投入之間的核心關係的不確定性將會導致這種研究結果不具備穩定性。此外，影響投入的最大要素也是可變的，因此，評估模型和方法應該根據具體的項目來量身打造。
核心關係的不穩定性也可以說明為什麼誤差水平長時間以來沒有改觀。換句話說，如果有穩定的核心關係就可以使用更加簡單的模型了。當核心要素發生變化時，先進的統計模型就會對歷史數據產生過擬合現象（過擬合是機器學習中常用的一個術語，反映的是在學習訓練過程中，NN對訓練集達到非常高的逼近精度，但對測試集的逼近誤差隨著NN的訓練次數而呈現先下降，後反而上升的異常現象，即過擬合現象會導致更大的估計誤差）。所以，具體的評估方法就根據你的項目來定製吧。
2、評估超支的主要原因：用戶想要最低的成本
項目奪標的競爭壓力迫使開發人員儘量減少預算，如果在沒有價格競爭壓力的環境下就不會出現這種趨勢，反而會朝著相反的方向發展。顯而易見，來自客戶的壓力是導致預算過低的主要原因，因為客戶比較樂意選擇成本更低的開發商。
3、「峰峰值」過小
「峰峰值」指評估方案中的最大值和最小值之間的距離。這種方法是有缺陷的，例如置信區間是90%也不能全部囊括實際情況的不確定性。儘管事實證明我們沒有辦法確定精確的最大最小值，但是目前仍然使用這種辦法，最常見的是基於PERT（三點評估）的方法，投入的期望值很可能就出現在最大最小值之間。
對最大最小值的估計就是專家發揮的地方，優秀的軟體開發者通常有如何評估最大最小值的歷史經驗，並且能根據經驗做出合適的評估。
4、誤導效應（評估很容易被誤導並且難於從誤導中恢復過來）
所有對軟體開發的評估都需要專家的指導，即使使用正式模型評估也不例外。專家的評估很精確，卻也容易造成誤導。最易被誤導的是投入估計的負責人，當他們考慮到預算，客戶要求，日程等因素時，專家的評估指標就成了參考指標。如果不注意到這點，你很可能就會把專家的評估當成了標準，並且在項目進行的過程中不斷地去接近這些指標。
儘管對如何從誤導中恢復過來做了大量的研究，目前仍然沒有找行之有效的方法。所以項目負責人需要對這個這些指標有個清晰地認識，並且自己能量化這些指標。
5、歷史記錄有助於提高精確度
使用歷史數據和清單撰寫的文檔有助於提高估計的精確度。當有可參照的歷史記錄時，一些注意事項就不會被遺忘，以前的經驗能重新利用，還能避開以前走過的彎路。特別是在進行相似的項目時，就可以使用類比來進行估計，歷史文檔的好處就顯而易見。
儘管歷史記錄有著諸多的好處，很遺憾好多公司還沒有把他們當做一個工具用起來。
6、結合獨立估計，提高估計精度
不同渠道評估的均值一般要比單獨個體評估的結果精確。其中有一個重要的假設就是評估是相互獨立的，評估者來自不同的企業，具有不同的背景，使用不同的方法。即這是一個類似Delphi的評估方法（Delphi，一種在專家個人判斷法和專家會議法的基礎上發展起來的專家調查法，它廣泛應用在市場預測、技術預測、方案比選、社會評價等眾多領域），比如Planning Poker（計劃撲克（Planning Poker）的目的是確保開發團隊中的每個人都積極地參與到評估過程並貢獻他或她的知識。該活動在可能有很多未知變量且為了得到精確的估計，需要很多領域的專業知識。撲克會話通常是開發團隊、項目負責人和引導人參與。在計劃撲克（Planning Poker）開始前，引導人將開發團隊聚在一桌並給每個成員分發一副專用牌，這也是撲克這個名字的來由。引導人和負責人沒有牌。）就是基於這種方法的。
一個基於組的結構化的方法因為知識和經驗的共享比機械的合併會產生更好的效果。當然這種方法也存在風險性，比如組內的某種思想會滋生消極因素。
總體看來，評估模型的精度並沒有專家評估的精度高。但是能將這兩種方法結合起來就可以相互取長補短。
7、評估也會帶來弊端
評估不僅僅是預測未來，更多的是約束未來。估計得太低會產生豆腐渣工程，根據帕金森定律，估計得太高又會降低生產力。
這就是為什麼你要考慮到底需不需要進行評估的原因。如果你壓根不需要評估或者後期才需要評估，不進行評估和後期來評估才是妥當的做法。敏捷開發就是避免早期評估潛在危害的一種好辦法，它是根據前期的反饋來制定後期計劃的一種方法。
儘管進行了大量的研究，評估工作仍然面臨著諸多挑戰，但至今仍然沒有十分令人滿意的方案。以下三大挑戰表明，我們自身的知識還遠遠不夠。
1、如何精確評估大型複雜項目
大型的項目對投入有更高的要求，不僅因為大型項目具有更多的因素，還因為它可參照的經驗和歷史記錄比較少。由於大型項目還涉及到業務流程的變化以及和現有軟體利益對接等問題。
2、如何精確評估項目規模和複雜度
長時間以來的研究仍然沒有找到十分有效的方法來評估項目的規模和複雜度。
3、如何衡量和預測生產力
即使你有好方法來計算項目的規模和複雜度，你依然要估計團隊或個人的工作進度和生產力。這是很難的，因為不同的軟體開發者或團隊，工作效率很有可能大不相同。這項指標的估計除了跟進工作進度來評估之外沒有更好的辦法。
目前，我們還不知道項目規模和經濟效益是正相關還是負相關。大多數基於經驗的研究表明：軟體項目的規模關係著經濟效益是正相關的，而軟體從業者卻認為是負相關的。不過這兩種觀點至今仍沒有定論。
我們目前所掌握的軟體開發投入評估的相關知識還不足以應對評估工作中面臨的挑戰，然而，這些知識可以為我們提供指導。特別是如果軟體公司做到了以下幾點，評估的精準度有望提高：
來自投標的壓力會迫使評估者去降低預算，從而可能會導致豆腐渣工程，這中現象在別的領域稱之為「贏家的詛咒」。從長遠來看，客戶應該要意識到他們對固定價格、低價格的執著將對項目產生的消極作用。到那時，軟體公司也應該提高自身的意識，當他們因為價格優勢而中標時，應該考慮考慮如何避開這「贏家的詛咒」。
（英文出處：InfoQ，譯者金色的妖精，各位親，想要贏取積分和禮物，趕快來參與CSDN CODE翻譯任務吧，猛戳 這裡 哦！）