摘要：團隊用於估算時間過多，留給開發的時間會相應減少，大家工作緊張，狀態不佳。團隊過度承諾直接造成迭代目標不能完成，士氣低落。以上弊端直接傷害敏捷團隊，是敏捷團隊保持穩定健康節奏的阻力。
背景
敏捷江湖桃花島社區下線會議時，敏捷實踐者問了很多關於估算的問題。作者在這裏把具有共性的問題簡單做了梳理。問題主要集中在團隊只關心估算結果，也就是數字。再則團隊經常在外界壓力下過度承諾迭代目標。這兩個比較集中的問題描述如下：
問題一：團隊只關心數字。計劃會議大家只關心估算的數字，經常花費大量時間做估算，怎麼辦？
問題二：團隊過度承諾。有時候，團隊被迫承諾過多的工作，迭代目標完不成，怎麼辦？
團隊用於估算時間過多，留給開發的時間會相應減少，大家工作緊張，狀態不佳。團隊過度承諾直接造成迭代目標不能完成，士氣低落。以上弊端直接傷害敏捷團隊，是敏捷團隊保持穩定健康節奏的阻力。
問題分析
以上兩個問題也是敏捷初始團隊經常遇見的問題，現簡單分析發生原因如下：
問題一：團隊只關心數字。
團隊從瀑布開發方式轉爲敏捷開發後，學習了敏捷Scrum框架，然後開始使用敏捷開發。他們知道其中有一個事件是迭代計劃會議。在會上團隊成員經常耗費大量時間做估算。常見對話：“這個估算數字合理嗎，我們要不要再好好想想清楚？”因此團隊常常陷入無休止的討論中。團隊狹隘的理解爲，計劃會議中最重要的事情就是估算，而估算最重要的事情就是得到每個用戶故事完成所需要花費的精確時間，即數字。也就是說，團隊過於追求數字的準確性，忽略了估算的真正核心價值。
問題二：團隊過度承諾。
團隊經常在產品上市日期已經確定的情況下過度承諾。因爲時間緊迫，領導施壓（與資金和績效掛鉤）。比如，領導經常說：“大家加把勁兒，我相信大家的能力，努力一下，這些需求你們是可以做完的，大家的表現會影響績效評估，年底咱們多發點資金。”所以團隊常常了了估算、一言堂（架構師說的算）、猜測工作量，最後造成過度估算，經常完成不了迭代目標。
小結
“團隊只關心數字”和“團隊過度承諾”兩個問題是敏捷初始團隊經常遇見的問題。從以上問題分析中可知，團隊成員並沒有瞭解估算的真正核心意義，導致團隊狹隘地理解成估算就是要最後的數字，而且在有外部壓力的情況下團隊也顧不上認真估算，盲目地過度承諾工作內容。
其實估算並不只是爲了得到估算數字和不靠譜的承諾。我們先一起學習和了解什麼是估算的核心內容，這樣可以更好地理解估算，然後再針對以上2個問題進行解答。
解決措施
利用核心概念樹立正確認識
在這裏，我們只考慮不瞭解核心概念而導致估算活動不理想的情況。還有其它情況可以導致估算活動不理想。比如，不會利用故事點估算、不會估算具體方法等。這兩種情況我們在後續的2篇文章中給予解答。
通過上一篇《估算第一篇：利用用戶故事瞭解需求》相信瞭解瞭如何利用用戶故事理解需求。如果對用戶故事不太瞭解的朋友，建議可以花一點時間閱讀上篇文章，也會有助於做好估算。
現在我們一起了解一下估算的4個核心概念，以便理解估算，樹立正確認識，然後才能更好地解答以上2個問題。估算的4個核心概念所對應解決的問題如下表所示：
|
問題 |
估算核心概念 |
|
問題一：團隊只關心數字。 |
利用“區分準確與精確”：估算應該準確，但不必過分精確。 |
|
利用“估算相對大小”：人們更擅長對大小進行估算，而不是絕對大小。 |
|
|
問題二：團隊過度承諾。 |
利用“團隊一起估算”：在估算活動中，團隊成員一起估算，結果更合理。 |
|
利用“估算不是盲目承諾”：估算不是承諾，重要的是我們不能這樣認爲。 |
區分準確與精確
估算應該準確，但不必過分精確。比如，我們估算某產品是10888人時（是怎麼做到這麼精確的？）。其實這是很荒唐的，過於精確的估算純屬浪費。我們需要應該投入剛好夠用的工作量，得到一個剛好的、大致正確的估值，如做估算時工作量和準確度的對比圖所示：
做估算時工作量和準確度的對比圖
在做估算時，有一個收益遞減的點，在這個點之外，額外投入任何時間和精力都不會使估算更準確。在這個點之外，就屬於浪費時間。
團隊成員在做一項工作的同時，難免會遇到各種各樣的問題，所以爲了做到準確估算，在做估算時，任務的拆分一定要適當細，只有細化後，團隊成員才清楚每項工作預計會花多少時間。當然細化也是有個度的，如前面提到的做估算時工作量和準確度的對比。當團隊成員反饋超過預計工時時，需要了解是不是遇到了什麼困難，需不需要幫助解決。超過16小時的任務建議需要再細化。
在做估算時，我們經常會填寫預計工時和實際工時。預計工時是我們估算的結果，實際工時是對估算結果的檢驗。我們允許預計工時的不準確，但是一定要填寫準確的實際工時，這樣纔有助於我們在估算不準的問題上有充分的證據做分析，然後改進，進行良性循環。隨着團隊成熟度的提高和對業務的越來越瞭解，估算準確度經過幾個Sprint會有所提高。
估算相對大小
建議使用相對大小而不是絕對大小來估算PBI。比較所有條目，然後確定某個條目和其它條目的相對大小。如下圖所示，討論一個杯子相對於另一個有多大比較容易，但對於杯子中可以盛多少絕對數量的液體，我們可能沒有概念。
相對大小對比圖
人們更擅長對大小進行估算，而不是絕對大小。讓團隊成員做估算，建議用大家都擅長的技術。當然，有些較成熟的團隊，也可以借鑑歷史數據和經驗，直接應用工時或理想人天估算也並非不可。更多關於相對大小的內容介紹，可以閱讀下一篇《如何估算第三篇：估算故事點》，其中會介紹一個具體實踐，即故事點估算。
團隊一起估算而不是個別人估算
在估算活動中，團隊成員一起估算，而不是僅僅由項目經理、架構師、主要程序員估算。簡單說，是負責完成工作的所有人，也就是指實際動手設計、構建並測試PBI的開發團隊來估算。產品負責人和Scrum Master這兩個角色都在場，但並不實際參與估算。產品負責人負責闡述PBI，並回答團隊要求澄清的有關需求的問題。Scrum Master負責幫助指導和引導估算活動。最終的目的是開發團隊能夠一起確定每個PBI的大小，當然包括開發和測試的所有工作量。團隊成員一起估算也是爲了確保工作沒有遺漏，不管怎麼拆分任務，甚至是不拆分任務以story爲最小顆粒度，那就按照story可以上線爲標準來估算。如果團隊非常關注每個人手頭上的task，比如測試和開發人員手頭上的task，那就沒有統一標準，根據具體task內容估算。 記錄工作項工時，可以參考華爲雲DevCloud，工作項工時顯示如下圖所示。
需要客觀估算而不是盲目承諾
估算不是承諾，重要的是我們不能這樣認爲。舉一個例子，如果在估算的時候告訴團隊成員他們的估算正確性直接影響着他們的獎金和績效，那麼每個人都會給出一個比開始大得多的估值。估算應該是較爲實際的估值，應該靠譜，我們不想因爲外因而人工放大估算值，變成團隊成員往上加和管理層往下減的拋球遊戲。
所以，團隊成員在沒有外因干擾情況下，大膽、放心的估算工作量，也就是估算預計工時。預計工時不僅僅是用於安排任務和估算本Sprint PBI在哪個時間點完成的,它還可以用於持續改進。預計工時就是估算需要多少時間可以完成，在Sprint進行中，會讓團隊成員根據實際情況去更新實際工時。例如，昨天更新4小時，今天又更新4小時，那就把實際工時更新爲8小時。當Sprint結束後覆盤時，我們會整體看這些預計工時和實際工時的數據，主要是爲了提升團隊/個人估算水平。如果估算和實際有明顯差距，是需要深入分析的。本身也是期望通過估算促進做簡單設計。
應用正確認知處理問題，做好估算
以上是估算的核心內容。現在我們回頭看看之前的兩個問題。
問題一：團隊只關心數字。
面對這個問題，作者主張團隊成員不要只是關心數字，還要關心投入產出比（ROI），避免浪費。另外還可以考慮採用更快、更易於理解的方式來進行估算。
從估算的核心概念“準確與精確”中瞭解到，在做估算時，有一個收益遞減的點，在這個點之外，額外投入任何時間和精力都不會使估算更準確。在這個點之外，就屬於浪費時間。另外從估算的另一個核心概念“估算相對大小”中瞭解到，人們更擅長對大小進行估算，而不是絕對大小。讓團隊成員做估算，建議用大家都擅長的技術。因此，我們在做估算時：首先，要把握一個估算的適度準確原則，不要過度浪費。其次，爲了降低難度，團隊更好的達成一致意見，可以採用相對大小方式進行估算。
問題二：團隊過度承諾。
面對這個問題，作者主張估算由真正完成工作的成員在安全的環境下大膽、放心地估算，避免過度承諾。
從估算的核心概念“團隊估算”中瞭解到，估算活動是負責完成工作的所有人，也就是指實際動手設計、構建並測試PBI的開發團隊來完成。也就是說，真正完成工作的人才會對工作需求內容更用心，也更瞭解團隊的速率，他們的承諾更客觀。估算另一個核心概念“估算不是承諾”中提到，估算應該是較爲實際的估值，應該靠譜，我們不想因爲外因而人工放大估算值，變成團隊成員往上加和管理層往下減的拋球遊戲。團隊成員在沒有外因干擾情況下（不建議獎金、績效明顯掛鉤），大膽、放心的估算工作量。如果能做到以上相信至少在估算的結果上更爲客觀和靠譜。
有些朋友可能會問，如果得到的估算結果是靠譜的，完成需求就是那麼多工作量，產品上市日期也已經確認，那麼怎麼辦？如果真的是因爲產品上市日期已定，有上線壓力，團隊一定要承諾過多的工作內容，那麼就確保團隊把故事拆分得更細，即使他們交付不出設想中的高檔理想的全功能版，至少也能每個典型的功能領域多少交付一些內容。說到這裏，還是不建議這樣做，儘量採用高價值的事情優先做原則，與客戶協商，產品經理對需求排好優先級，優先實現高優先級的PBI。
瞭解更多
以上是針對不瞭解估算核心概念而導致估算活動不理想的解決措施。朋友們看到這裏，相信對估算的核心有了基本瞭解。也許對什麼是故事點估算以及具體估算方法感興趣，歡迎閱讀接下來的關於估算的另外兩篇文章，即《如何估算第三篇：利用故事點做估算》和《如何估算第四篇：利用2種常見方法做估算》。
參考附錄
- Kenneth S. Rubin. Scrum精髓[M].北京：清華大學出版社。
- Mark C. Layton. 敏捷項目管理[M].北京：人民郵電出版社。
- Rachel Davies. Liz Sedley.敏捷教練[M].北京：清華大學出版社。