摘要：
說起估算問題，我們第一反應往往是「估不准」！估得準又怎樣呢？假設估算結果是須要5個月才幹完畢，但合同要求3個月交貨，你怎樣辦？所以事實上我們另乙個「估得多」的問題，而在「估不准」和「估得多」這兩個問題之前，還有「不敢估」的問題。
估算問題非常複雜，我們首先要做的是拆解這個問題，這樣才幹更好地找到合適的解決方法。
我們從不同角色的視角來看看估算的問題：
老闆怎樣看估算？
老闆是非常了解自己的手下的：假設讓專案組自己去估算，那麼估算值一定是大於工期限制，並且實際的工作量又會遠大於估算值。
但老闆是要賺錢的，專案的合同金額是固定的，交付期是「死」的，所以專案組不要跟我扯專案有多困難，不要說須要更長時間，反正必須在交付期之前將專案做出來，並且專案能驗收！這樣才幹符合我的利益。
所以老闆不太可能讓專案組自己估算工期，然後讓專案組依照這個工期來安排工作。
專案經理怎樣看估算？
專案經理（後面簡稱pm）是責任大，權力小的職位，專案的「幾座大山」都壓在了pm身上。
這「幾座大山」是什麼呢？
1）進度的壓力
2）老闆的壓力
3）客戶的壓力
4）軟體質量的壓力
5）恨鐵不成鋼的專案組成員
6）……
本來估算應該是舒緩這些壓力的好辦法，假設能依據估算來安排進度和調整專案組的人力安排，估算就是美好的。
但問題是估算出來須要5個月完畢，但工期僅僅有3個月，老闆和客戶都不會由於這個估算而放鬆對進度的要求和限制，也不會減少軟體的質量要求，老闆也不會安排很多其它的人手到你的專案組（專案期間老闆假設不將人員抽走的話，你已經要阿彌陀佛了）。
所以估算對於pm來說一點價值都木有，橫豎都是死，不如節省這些沒用的估算時間，讓我死得舒服一點吧。
專案成員怎樣看估算？
我是來打工的不是來賣命的，完畢本職工作對得起這份工資即可。專案成敗跟我沒啥特別關係，pm把任務安排下來，我完畢任務就能夠了。至於加班嘛，這是it界的「潛規則」，我就加一點吧，但沒日沒夜的加班老子是受不了的！
你說「估算」？讓我預計自己任務須要多長時間完畢？說了這個時間實用嗎？我說10天你還不是直接砍成3天，不要做這種「虛偽」的事情了，直接告訴我什麼時候要完畢即可了。
客戶怎樣看估算？
不要老說我們提不出需求，你不做出來我怎樣知道我要什麼呢？軟體開發我不懂，不要每次催促你們交貨就跟我提一些我聽不懂的理由，我們懂技術的話就沒有你們公司的事了！我們推斷事情的標準事實上非常簡單，簽署合同一時候我們已經寫得非常清楚了，就是：給你們這麼多錢，這種工期，到時必須交出像樣的東西出來！
估算？你說什麼估算？你們簽合同的時候不是應該想好了嗎？如今才跟我說超出工期，那合同要來幹嘛呢？
看上去不管是從哪個角度來看，估算」都是「十死無生」的事情，並且估算似乎沒有辦法兼顧各方面的利益。那麼是不是不談估算，直接繞開估算這個事情，就「萬事大吉」呢？
理想的估算境地
理想情況是這種：專案組的估算符合合同的要求，能在工期內交付，能保證質量要求，並且專案的實際情況與估算情況基本吻合，並且專案組不須要太多加班，甚至是不須要加班。這樣就能滿足和平衡老闆、pm、專案組成員以及客戶的利益了。
避開估算事實上象鴕鳥遇到事情將頭埋在沙中，避得一時避不了一世。我們須要直接面對估算帶給我們的挑戰，僅僅要能克服下面的三個問題，就能夠實現上述的「理想境地 」。這三個問題是：1）不敢估；2）估不准；3）估得多。
問題1：不敢估
不敢估算或者不願意估算，主要有三個原因：
1）專案工期是限死，專案人力資源基本也是死的，讓估算者認為估算沒有價值；
2）專案的需求不確定，採用什麼技術也不太確定，讓估算者認為無法進行估算；
2）估算事實上相當於是對自己工作的承諾，估算者不想自己對自己設套。
問題2：估不准
不敢估算這個問題克服後，估不准的問題就會呈現出來，估算誤差超過100%甚至是200%以上都是非經常見的事情。不必太過緊張，假設能克服「不敢估」這一關，「估不准」這個問題是能夠解決的。
「估不准」的原因通常有：
1）對專案的需求和技術預計不准，特別是專案需求不確定的時候；
2）對專案組自身的預計不准，包含對自身的技術能力、團隊協作能力、研發流程能力的預計等。
問題3：估得多
估算出來了，並且實際情況也估算情況相差無幾，也不一定能滿足要求，由於這個估算往往是大於工期的限制的。這第三個問題，才是我們終極須要解決的問題！
估算方法最多僅僅能幫助我們估得比較準，但並不能幫助我們估算得少，真正能讓估算數字下降的決定性因素是什麼呢？這個決定性東西事實上就是你們的研發能力！
怎樣解決這些問題？
談起估算問題，我們表面上談的是「估得準」的問題，而實際上我們希望的是「估得準並且估得少」，要終極達到這個目標，必須按順序逐步來解決前文提到的三個問題。
公司的領導們不要太過心急，這三個問題沒有幾年時間是不能徹底解決的，給你乙個時間表參考參考：
1）徹底解決這個問題1大概須要3個月時間；
2）在解決這個問題1基礎上，徹底解決這個問題2大概還須要6個月-1年時間；
3）在徹底解決這個問題1、2的基礎上，徹底解決這個問題3大概還須要2年以上時間。
這是乙個系列文章，將會環繞這三個問題給出一些最佳實踐供你參考，你也不用太操心須要這麼長時間 才有效果，興許文章會為你分享立即能夠實踐的做法，改進是持續進行的。
下面是本系列文章的大致規劃：
1.不僅僅是估不准的問題 <---------這是本篇文章
2.估算能夠非常難也能夠非常easy
3.估算和預算
4.估什麼？誰來估？
5.怎樣估算？
6.專案初期的估算
7.專案中後期的估算
8.怎樣才幹讓估算數值更少？
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
cmmi首席專家
《火球——uml大戰需求分析》作者
www.umlonline.org創辦人
我們為什麼「敏捷」不起來
從接觸scrum到現在已經快一年了。在這一年裡，組內一直使用scrum的流程進行開發管理，雖說有些山寨，但看上去還是像那麼回事的 blog分解 計畫分解 立會 發布 回顧，該有的都有了，自己對於敏捷也從開始的新鮮到了現在的。怎麼說呢，不那麼新鮮了。這次的產品是乙個公升級版，功能比較單一，但由於原來的...
敏捷開發實踐 1 故事工作量估算導致的問題
背景 自從我們使用scrum進行專案開發後，出現了這樣那樣的問題，有些是因為我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的經驗。我說的不一定正確，只是描述問題，然後說...
為什麼我不推薦敏捷開發？
當專案成員越多，我越不推薦敏捷開發，原因在於 當連自己要做什麼事 為什麼這樣做 這樣做為了解決什麼問題 都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了 敏捷開發 mba智庫百科 最下方有段 對敏捷開發的誤解 可順便參考 敏捷軟...