【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].北京：人民郵電出版社。

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