背景

在某開發團隊輔導的回顧會議上，團隊成員對於優化估計具體方法上達成了一致意見。詢問是否有什麼具體的估計方法來做估算。

問題分析

回顧意見上大家對本次Sprint的效果做回顧，其中80%的成員對於本次Sprint的估算效果不滿意，最終團隊希望在下一個Sprint中，估算活動能有所改善。

經瞭解，團隊目前的估算方法很簡單，基本上是架構師和團隊中有豐富開發經驗的成員一言堂。估算的速度也很快。對於有些有疑問的需求，開發成員也是保持沉默，草草認領了任務。

團隊迫切希望學習新的估算方法來優化目前的估算活動，因此分享幾個具體的估算方法給團隊實踐，讓他們自己選擇適合、喜歡的估算方法是解決問題的關鍵。

解決措施

我們來學習下具體的故事點估算的實踐，感受一下估算。這裡介紹最常用的兩種估算方法：一個是計劃撲克估算，另一個是敏捷估算2.0。下表內容展示了這兩種估算方法在什麼情形下選擇。

計劃撲克估算

在敏捷開發中，最典型的使用故事點做估算的方法是計劃撲克（Planning Poker）。

計劃撲克由James Grenning在2002年首次提出。計劃撲克集合了專家意見（Expert Opinion），類比（Analogy）以及分解（Disaggregation）這三種常用的估算方法，使團隊通過一個愉快的過程快速而準確的得出估算結果。

計劃撲克的參與者是團隊的所有成員。典型的敏捷團隊規模推薦為7±2人，如規模比較大可以考慮拆分成為多個小團隊各自獨立進行估算。Product Owner也需要參加，但不參與估算。

計劃撲克開始時，每個參與估算的組員都會得到一副計劃撲克，每一張牌上寫有一個Fibonacci數字 （典型的計劃撲克由12張牌組成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表資訊不夠無法估算，∞代表該使用者故事太大）。

開始對一個使用者故事進行估算時，首先由Product Owner介紹這個使用者故事的描述。過程中Product Owner回答組員任何關於該使用者故事的問題。展開討論時主持人(通常由Scrum Master擔任)應注意控制時間與細節程度，只要團隊覺得對使用者故事資訊已經瞭解到可以估算了，就應當中止討論開始估算。

所有問題都被澄清後，每一個組員從 撲克中挑選他／她覺得可以表達這個使用者故事大小的一張牌，但是不亮牌，也不讓別的組員知道自己的分數。所有人都準備好後，主持人發口令讓所有人同時亮牌，並保證每個人的估算值都可以被其他人清楚的看到。

經常會出現不同組員亮出的分值差距很大的現象。當出現有很多不同分值的時候，出分最高的人和出分最低的人需要向整個團隊解釋出分的依據。（主持人需要注意控制會議氛圍，避免出現意見不一導致的攻擊性言論。）所有的討論應集中於出分者的想法是否值得團隊其他成員進行更深入的思考。

隨後全組可以針對這些想法進行幾分鐘的自由討論。討論之後，團隊進行下一輪的全組估算。一般來說，很多使用者故事在進行第二輪估算的時候就能得到一個全組統一的分值，但是如果不能達到全組意見一致，那麼就重複的進行下一輪直到得到統一結論。

敏捷估算2.0（Agile Estimating 2.0）

計劃撲克是Scrum團隊應用最廣泛的敏捷估算方法，但是有時候計劃撲克玩起來耗費比較多的時間，尤其是在十人左右的團隊中。Ken Schwaber在他的書《Agile Project Management with Scrum》中指出，在進行迭代規劃時，迭代計劃環節應該控制為一個4小時的固定時間，但是從戰術的角度看，如果一個會議持續4小時，大部分的參會者會有精疲力竭的感覺，並且很難保持持久的注意力。

為了解決這個問題，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介紹了Agile Estimating 2.0技術。這個新的估算技術同樣基於的專家意見，類比和分解，同樣適用Fibonacci數列，但是它可以顯著地縮短會議時間。它的估算過程大致分為主要四步，如下圖所示：

第一步：由Product Owner向團隊介紹每一個使用者故事，確保所有需求相關的問題都在做估算前得到解決。

第二步：整個團隊一起參與這個遊戲。

只有一個簡單的遊戲規則：一次僅由一個人將一個使用者故事卡放在白板的合適位置上：規模小的故事在左，大的在右，一樣大的豎向排成一列。整個團隊輪流移動故事卡，直到整個團隊都認同白板上的故事卡的排序為止。

第三步：團隊將故事點（Story Point）分配給每個使用者故事（列）。

最簡單的做法是使用投票來決定每個使用者故事分配到哪一個Fibonacci數字。

最後一步：使用不同顏色來區分影響估算大小的不同方面，並且重新考慮是否需要修改估算值。

例如，我們使用紅色來表示那些無法被自動化測試指令碼覆蓋的使用者故事，因此那些使用者故事需要一個更大的數字來容納手工迴歸測試的代價。

在國內一些企業多次實踐Agile Estimating 2.0之後，反饋的結果還是令人興奮。據稱，團隊對於估算的準確性更有信心了，並且只耗費原先的1/2時間。

通過以上介紹，相信瞭解瞭如何使用使用者故事來分析瞭解需求。在學習了估算的核心概念及故事點後，對於估算方法的實踐也有了更深的體會。不論是計劃撲克估算還是敏捷估算2.0都只是估算的一種實踐，不是固定的唯一方法。只要理解估算的意義和核心概念，選擇適合的方法就是沒有問題的。另外補充一下，這裡講的估算偏重於用故事點估算，如果團隊成員一致達成共識，用工時或理想人天效果更好，便可以嘗試，給予團隊試錯的機會，說不定也有意想不到的收穫。

完成了估算後，我們需要對估算的內容進行管理。華為雲DevCloud在使用者故事或者Task中均有一個記錄估算結果的屬性，比如預計工時。所有工作項估算結果記錄以後就可以以列表的方式進行檢視。可以按處理人排序，檢視每個成員認領的任務是否飽和。

開發團隊完成的工作內容可以時時更新實際資料，這樣每輪迭代也可以就估算準確度進行統計和分析。看看估算結果和實際結果的差別，以便可以後續做估算調整和改善。

參考附錄

1. Kenneth S. Rubin. Scrum精髓[M].北京：清華大學出版社。
2. Mark C. Layton. 敏捷專案管理[M].北京：人民郵電出版社。

估算系列文章

【DevCloud · 敏捷智庫】估算第一篇：利用使用者故事瞭解需求

【DevCloud · 敏捷智庫】估算第二篇：利用核心概念解決估算常見問題

【DevCloud · 敏捷智庫】估算第三篇：利用故事點做估算

點選關注，第一時間瞭解華為雲新鮮技