深度解析：故事點估算看這一篇就夠了 | IDCF

我在輔導團隊對用戶故事進行故事點估算的時候，常常會遇到以下問題：

• 用戶故事的工做量估算爲何要用故事點，而不是時間？
• 故事點估算爲何要用斐波那契數列？
• 斐波那契數列的數字爲何被改了？
• 爲何要用估算撲克？
• 爲何要有基準故事？
• 怎樣肯定基準故事？
• 其餘故事怎樣與基準故事作相對估算？
• ……

我在翻閱了大量零散的資料之後，終於把這些問題搞清楚了。若是你也遇到過相似上述的問題，能夠花點時間閱讀下這篇文章，相信不會讓你失望的。

1、爲何用故事點而不是時間

在回答這個問題以前，咱們先看個例子：

韓梅梅和李雷一塊兒去北京奧林匹克森林公園跑步，李雷對韓梅梅說：咱們跑南園這條路吧，這大概要花30分鐘。

這條路韓梅梅很熟，可是做爲一個跑步很慢的人，韓梅梅內心清楚這要花60分鐘。因此，韓梅梅告訴李雷，她跑過這條路的，須要花60分鐘。

而後他們就爭執起來了：30-60-30-60……

他們爭執半天沒有結果，做爲一個熱心的旁觀者，你可能會勸他們互相妥協一下，就算45分鐘吧？可是這樣也許是最壞的結果，由於他們雖然有了一個折中的方案，可是這個結果對雙方都不太實際：李雷以爲太慢了，而韓梅梅以爲太快了。

因此，他們繼續爭論：30-60-30-60……

最終，李雷跟韓梅梅說：南園這條路大概5km，我能在30分鐘內跑完它。

韓梅梅說：我贊成這段路程是5km，但它要花我60分鐘。

他們兩個都是對的：李雷真的能在30分鐘內跑完，韓梅梅也真的須要60分鐘。但當他們想爲這段路程統一時間估算時，他們發現作不到，由於你們跑步的速率不一樣。

可是，當他們使用了一個抽象的長度度量單位（km），他們很快就達成了一致。李雷和韓梅梅都贊成這段路程是5千米，可是因爲他們的速度（相對度量單位）不一樣，致使他們花費的時間（絕對度量單位）也不一樣。

例子說完了，不少人這時候可能已經想到了一個公式：距離（km）=速度（km/h）*時間（h），那我爲何要舉這個例子呢？難道只是帶你們回憶一下小學數學？

其實軟件開發中任務的工做量跟跑步的「距離」是很是相似的概念：同一個任務，無論誰來作，它的工做量都是同樣的，只不過能力強的人就作得快一點（耗時少）；能力弱的人就作得慢一點（耗時多）。

與跑步相似，若是咱們讓多我的就同一個開發任務的耗時達成一致，那是很難的，可是若是咱們能有一個描述軟件開發工做量的單位（相似表示舉例的km），咱們可能就能很快達成一致。而「故事點」就是敏捷開發創造出來的用來表示開發任務工做量的單位，它跟例子中用來表示距離單位的「km」的做用差很少：它能使不一樣技術水平和工做速率的人在工做量的估算上快速達成一致。固然，敏捷開發的主角是具備不一樣工做效率的開發人員，而不是例子中不一樣跑步速度的跑者。

就像這兩個跑步的人，兩個程序員也許贊成一個用戶故事是5個故事點（類比例子中的5千米，都是一種抽象度量單位）。高級開發人員可能以爲這很容易，1天（時間）就能完成。初級開發人員可能以爲須要2天才能搞定。可是他們能在5個故事點上快速達成一致，由於把第一個用戶故事定成5個故事點是不須要什麼依據的（就像不一樣國家或地區對長度單位的定義可能不一樣，好比米、寸、英寸等，每一個團隊對故事點的大小也均可以有本身的標準，只要團隊成員都承認便可）。

不過，最重要的是，一旦他們贊成第一個故事的工做量是5個點，這兩個開發人員就能夠對後續估算達成共識。若是高級開發人員認爲一個新的用戶故事將須要兩天（兩倍於他估計爲5個點的故事），他將評估新的故事爲10個點。而初級開發人員也會這樣作，當他估算須要4個工做日時（兩倍於他估計爲5個點的故事），他將評估新的故事爲10個點。

因此，使用故事點而不使用時間的緣由是，故事點可使能力不一樣的開發人員在估算同一任務時快速達成一致。

2、爲何要用斐波那契數列估算故事點

2.1 人們沒法分辨過小的差別

德國生理學家E.H.韋伯經過對重量差異感受的研究發現一條定律，即感受的差異閾限隨原來刺激量的變化而變化，並且表現爲必定的規律性，刺激的增量(△I)和原來刺激值(I)的比是一個常數(K)，用公式表達即K=△I/I，這個常數叫韋伯常數、韋伯分數或韋伯比率。

上面的定義是從百度百科拷貝下來的，簡單來講就是：咱們只能分辨出兩個物體間必定百分比外的差別。

好比：咱們大部分人都能分辨出1公斤和2公斤物體，但可能沒法分辨出20公斤和21公斤物品。它們一樣是相差了1公斤，爲何有的能分辨出來，有的就分辨不出來了呢？這是由於1公斤和2公斤之間的差異是100％，可是20公斤和21公斤之間的差別僅爲5％，20公斤和21公斤之間的百分比差別過小了。

這就是韋伯定律想要告訴咱們的：差別過小，咱們是分辨不出來的；只有差別大到必定程度，才能被咱們分辨。那人們能夠分辨出多大比例的差別呢？

2.2 人們能夠分辨出的差別比例

韋伯定律只是告訴了咱們能夠識別必定百分比差別外的區別，可是這個百分比是多少呢？天然界有個神奇的數字：0.618，即黃金分割比例。

黃金分割比例的現象在咱們身邊有不少，好比：

• 人們的肚臍是人體總長的黃金分割點
• 大多數門窗的寬長之比也是0.618
• 有些植莖上，兩張相鄰葉柄的夾角是137°28'，這剛好是把圓周分紅1:0.618
• 一些名畫、雕塑、攝影做品的主題，大多在畫面的0.618處
• ……

甚至在醫學領域，當一個患者報告說本身感覺到了病情的好轉，那麼實際上他的病已經好了65%。

也就是說，61.8%這個百分比差別對不少人來講，是能夠輕易分辨出來的。

2.3 斐波那契數列大體符合了黃金分割比例

斐波那契數列之因此能很好的用於故事點的估算，是由於該數列的數字分佈大體符合了黃金分割比例。在這個數列中，一、二、三、五、八、1三、21……，前兩個值（後一個值比前一個值大100％）以後，後面的每一個數字都比前一個數字值大60％左右。

根據韋伯定律，若是咱們能夠區分兩個工做量相差60％的故事，則能夠區分其餘相同百分比差別的故事。

所以，斐波那契值之因此能很好地工做，是由於它們每次都以大約相同的比例增長，且該比例基本符合黃金分割比例。

3、爲何敏捷估算要使用修正後的斐波那契數列

標準的斐波那契數列是一、二、三、五、八、1三、2一、3四、55……，可是目前絕大多數團隊在估算時使用的斐波那契數列是一、二、三、五、八、1三、20、40、100……，數列的前面6個數字是同樣的，可是從第7個數字開始，就徹底不同了，這是爲何呢？

Mike Cohn曾經在他的文章中提到，早期的估算他都是根據真實的斐波那契數列進行的（一、二、三、五、八、1三、2一、3四、55……）。

這個數列越日後數字越大，也就說明估算越不許確，因此對於2一、3四、55這樣的估算值，不少人都以爲很奇怪：既然已經估不許了，爲何非要使用21，而不將其四捨五入爲20或25呢？

因而Mike Cohn就接受了這個建議，在以後的團隊輔導及授課中他就開始使用20而不是21了，而且一直持續到了如今。

後來他又嘗試使用了40和100這兩個數代替了數列的其餘值，之因此這麼使用，是由於任務的粒度越粗，估算就越不許確，也就越不須要糾結究竟是80、90仍是100了。

同時，使用40和100也是不違反韋伯定律的，它們分別比以前的數字增長了100％（20 →40）和150％（40 →100）。這比黃金分割比例的61.8％大得多，人們是能夠輕鬆的分辨出這些工做量的區別的。

後來在Mike Cohn的影響下，如今大部分公司在敏捷估算中都開始使用修正後的斐波那契數列了：一、二、三、五、八、1三、20、40、100、∞。

4、爲何要使用規劃撲克

相信不少人在估算故事點時，都是使用物理或電子的規劃撲克進行的，咱們爲何要這麼作呢？這個問題須要從一個心理學名詞「從衆效應」提及。

4.1 什麼是從衆效應

在估算故事點時，當有人提出一個估算，即便你不一樣意，但當別人都表達贊同時，你仍是會隨聲附和，這就是所謂的「從衆效應」：人們認爲若是其餘人都贊同某一件事時，那麼本身的保留意見則是愚蠢的或是誤導性的，他們不想在其餘人面前出醜。

這個弱點不是個體獨有的，而是全人類共有的。

與「從衆效應」相關的概念還有信息瀑布和光環效應：

1）信息瀑布

一篇叫作《A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades》的論文中首先提到了這個概念：若是一我的觀察到以前衆人的行爲後，認爲最佳的作法是放棄本身掌握的信息，聽從以前衆人的行爲，那麼這個時候信息瀑布就出現了。

2）光環效應

當認知者對一我的的某種特徵造成好或壞的印象後，還傾向於推論該人其餘方面的特徵，本質上屬於以偏概全的認知錯誤。與從衆效應同樣，光環效應也會致使人們將目光集中到某一個有正面色彩的光環上，從而忽視了實際數據。

從衆效應的危害很大，咱們要怎麼作才能避免它呢？

4.2 使用「德爾菲法」下降從衆效應的影響

德爾菲法，也稱專家調查法，1946 年由美國蘭德公司創始實行，其本質上是一種反饋匿名函詢法，其大體流程是在對所要預測的問題徵得專家的意見以後，進行整理、概括、統計，再匿名反饋給各專家，再次徵求意見，再集中，再反饋，直至獲得一致的意見。

蘭德公司使用這個方法作過一個匿名投票，投票的主題是「冷戰期間，若是蘇聯要摧毀美國的主要工業目標，須要多少枚原子彈？」。

他們找來了一羣專家，包括4名經濟學家、1名物理脆弱性方面的專家、1名系統分析師及1名電氣工程師。這幾我的都是各個領域的專家，可是第一輪投票的結果差異很是大，少則50枚，多則5000枚。

在第一輪投票後，組織方將各個專家的意見整合後發給了你們，好比各個目標的脆弱性、各個行業的恢復能力、工廠的安全性、不一樣零部件的交付週期、打擊目標的準確性等等，而後又組織各位專家進行了第二次投票，評估差別縮小到了89~800之間。

反覆開展上述過程，最終差別愈來愈小，最後落在了167~360之間。

最初的評估結果相差100倍，到最後，縮小到了2倍。藉助這一工具，既能讓專家達成廣泛的共識，又不會擔憂出現什麼偏見。

爲了下降用戶故事估算時的「從衆效應」，因此如今不少團隊就採用了規劃撲克這種獨立投票的方式。規劃撲克的具體使用方法會在第5.3節中進行介紹。

5、如何估算故事點

5.1 肯定基準故事點

每次估算時，最好使用相同的基準用戶故事做爲1個點（稱做基準故事點，相似表示距離時先肯定好1km表明多長），這樣對於整個項目的統計有很大幫助。其餘的故事都基於這個基準故事作相對估算，就能夠獲得其餘故事的工做量了，每一個迭代完成的故事點能夠有效的統計團隊生產能力在各個迭代的變化。

對於初次實施敏捷的團隊，對基準故事和基準故事點的肯定可能會很迷茫：基準故事點若是定的太大，可能就會存在不少低於1故事點的故事；定的過小了又會致使其餘故事的故事點會很大。根據個人實踐經驗，初次評估故事點時，能夠嘗試使用一個有1次先後端網絡通訊、前端有一個頁面、後端有一次數據庫交互的用戶故事做爲基準故事，將其工做量定位1個故事點，好比不少系統都有的登陸功能，就是一個很好的基準故事，這樣的故事工做量不會太大，同時也不至於太簡單。

5.2 相對估算的依據

基準故事點肯定好之後，其餘的故事怎樣與它對比呢？怎樣肯定另外一個故事的工做量是基準故事的幾倍呢？咱們能夠從如下3個因素考慮：

1）要開展的工做數量（The Amount of Work）

若是要開展的工做越多，工做量的估算值固然就會越大。考慮兩個網頁開發的案例。第一個網頁只有一個字段和一個要求輸入姓名的標籤。第二個網頁有100個要輸入一小段文本的字段。

第二個網頁並不比第一個網友更復雜。字段之間是不存在交互的，每一個字段只不過是一點文本而已。所以第二個網頁並不存在額外的風險。這兩網頁之間的惟一區別就是第二頁有更多的事情要作。

應該給予第二個網頁更多的故事點數。但它即便有多了100倍的字段數，可能仍然得不到多100倍的點數。畢竟，因爲規模經濟效應，第二個網頁的工做量可能只是第一個網頁的工做量的2或3倍。

2）風險和不肯定性（Risk and Uncertainty）

用戶故事的風險和不肯定性會影響其故事點估算值。

若是用戶故事的干係人在詢問需求時說得不清不楚，那麼團隊在估算時應當把不肯定性也反映在估算結果中。

若是要實現一項功能時須要改動一段缺少自動化測試、結構脆弱的老代碼，那麼估算結果中也應該反映這個風險。

3）複雜度（Complexity）

在進行故事點估算時，還應該考慮複雜度。回顧一下以前那個有100個瑣碎文本字段且字段之間無交互的Web網頁開發的例子。

如今考慮另外一個也有100個字段的網頁。但這些字段中，有些是採用日曆控件彈出的日期字段；有些是格式化的文本字段，如電話號碼或身份證號；另外一些字段則須要作銀行卡號的校驗和驗證。

頁面上的字段之間還要相互交互。若是用戶輸入的是一個189開頭的號碼，則運營商字段默認顯示中國電信。可是若是用戶輸入的是一個139開頭的號碼，則運營商字段默認顯示中國移動。

儘管這個頁面上仍然只有100個字段，但這些字段更難實現。它們更復雜，須要花更多時間才能實現。開發人員出錯的可能性更大，所以不得不採起一些預防和糾正措施。

這種額外的複雜度都應該反映在所提供的估算結果中。

5.3 使用規劃撲克集體估點

(規劃撲克)

在4.2節介紹了怎樣使用「德爾菲法」下降從衆效應的影響，在敏捷開發中，咱們能夠藉助規劃撲克來進行匿名投票。在估算會議上，團隊中的每位人員都會獲得一副紙質撲克，固然，隨着移動互聯網的普及，目前大多數敏捷團隊使用了更爲便捷的電子撲克。這裏有2張撲克的含義須要解釋下：

若是有人出了「☕️」這個撲克，說明須要休息一會了；

若是有人出了「？」這個撲克，說明他不瞭解需求，沒法估算工做量，PO須要嘗試從新澄清需求。

同4.2節介紹的案例同樣，咱們在規劃故事點數時，第一輪你們的估點可能也會有很大的差距。若是估算值差距明顯，表明你們對該用戶故事的工做量、風險和不肯定性、複雜度沒有達成共識，估點高和估點低的人須要給他們一個機會闡述如此估點的理由。你們對該故事所包含的細節達成共識後，再對故事點數進行從新評估，直至你們對故事點數的評估基本達成一致。

若是對於同一個用戶故事，估算的故事點數可能不徹底一致，但點數之間差距不大，好比在3和5個故事點之間，該用戶故事的故事點能夠採用平均值法進行計算，計算方法是將估點的平均值與斐波那契數列相比較，並把與平均值差值較小的故事點做爲用戶故事的最終點數。

如在A故事的估算中，共有7人蔘與估算，其中4人估算的故事點數爲3，3人評估的故事點數爲5，則取平均值後的故事點數爲3.85，與斐波那契數列中的3和5比較，平均值與故事點3的差值更小，因此，該用戶故事的最終點數爲3，該用戶故事點數估算完成。

5.4 其餘

關於故事點估算還有不少小細節，我大概列一下個人見解，就不詳細展開了，各位讀者若是有更好的作法，歡迎留言指教：

1）在哪個會議上進行故事點估算？

若是需求梳理會出席的人數較多（達到團隊人數的2/3以上），就在梳理會上進行；若是人數較少的話就在計劃會前單獨召開一個簡短的估算會議進行估點。不建議在計劃會上估點。

2）估算完成後，能夠任意亮牌嗎？

不能夠，必須一塊兒亮牌，而且在估算過程當中，團隊成員之間也不能夠互相討論估算的點數。

3）PO和SM參與估算嗎？

不參與。只有開發團隊參與估點。注意是「開發團隊」，它包括了開發和測試人員，而不只僅是開發人員。

4）超過多少點數的用戶故事須要從新拆分？

每一個團隊的基準故事點規模不同，因此無法給個確切數字，可是建議剛組建的敏捷團隊最好不要超過5，後期能夠根據團隊的反饋進行調整。

5）實際開發中發現了估算失誤要不要修改點數？

不要。估算是爲了輔助咱們的工做安排，而不是用來管理員工的績效表現。爲了達到精準的估算而耗費過多的時間精力，這是本末倒置。並且就個人經驗來看，一個迭代中確實會有一些故事的點數被低估，可是也會有一些被高估的故事，因此就迭代總體來看，故事點不會波動太大。

6）很小的需求，也必需要團隊集體估算嗎？

要。估點是團隊對需求理解對齊的過程。若是需求真的很小，估點的過程也會很快達成一致的，不會耽誤你們多少時間。

7）規模化敏捷中的各個團隊如何統一估算基線？

首先從各個團隊召集一些骨幹成員（每一個團隊最好能有2-3名），組成一個跨職能的估算團隊；而後從整個產品待辦列表中隨機選擇10-20個故事進行基準故事點的定義和估算工做，估算的過程當中若是有人對相關的技術或需求不清晰，能夠放棄；最後，參與估算的人，將這10-20個估點後的故事帶回本身的團隊，並將基準故事和其餘故事的估點同步給團隊，以此對齊你們對工做量的認識。

參考資料

• 《敏捷革命》，Jeff Sutherland，中信出版集團。
• Why the fibonacci sequence works well for estimating，Mike Cohn。The main benefit of story points，Mike Cohn。
• What are story points，Mike Cohn。
• 韋伯定律，百度百科。
• 黃金比例分割，百度百科。
• 斐波那契數列，百度百科。
• 德爾菲法，百度百科。
• How to Estimate Story Points With Multiple Teams，Mike Cohn。

來源：小船哥說敏捷

做者：小船哥

4月每週四晚8點，【冬哥有話說】DevOps之庖丁解牛，拆解DevOps的工具及具體實戰。公衆號留言「解牛」可獲取地址

• 0401《數據庫持續交付流水線分享與演示（Azure DevOps+Flyway）》
• 0408《持續交付中的版本管理與基於Azure DevOps擴展框架的插件開發》
• 時間待定《微服務，多團隊協做中的API測試怎麼作 - Pact契約測試》
• 0422《BoatHouse端到端流水線展現》