來源：申健
最近Uncle Bob發表了新的部落格《為什麼估算這麼難？》。
Bob大叔首先丟擲一個問題，如何將著名的葛底斯堡演說的237個單詞以固定字型和固定行寬寫在一張書籤上。如果人工執行這個任務，假設每秒鐘處理一個單詞來尋找合適的斷句點，估計5分鐘內就可以完成，而且實際花費時間也和估計的差不多。然而，如果要編寫程式來做，要花多久？而且是在知曉演算法、沒有意外情況、沒有絆腳石、無需備份和恢復功能的情況下，編寫程式要花多久時間？
Bob大叔提醒說：程式只不過是遵循某個過程的具體指令，而這個過程是已知的。在動手寫程式之前給出3個估算，最佳情況、最差情況和正常情況。根據Bob大叔的統計，大部分人需要花上30-45分鐘，也有人用了15分鐘，還有人用90分鐘。這樣，很多人之前的估算與實際花費相差懸殊。其中一個原因，他們基於手工任務看似簡單來進行估算的。
Bob大叔回憶某個下午和Kent Beck採用測試驅動開發來結對程式設計寫這個演算法。他們估計這需要10-15分鐘，結果花了30分鐘卻毫無進展。在被迫接受這個體驗後思考，為什麼這演算法這麼難？為什麼把如此簡單和直觀的過程寫下來這麼難？
其實，人類是目標導向的，在分解文字時，人類不會遵循一個過程，而是不斷評估輸出，然後調整做法直到正確為止，因此會預估5分鐘之內完成。而過程是盲目的，它不管輸出是否正確。如果過程錯了，那輸出結果也會錯。人類不瞭解過程，不瞭解過程的難度如何。人類不是電腦，做事的時候不會遵循過程，所以無法比較過程任務和手工任務的複雜性。這就是估算為什麼難，而且經常犯錯的一個原因：任務看上去簡單，人們基於這個表面現象來估算，之後卻發現寫出過程實際上是多麼複雜。人們估算不準是因為估算了錯誤的東西。
回到分解長字串的例子。每次分解一行，記錄下分解位置和選擇這個位置的原因。將其概括為三個不同的場景：
1.如果單詞長於10個字元，在第10字元處斷詞。
2.如果第11個字元是空格，在第11字元處斷詞。
3.從第10個字元向回查詢，如果找到一個空格，就在該處斷詞。
這些場景仍然需要被組成一個過程，但是至少知道這個過程有幾個部分組成，從而使估算更容易。
這個故事的寓意是任務看似容易被人類解決，卻經常被描述為複雜的過程。所以估算時，確保不要被簡單的表面現象所迷惑。深入進去，嘗試列舉出過程所包含的場景數量。
博文顯示估算失真有多容易。人腦不善於回答抽象問題，往往替換實際問題為一個直覺問題。而直覺在尋找答案時，如同博文所說，以期望結果的產生來考慮問題，不關注未知或可能出錯的東西，而是關注那些能夠理解的東西。
博文引發大量討論。有人認為分解過程為小的片段並無價值，有價值的是知道哪類問題是困難的和為什麼困難。也有人認為多練習有助於提高估算準確度，或者讓有經驗的人而不是新手估算。然而經驗最可以依靠，卻仍然可能出錯，除非專案與之前完全一樣。
除了博文所討論的原因，還有人認為，團隊水平、辦公室政治、企業缺乏變更控制，也都成為導致估算不準確的原因。
更多的人吐槽：在實際中，估算往往發生在沒有明確需求可以參考的時候，更不用說之後不斷變化的需求、未知因素、程式碼基礎中隱藏的陷阱。因此固執地遵循最初的時間表也使得估算看起來是不準確的。而且開發人員面對來自於客戶和經理的壓力時，往往傾向於低估時間表。
各位讀者，你們對於估算有什麼樣的經驗？什麼時候估算得準確，什麼時候又不夠準確呢？