敏捷開發創始人Martin Fowler：估算的目的

　　我第一次與敏捷軟件開發的邂逅，是在極限編程剛剛興起時，跟 Kent Beck 一起工作的經歷。其中讓我印象深刻的事情之一，就是我們如何做計劃的方式。這里面包括一種估算方式，比起我之前見到過的其他方法，它既輕量，還更有效。這 樣過了十年，現在一些有經驗的敏捷實踐者，開始了一場關于估算是否值得甚至是否有害的爭論。我想，為了回答這個問題，我們必須審視一下估算的目的。

　　通常的場景是這樣的：

• 開發者被要求給出對于即將開始工作的估算。人們大多是樂觀派，即使沒有壓力的情況下（一般至少也會有點壓力），這些估算通常會比較小。
• 這些任務和估算會被轉化成發布計劃，然后用燃盡圖跟蹤。
• 接著，人們就會按照這些計劃，持續監控著團隊為完成任務所投入的時間和資源。結果當實際消耗的時間和資源，超過當初的估算時，每個人都會變得失望。為了迎合當初的估算， 開發者被要求犧牲軟件的質量，但這只會讓事情變得更糟。

　　這種情形下，對估算的投入充其量就是一種浪費——因為“估算就是在干凈的襯衫上猜測”。只有當估算被當做追逐更多特性的手段時，它才會變成實質上有害的行為。過分追逐特性是一種很糟糕的情形，人們只是始熱衷于完成一個又一個特性，而不是追蹤項目的真實結果。

　　估算還會設定期望值，既然估算通常會偏低，所以它們設定的期望值也多是不切實際的。任何時間上的增長，或者軟件特性被砍掉，都會被視作是失敗。出于對風險的逃避，這些失敗的后果往往會被放大。

　　面對類似這樣的情況，我們就很容易看到人們把憤怒對準了估算本身。這樣也導致越來越多的人認為，任何沉迷于估算的人并不是真正的敏捷實踐者。而 批評敏捷的人則說，這意味著敏捷軟件開發的本質就是，開發者很快動手開始做，卻并不明確要做什么，而且承諾說，該做完的時候肯定會做完它，而且你肯定會喜 歡它。

　　我并不同意估算是天生有害的活動。如果有人問我，估算是不是件糟糕的事情，我的答案會是一名標準咨詢師的答案：“不一定”。而接下來的問題就會 是“取決于什么”。為了回答這個問題，我們就不得不問，我們為什么要估算——因為我想說：“如果事情值得做好，就值得問清楚，我們到底為什么要做它”。

　　對于我來說，當你面臨重大的決策時，估算就是有價值的。

　　我的第一個得益于估算決策的例子是：資源的分配。一般來說，組織大多擁有固定數目的錢和人，而且通常有太多值得做的事情。因此人們就面臨選擇： 我們是做A還是B？面對這樣的問題，了解A和B分別要涉及多少投入（以及成本）是有必要的。為了做出一個明智的決策，你需要有對成本和收益有個大致的了 解。

　　另外一個例子是估算對協調的幫助。藍色團隊想在他們的網站上發布一個新的特性，但直到綠色團隊創建新的服務提供給他們關鍵數據后才能發布。如果 綠色團隊估算他們會在兩個月后才能完成新的服務，而藍色團隊估算需要一個月去能完成新的特性，那么藍色團隊就知道不值得現在就開始實現這個新特性。他們可 以花費至少一個月時間，工作在其他可以早點發布的特性上。

　　所以任何時候當你想做估算時，你應當非常清楚哪一項決策需要依賴這個估算。如果你找不到這樣一項決策，或者那個決策并不是那么重要，這就是一個 信號：此時做估算是在浪費時間。當你找到這樣一個決策時，那要知道問題的上下文是什么，為什么估算會很重要。同樣還要搞清楚期望的精度和準確性。

　　同時也要明白，有時候為了做決策，可能會是其他替代的方案，而未必需要估算。也許任務A比起B要重要得多，以至于你都不需要一開始把你所有的空閑精力都放在B上。也許有辦法讓藍色團隊和綠色團隊合作，更快地創建出服務來。

　　類似地，跟蹤計劃也應該由它如何影響決策來驅動。通常我的意見是，計劃扮演的是基線角色，幫助評估變化——如果我們想要添加一個新的特性，我們 應該如何把它放進既定的“五磅籃”里呢？估算可以幫我們理解這些取舍，并因此決定如何響應變化。在更大范圍下，重新評估整個發布計劃，可以幫助我們理解整 個項目是否仍然充分有效利用了我們的能力。幾年前，我們曾經有一個規模達一年之久的項目，在重估時發現還要多花幾個月進去，之后我們取消了這個項目。我們 把這視作成功，因為重新估算發現，項目會比我們最初期望的會花費更長時間——早點取消可以讓客戶把資源轉移到更好的目標上。

　　但跟蹤計劃的同時，也要記住估算是有適用期限的。我曾經記得有一位經歷頗豐的項目經理說過，計劃和估算就像是生菜，剛過幾天還很新鮮，過了一周有點枯萎了，幾個月后就完全看不出來是什么了。

　　許多團隊發現，估算提供了一種有用的機制，可以促使團隊成員間彼此交流。估算會議可以幫助大家以不同的方式，對實現即將開始的故事、未來的架構 方向和代碼庫中的設計問題，有更好的理解。在這種情況下，任何輸出的估算數字可能都不重要。這樣的對話可能以很多方式發生，但如果這些對話沒有發生，就可 以引入關于估算的討論。相反地，如果你考慮停止估算，你需要確保估算時會發生的任何有效的對話，在其他地方還能夠繼續進行。

　　在任何敏捷相關的會議上，你都會聽到很多團隊在談論，沒有估算他們也可以工作得很有效。通常這是因為，他們以及他們的客戶明白做估算并不會影響 重大的決定。舉個例子，一支小團隊在和業務人員緊密協作。如果廣闊的商業前景很樂意分配一些人到那個業務單元，那么就可以按照優先級開展工作；通常這得益 于團隊把工作拆分成足夠小的單元。團隊在敏捷流暢度模型中的等級，在這里起到非常重要的作用。在團隊前進時，他們首先會糾纏于估算本身，然后開始會做很好 的估算，最后達到不再需要估算的境界。

　　估算本身并無好壞之分。如果你不用估算就可以有效地工作，那就這么干。如果你需要一些估算，那就要確認你很清楚估算在決策時起到的作用。如果估 算會影響到重大的決定，那就盡可能做出最好的估算。一定要小心那幫告訴你任何時候都要做估算，或者從來不需要估算的人。任何關于估算用法的爭論，都要遵從 于敏捷的原則，即針對你特定的上下文，決定你該采用的什么樣的方法。

                    <span id="shareA4" class="fl">                          </span></div>