【華爲雲技術分享】【DevCloud · 敏捷智庫】如何利用核心概念解決估算常見問題

摘要：團隊用於估算時間過多，留給開發的時間會相應減小，你們工做緊張，狀態不佳。團隊過分承諾直接形成迭代目標不能完成，士氣低落。以上弊端直接傷害敏捷團隊，是敏捷團隊保持穩定健康節奏的阻力。

背景

敏捷江湖桃花島社區下線會議時，敏捷實踐者問了不少關於估算的問題。做者在這裏把具備共性的問題簡單作了梳理。問題主要集中在團隊只關心估算結果，也就是數字。再則團隊常常在外界壓力下過分承諾迭代目標。這兩個比較集中的問題描述以下：

問題一：團隊只關心數字。計劃會議你們只關心估算的數字，常常花費大量時間作估算，怎麼辦？

問題二：團隊過分承諾。有時候，團隊被迫承諾過多的工做，迭代目標完不成，怎麼辦？

團隊用於估算時間過多，留給開發的時間會相應減小，你們工做緊張，狀態不佳。團隊過分承諾直接形成迭代目標不能完成，士氣低落。以上弊端直接傷害敏捷團隊，是敏捷團隊保持穩定健康節奏的阻力。

 

問題分析

以上兩個問題也是敏捷初始團隊常常碰見的問題，現簡單分析發生緣由以下：

問題一：團隊只關心數字。

團隊從瀑布開發方式轉爲敏捷開發後，學習了敏捷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種常見方法作估算》。

 

參考附錄

1. Kenneth S. Rubin. Scrum精髓[M].北京：清華大學出版社。
2. Mark C. Layton. 敏捷項目管理[M].北京：人民郵電出版社。
3. Rachel Davies. Liz Sedley.敏捷教練[M].北京：清華大學出版社。