估計目的

2013 年 2 月 27 日

我第一次接觸敏捷軟體開發是在與 Kent Beck 合作 極限編程的黎明時期。那項專案讓我印象深刻的事情之一就是我們規劃的方式。這包括一種估計方法,既輕量化又比我之前見過的更有效。現在已過十年,現在有經驗的敏捷主義者之間爭論估計是否值得進行,甚至是否真的有害 [1]。我認為要回答這個問題,我們必須了解估計將用於什麼目的。

常見的場景如下

  • 要求開發人員針對即將到來的任務提供(或給予)估計。
  • 人們是樂觀的,因此這些估計往往過低,即使沒有壓力要求他們降低(而且通常至少有一些隱含的壓力)

  • 這些任務和估計會轉換為透過燃燒圖追蹤的版本計畫
  • 花費時間和精力來監控進度是否符合這些計畫。當實際結果高於估計時,每個人都會感到沮喪。為了提高與估計的進度,開發人員被告知要犧牲品質,這只會讓事情變得更糟

在此敘述中,投入預估的努力充其量只是浪費,因為「預估就是穿著乾淨襯衫的猜測」[2]。預估通常會造成積極的傷害,因為它們會鼓勵功能崇拜,這是一種令人討厭的狀況,人們開始重視勾選功能,勝過追蹤專案的實際結果。[3]

預估也會設定預期,而且由於預估通常過低,它們會設定不切實際的預期。[4]任何時間增加或功能減少,都會被視為損失。由於損失規避,這些損失會產生放大的效果。[5]

面對這種情況,很容易理解人們如何將憤怒的目光轉向預估。這導致一個觀念越來越盛行,認為任何沉迷於預估的人都不是真正的敏捷主義者。敏捷開發的批評者表示,這表示敏捷開發是關於開發人員離開並執行模糊的事物,承諾在完成時完成,而且你會喜歡它。

我不同意這種觀點,認為預估是一種本質上邪惡的活動。如果有人問我預估是否是一件壞事,我的回答是顧問的標準答案「這要看情況」。每當有人回答「這要看情況」,後續問題就是「看什麼」。要回答這個問題,我們必須詢問我們為什麼要進行預估,就像我喜歡說的:「如果值得做好,就值得詢問你為什麼要這麼做」。

對我來說,當預估有助於你做出重大決策時,它是有價值的

我第一個預估知情的決策範例是資源配置。組織擁有固定數量的金錢和人員,而且通常有太多值得做的事情。因此,人們面臨決策:我們要做 A 還是 B?面對這樣的決策,了解每項決策需要多少努力(和成本)是有用的。要對要做的事情做出明智的決策,你需要了解成本和收益。

另一個範例是有助於協調。藍色團隊想要在其網站上發布新功能,但在綠色團隊建置一項新服務以提供關鍵資料之前,無法這麼做。如果綠色團隊預估他們將在兩個月內完成,而藍色團隊預估他們需要一個月來建置該功能,那麼藍色團隊知道今天開始並不值得。他們可以花至少一個月時間處理其他可以提早發布的功能。

因此,每當您考慮要求估計時,您應始終釐清該估計所提供資訊的決策為何。如果您找不到一個,或決策並不重要,那麼這表示估計是浪費的。當您找到一個決策時,了解它會聚焦估計,因為決策提供背景。它也應釐清所需的精確度和準確度。

了解決策也可能引導您採取可能不涉及估計的替代行動。也許任務 A 比 B 重要得多,以至於您不需要估計就能將所有可用精力投入其中。也許藍色團隊成員可以與綠色團隊合作,以更快速地建置服務。

類似地,追蹤計畫也應由它如何提供決策資訊來驅動。我通常在此的評論是,計畫作為基準,以協助評估變更 - 如果我們想要新增新功能,我們如何將其納入 FivePoundBag?估計可以幫助我們了解這些權衡,並因此決定如何回應變更。在更大規模上,重新估計整個版本可以幫助我們了解專案整體是否仍是我們精力的最佳用途。幾年前,我們有一個為期一年的專案,在重新估計幾個月後取消。我們將其視為成功,因為重新估計表明專案所需時間比我們最初預期的要長很多 - 提早取消讓客戶能夠將資源轉移到更好的目標。

但請記住,追蹤計畫時,估計具有有限的保存期限。我曾經記得一位脾氣暴躁的專案經理說,計畫和估計就像萵苣,保存幾天後仍然新鮮,一週後有點萎蔫,幾個月後就認不出來了。

許多團隊發現,估算提供了一個有用的強制功能,讓團隊成員彼此交談。估算會議有助於更了解實施即將到來的故事、未來的架構方向和程式碼庫中的設計問題的各種方法。在這種情況下,任何產出的估算數字可能並不重要。有許多方法可以進行此類對話,但如果沒有進行此類對話,則可以引入估算討論。[6]相反,如果您正在考慮停止估算,則需要確保估算期間的任何有用的對話仍在其他地方繼續進行。

參加任何具有敏捷傾向的會議,您都將聽到團隊在沒有估算的情況下有效工作的演講。通常情況下,這是因為他們及其客戶了解進行估算並不會影響重大決策。一個例子是一個與業務緊密合作的小團隊。如果更廣泛的業務樂於將一些人分配到該業務部門,那麼可以按優先順序進行工作;通常,團隊將工作分解成足夠小的單元,這有助於此。[7]團隊在敏捷流暢模型中的等級在這裡扮演著重要角色。隨著團隊的進步,他們首先在估算方面遇到困難,然後可以做得很好,然後達到通常不需要估算的程度。[8]

估算既不優也不劣。如果您可以在沒有估算的情況下有效工作,那麼請繼續進行,不要估算。如果您認為需要一些估算,那麼請確保您了解它們在決策中的作用。如果它們將影響重大決策,那麼請繼續並做出您所能做出的最佳估算。最重要的是,要提防那些告訴您估算總是需要或永遠不需要的人。關於估算使用的任何爭論都總是讓位於敏捷原則,即您應該決定哪些技術適合您的特定環境。

致謝

我在此再次感謝內部清單上的各種 ThoughtWorkers 對他們的評論。特別是,我想點名 Angela Ferguson、Dave Pattinson 和 Pat Kua。我還應該感謝 James Shore 對我關於流暢模型連結的問題做出如此迅速且良好的回應。

備註

1: 最近閱讀的是估算就是邪惡,這是 Ron Jeffries 對估算可能導致的問題進行的精彩討論。

2: 我從 Ron Jeffries 那裡得到這個類比,儘管我沒有書面參考。

3: 這種情況是 不當使用指標 的一個極佳範例。

4: 估計和期望

我特別喜歡我同事 Angela Ferguson 對此的一則評論:「估計設定期望的方式取決於我們 - 這是糟糕的專案管理(無論是專案經理或其他團隊成員),導致客戶認為估計是固定的,或原始估計等於實際工作量/持續時間」

「事實上,我試著每週向我的主要客戶傳達壞消息,即使事情按照預期進行時也是如此...「所以我們現在看起來進展得很順利,但如果我們發現某件事比預期花費更長的時間,或某個需求比預期更大,或我們發現某個新且非常重要的事情,你認為最好的行動方案是什麼?」然後你探討各種選項 - 刪減故事、增加時間、增加產能等。這表示當預期的意外事件發生時(因為我們知道它會發生),對客戶來說,對話不會顯得新奇且可怕。」

5: 大致上來說,人們對損失的痛苦是獲得的快樂的兩倍。

6: 如果你這樣做,像 ThrownEstimates 的方法可以幫助討論以良好的步調進行。

7: 當然,將工作分解成小單元需要一些隱含的估計,但那真的是一種與更常見的明確估計活動不同的動物。

8: James Shore 最近有一篇部落格文章 詳細說明他的觀察,說明流暢度如何影響估計實務。我認為對不同流暢度階段的實務進行類似的分析會非常有用。