傳統(tǒng)上，項目經理往往會致力于創(chuàng)建很詳細的估算，這個估算從財務的角度要經得起推敲。當然這樣的估算是基于能夠預見的情況再加上針對“已知的未知因素”所設的應急預算…… 然而就像Donald Rumsfeld的名言所說“有一些我們未知的未知因素——有些事情我們根本不知道我們不知道”。就像上面那些商人，我們永遠無法預知那些意想不到的情況。我們花越長的時間來創(chuàng)建詳細的估算，麻煩卻越多。我們可以把詳細的估算看作是一個綁定報價，一個不同于真正交付價值的目標，它使得我們的注意力都放到能在協(xié)議的日期和成本內交付一些東西——任何東西，無論它的價值高低。
在每次實施后的回顧評審中，初始估算和實際之間的差距總是讓我們備受打擊，然后告訴我們自己下次再努力些。愛因斯坦曾經說過，所謂神經錯亂就是“一遍又一遍地做同樣的事情，卻期望得到不同的結果”。因此事情不應該這樣，一定有其它更好的方法。
敏捷項目顯然就不是這樣?我們何不就從一個大概的需求范圍開始，然后在做的過程中逐漸理清細節(jié)?嗯，對，但也不全對。在敏捷項目中我們不會去創(chuàng)建詳細的估算來束縛自己，但是對將要進行的工作量的大小有一個認識還是很重要的，這就是為什么……
1、為什么我們需要估算?
忘掉那些傳統(tǒng)的估算，那些漂亮的精心制作的甘特圖，那些圖表迫使我們的注意力都放在要進行的任務上，而不是要交付的成果。在項目中有三種活動需要我們進行一些粗略的估算。
當我們在考慮一個新提議項目的合理性時，我們需要提前知道大概的成本，這樣才能決定是否值得投入。
當我們正在將新的或改進的產品推向市場時，我們需要知道那些重要的特性大概什么時候可以發(fā)布，這樣我們才能安排相關的活動。
當我們在為工作排優(yōu)先級時，產品負責人需要知道每個故事(或待辦清單項)的成本，而團隊需要知道每個故事的價值。
有件事很有意思，只要整個團隊都一起參與進來共同協(xié)作，估算本身也可以變成一種很有意義的活動。它有助于團隊增進理解，并保證團隊每個人都對要交付的需求范圍和價值達成共識。
然而對“估算”這個詞的傳統(tǒng)理解可能會讓我們偏離這個方向。
2、使用“大小”而不是“估算”
為了避免讓人誤會我們討論的是對成本和時間的估算，當我們評估一個故事的復雜程度時，有些人喜歡用“大小”而不是“估算”來描述。在90年代當我第一次使用Scrum和XP時——那時它們都還沒有被稱為敏捷實踐——我們是使用T-shirt尺寸來評估故事的大小(S，M，L，和XL)。
現(xiàn)在我們使用故事點數(shù)——一種評估故事之間相對大小的方法——因此我們先找到可能最簡單的故事，將它的點數(shù)設為1點，接下來用其他的故事與它進行比較，如果另一個故事比這個更復雜，那個故事可能就是3點。
讓評估變得更有趣的是，我們不采用簡單連續(xù)的數(shù)列，比如1，2，3，4，5等——而是采用一種近似菲波拉契數(shù)列的形式，像1，2，3，5，8，13等(就如《達芬奇密碼》里面看到的)。這樣當數(shù)字越大相鄰數(shù)之間的間隔也越大，使得我們更容易區(qū)分哪個故事更小哪個更大。
盡管這不是一種精確的科學，但對上面提到的三種需要估算的情況這種方法已經足夠好了。像John Maynard Keynes所說，“粗略的正確好過精確的錯誤”。這也意味著，我們仍然需要將故事點數(shù)轉換成粗略的時間和成本估算。
另一個主要用于敏捷項目的實踐是建立“完成標準”，就是對一個故事要能夠標注為完成并可發(fā)布所需要滿足的所有條件進行全面的理解，包括各種