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

背景

在某開發團隊輔導的次日，一個團隊負責人諮詢道：「領導常常管我要開發計劃，我如何能快速的評估出預計開發完成時間呢，咱們目前用工時估算，我據說過故事點估算，不知道適合嗎？」

問題分析

從這個團隊負責人那裏瞭解到，領導通常在接到項目大量新需求時會問這個問題。領導須要作到「內心有數」，有一個預計的項目新需求完成時間。加上領導一直作傳統的瀑布開發項目，他很是關心項目中遠期計劃，也就是咱們一般講的里程碑或關鍵結點的問題。

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

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

解決措施

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

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

故事點的定義

故事點是表述一個用戶故事，一項功能或一件工做的總體大小的一種度量單位。當採用故事點估算時，咱們爲每一個待辦項分配一個點數。待辦項估算結果的原生數據並不重要，咱們只關注最後獲得的相對估算結果。一個估算值爲2的用戶故事應該是估算值爲1的用戶故事的2倍。而它也應該是另外一個估算值爲3的用戶故事的三分之二。團隊不要採用100、200、300，而要使用一、二、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].北京：人民郵電出版社。

點擊關注，第一時間瞭解華爲雲新鮮技術~