【DevCloud·敏捷智庫】如何利用故事點做估算

　　背景

　　在某開發團隊輔導的第二天，一個團隊負責人諮詢道：“領導經常管我要開發計劃，我如何能快速的評估出預計開發完成時間呢，我們目前用工時估算，我聽說過故事點估算，不知道適合嗎?”

　　問題分析

　　從這個團隊負責人那裡瞭解到，領導一般在接到專案大量新需求時會問這個問題。領導需要做到“心裡有數”，有一個預計的專案新需求完成時間。加上領導一直做傳統的瀑布開發專案，他非常關心專案中遠期計劃，也就是我們通常講的里程碑或關鍵結點的問題。

　　團隊目前使用敏捷開發方式初期，團隊成員本身也對如何更快、更好地做好估算感到困惑，目前糾結是否應該採用故事點估算。

　　從以上問題分析中可以得出：第一，團隊對故事點不瞭解，需要學習什麼是故事點;第二，解決如何快速提供給領導開發計劃的問題。

　　解決措施

　　解決問題我們來分兩步走。首先解決不熟悉故事點的問題，先給大家介紹一下故事點的定義及特性。然後大家瞭解一下兩層估算即產品待辦列表估算和Sprint待辦列表估算的簡單區別，解決開發計劃的問題。

　　如果有時間，建議可以先看看上篇《如何估算第二篇：利用核心概念理解估算》瞭解估算的核心概念。然後再來看這篇文章效果更好。這篇文章主要講故事點。具體的估算方法有沒有比較好的實踐呢?在《如何估算第四篇：利用2種常見方法做估算》中會介紹幾種比較好的估算方法，包括：“計劃撲 克估算”、“敏捷估算2.0(Agile Estimating 2.0)”等。本篇仍然在為估算做技能儲備(磨刀不誤砍柴功)，即明確什麼是故事點。前面文章已經講過估算的一個核心概念即估算相對大小，這個相對大小我們用故事點為單位。工時和理想人天相信大家都理解，不做過多解釋。在這裡著重從故事點的定義、故事點的特性兩個方面解釋下什麼是故事點，然後解決給領導提供計劃的問題。

　　故事點的定義

　　故事點是表述一個使用者故事，一項功能或一件工作的整體大小的一種度量單位。當採用故事點估算時，我們為每個待辦項分配一個點數。待辦項估算結果的原生資料並不重要，我們只關注最後得到的相對估算結果。一個估算值為2的使用者故事應該是估算值為1的使用者故事的2倍。而它也應該是另一個估算值為3的使用者故事的三分之二。團隊不要採用100、200、300，而要使用1、2、3。估算結果是相對值，而不是絕對值。

　　“當使用故事點來估算使用者故事的大小時，並沒有固定的公式來規定如何計算故事點的數值。故事點估算用於評估為了交付一個使用者故事所包含的工作量(team effort)，使用者故事的複雜度(complexity)，風險，以及所有其他需要考慮的元素。——《Agile Estimating and Planning》, Mike Cohn.

　　故事點的特性說明

　　是相對單位

　　它是一個相對單位。比如，不同的組織團隊，對於同樣的使用者故事的故事點大小一般是不同的;即使同一團隊，針對不同使用者故事的故事點大小，甚至是針對同一使用者故事的故事點大小，都允許是不同的。但同時提醒，不同團隊不同使用者故事的故事點的設定，有利於組織能力的積累和橫向參考。

　　不等同於工作量估算

　　故事點估算不是簡單等同於工作量估算。如Mike Cohn所描述，它包含工作量、技術含量、各方面制約等多方面價值因素。有時其他的這些因素，在故事點估算中佔有比重會勝過工作量方面的考慮。

　　考慮“完成的定義”

　　以上介紹，有些朋友可能會問：有些團隊用工時(單位小時)來估算，不可以嗎?上一篇文章末尾提到，有些較成熟的團隊，也可以借鑑歷史資料和經驗，直接應用工時或理想人天估算也並非不可。　　故事點估算必須要覆蓋直到實現產品待辦項待真正完成的所有事項。如果團隊的“完成的定義”中包括了建立自動化測試來驗證這個故事(並且這是一個好主意)這個事項，那麼建立這些測試的工作量也應該包含在故事點估算結果中。

　　如果一定要推薦工時(或理想人天)和故事點分別在什麼時候應用比較好，那麼我一般推薦在做產品待辦列表估算時用故事點，而Sprint待辦列表估算時用工時(單位是小時)。

　　原因很簡單，結合最開始團隊負責人的問題，其實老闆大多對什麼時間點可以交付多少需求(使用者故事形式體現)感興趣。最常見的問題是：“這50個需求什麼時間可以做完?”很明顯，老闆並不是在問本Sprint能做完多少需求，而是在問專案得有一個預計的時間點或里程碑。換句話說就是，需要對某個時間點可以交付什麼樣價值做出一個長期一點的預測。如果每個故事平均15分鐘估算，那麼50個使用者故事估算需要50*15分鐘=750分鐘=12.5小時。顯然估算所需要花費的時間代價比較高，ROI太低。如果採用準確度差不多的故事點估算，則效率會大大提升。前面提到過為什麼故事點估算容易，這裡不再重複解釋。此時建議團隊平均3分鐘完成一個使用者故事的估算，那麼估算需要50*3分鐘=150分鐘=2.5小時。這樣根據團隊正常速率，就可以預計完成時間，回答老闆的問題了。

　　對於Sprint列表的估算，其目標更多的是要確定團隊本Sprint要完成的工作量，故事點顯得有點抽象。團隊具體執行時，時間概念上有點困難，而小時數就容易得多。通常Sprint列表項也會比產品待辦列表項少得多，所以時間上不會花費太多。另外，就Sprint列表中的工作項而言，它會是更具體的需求，通常會進行任務細化和“完成定義”，進而很清楚如何去做，誰來做。這些因素綜合看，以工時(小時)來估算成為優勢。

　　參考附錄

　　1. Mark C. Layton. 敏捷專案管理[M].北京：人民郵電出版社。

　　作者：黃藥師(黃雋)