估算的目的

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

通常的場景是這樣的。

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

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

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

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

我并不同意估算是天生有害的活動。如果有人問我，估算是不是件糟糕的事情，我的答案會是一名標準咨詢師的答案：“不一定。”而接下來的問題就會是“取決于什么?！睘榱嘶卮疬@個問題，我們就不得不問，我們?yōu)槭裁匆浪?，因為我想說：“如果事情值得做好，就值得問清楚，我們到底為什么要做它?！?/p>

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

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

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

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

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

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

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

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

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

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