在某開發團隊輔導的回顧會議上，團隊成員對于優化估計具體方法上達成了一緻意見。詢問是否有什麼具體的估計方法來做估算。
回顧意見上大家對本次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擔任)應注意控制時間與細節程度，隻要團隊覺得對使用者故事資訊已經了解到可以估算了，就應當中止讨論開始估算。
所有問題都被澄清後，每一個組員從 撲克中挑選他／她覺得可以表達這個使用者故事大小的一張牌，但是不亮牌，也不讓别的組員知道自己的分數。所有人都準備好後，主持人發密碼讓所有人同時亮牌，并保證每個人的估算值都可以被其他人清楚的看到。
經常會出現不同組員亮出的分值差距很大的現象。當出現有很多不同分值的時候，出分最高的人和出分最低的人需要向整個團隊解釋出分的依據。（主持人需要注意控制會議氛圍，避免出現意見不一導緻的攻擊性言論。）所有的讨論應集中于出分者的想法是否值得團隊其他成員進行更深入的思考。
随後全組可以針對這些想法進行幾分鐘的自由讨論。讨論之後，團隊進行下一輪的全組估算。一般來說，很多使用者故事在進行第二輪估算的時候就能得到一個全組統一的分值，但是如果不能達到全組意見一緻，那麼就重複的進行下一輪直到得到統一結論。
計劃撲克是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中均有一個記錄估算結果的屬性，比如預計工時。所有工作項估算結果記錄以後就可以以清單的方式進行檢視。可以按處理人排序，檢視每個成員認領的任務是否飽和。
開發團隊完成的工作内容可以時時更新實際資料，這樣每輪疊代也可以就估算準确度進行統計和分析。看看估算結果和實際結果的差别，以便可以後續做估算調整和改善。
參考附錄
Kenneth S. Rubin. Scrum精髓[M].北京：清華大學出版社。
Mark C. Layton. 靈活項目管理[M].北京：人民郵電出版社。
【DevCloud · 靈活智庫】估算第一篇：利用使用者故事了解需求
【DevCloud · 靈活智庫】估算第二篇：利用核心概念解決估算常見問題
【DevCloud · 靈活智庫】估算第三篇：利用故事點做估算
點選關注，第一時間了解華為雲新鮮技術~