在估算用戶故事點數(shù)的時候，你有沒有遇到跟我一樣的疑問：

• 用戶故事的工作量為什么要用故事點估算，而不是時間（比如人天）？
• 故事點估算為什么要用斐波那契數(shù)列？
• 斐波那契數(shù)列的數(shù)字為什么被改了？
• 為什么要用估算撲克？
• 為什么要有基準故事？
• 怎樣確定基準故事？
• 其他故事怎樣與基準故事做相對估算？
• ……

本文將為你一一解決上述問題。全文大概5000字，預計閱讀時間15分鐘，如果你也有類似困惑，可以花點時間閱讀下，相信不會讓你失望的。

1. 為什么使用故事點而不是時間

在回答這個問題之前，先看個例子：

韓梅梅喜歡跑步，但是她跑得很慢，而李雷卻跑得很快。李雷指著北京奧林匹克森林公園對韓梅梅說：我們跑南園這條路吧，這大概要花30分鐘。

這條路韓梅梅很熟，但是作為一個跑步很慢的人，韓梅梅心里清楚這要花60分鐘。所以，韓梅梅告訴李雷，她跑過這條路的，需要花60分鐘。

然后他們就爭執(zhí)起來了：30-60-30-60……

他們爭執(zhí)半天沒有結(jié)果。也許他們可以妥協(xié)一下，需要45分鐘？但是這也許是最壞的結(jié)果，因為他們雖然有了一個折中結(jié)果，但是，這個結(jié)果對大家都沒不太實際：李雷覺得太慢了，而韓梅梅覺得太快了。

所以，他們繼續(xù)爭論：30-60-30-60……

最終，李雷跟韓梅梅說：這段路大概5公里，我能在30分鐘內(nèi)跑完它。

韓梅梅說：我同意這段路程是5公里，但它要花我60分鐘。

他們兩個都是對的：李雷真的能在30分鐘內(nèi)跑完，韓梅梅也真的需要60分鐘。但當他們想為這段路程統(tǒng)一時間估算時，他們發(fā)現(xiàn)做不到，因為大家工作（跑步）的速率不同。

但是，當他們使用了一個抽象的度量單位（公里），他們就達成了一致。李雷和韓梅梅都同意這段路程是5公里，他們僅僅在要花費多長時間上意見不同。

例子說完了，相信大家已經(jīng)對時間和公里（抽象度量單位）有了一點理解。

敏捷開發(fā)中的“故事點”跟例子中的“公里”作用差不多：它能使不同技術(shù)水平和工作速度的人在估算結(jié)果上保持一致。當然，敏捷開發(fā)中的主角是具有不同產(chǎn)出效率的程序員，而不是例子中跑得快的人和跑得慢的人。

就像這兩個跑步的人，兩個程序員也許同意一個用戶故事是5個故事點（類比例子中的5公里，都是一種抽象度量單位）。資深程序員可能覺得這很容易，1天（時間）就能完成。初級程序員可能覺得需要2天才能搞定。但是他們能在5個故事點上達成一致，因為把第一個用戶故事定成5個故事點是不需要什么依據(jù)的。

不過，最重要的是，一旦他們同意第一個故事是5個點，這兩個程序員就可以對后續(xù)估算達成共識。如果資深程序員認為一個新的用戶故事將需要兩天（兩倍于他估計為5個點的故事），他將評估新的故事為10個點。而初級程序員也會這樣做，當他需要4個工作日（兩倍于他估計為5個點的故事），他將評估新的故事為10個點。

所以，使用故事點而不使用時間的原因是，故事點可以使能力不同的程序員在估算同一任務時快速達成一致。

2. 為什么要使用斐波那契數(shù)列估算故事點

2.1. 人們只能識別一定百分比外的差異

德國生理學家E.H.韋伯通過對重量差別感覺的研究發(fā)現(xiàn)一條定律，即感覺的差別閾限隨原來刺激量的變化而變化，而且表現(xiàn)為一定的規(guī)律性，刺激的增量(△I)和原來刺激值(I)的比是一個常數(shù)(K)，用公式表達即K=△I/I，這個常數(shù)叫韋伯常數(shù)、韋伯分數(shù)或韋伯比率。

上面的定義是從百度百科拷貝下來的，簡單來說就是：我們只能識別出兩個物體間一定百分比外的差異。

比如：一公斤和兩公斤之間的差別是100％，但是20公斤和21公斤之間的差異僅為5％。所以您可能可以區(qū)分1公斤和2公斤的物品，但您可能無法分辨出20公斤和21公斤的物品，因為20公斤和21公斤兩者之間的百分比差異太小了。

這就是韋伯定律想要告訴我們的：差異太小，我們是識別不到的；只有差異大到一定程度，才能被我們識別。

2.2. 人們可以識別到多大差異的區(qū)別

韋伯定律只是告訴了我們可以識別一定百分比差異外的區(qū)別，但是這個百分比是多少呢？

自然界有個神奇的數(shù)字：0.618，即黃金分割比例。

黃金分割比例的現(xiàn)象在我們身邊有很多，比如：

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

甚至在醫(yī)學領(lǐng)域，當一個患者報告說自己感受到了病情的好轉(zhuǎn)，那么實際上他的病已經(jīng)好了65%。

也就是說，61.8%這個百分比差異對很多人來說，是可以輕易分辨出來的。

2.3. 為什么使用斐波那契數(shù)列估算故事點

斐波那契數(shù)列之所以能很好的用于故事點的估算，是因為它們大致符合了黃金分割點。在這個數(shù)列中，1、2、3、5、8、13、21……，前兩個值之后（后一個值比前一個值大100％），后面的每個數(shù)字都比前一個數(shù)字值大60％左右。

根據(jù)韋伯定律，如果我們可以區(qū)分兩個工作量相差60％的故事，則可以區(qū)分其他相同百分比差異的故事。

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

3. 如何降低Scrum團隊中的從眾效應

3.1. 什么是從眾效應

在估算故事點時，當有人提出一個估算，即使你不同意，但當別人都表達贊同時，你還是會隨聲附和，這就是所謂的“從眾效應”：人們認為如果其他人都贊同某一件事時，那么自己的保留意見則是愚蠢的或是誤導性的，他們不想在其他人面前出丑。

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

與“從眾效應”相關(guān)的概念還有信息瀑布和光環(huán)效應：

• 信息瀑布
  一篇叫做《A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades》的論文中首先提到了這個概念：如果一個人觀察到之前眾人的行為后，認為最佳的做法是放棄自己掌握的信息，遵從之前眾人的行為，那么這個時候信息瀑布就出現(xiàn)了。
• 光環(huán)效應
  當認知者對一個人的某種特征形成好或壞的印象后，還傾向于推論該人其他方面的特征，本質(zhì)上屬于以偏概全的認知錯誤。與從眾效應一樣，光環(huán)效應也會導致人們將目光集中到某一個有正面色彩的光環(huán)上，從而忽視了實際數(shù)據(jù)。

3.2. 使用“德爾菲法”降低從眾效應的影響

德爾菲法，也稱專家調(diào)查法，1946 年由美國蘭德公司創(chuàng)始實行，其本質(zhì)上是一種反饋匿名函詢法，其大致流程是在對所要預測的問題征得專家的意見之后，進行整理、歸納、統(tǒng)計，再匿名反饋給各專家，再次征求意見，再集中，再反饋，直至得到一致的意見。

蘭德公司使用這個方法做過一個匿名投票，投票的主題是“冷戰(zhàn)期間，如果蘇聯(lián)要摧毀美國的主要工業(yè)目標，需要多少枚原子彈？”。

他們找來了一群專家，包括4名經(jīng)濟學家、1名物理脆弱性方面的專家、1名系統(tǒng)分析師及1名電氣工程師。這幾個人都是各個領(lǐng)域的專家，但是第一輪投票的結(jié)果差別非常大，少則50枚，多則5000枚。

在第一輪投票后，組織方將各個專家的意見整合后發(fā)給了大家，比如各個目標的脆弱性、各個行業(yè)的恢復能力、工廠的安全性、不同零部件的交付周期、打擊目標的準確性等等，然后又組織各位專家進行了第二次投票，評估差異縮小到了89~800之間。

反復開展上述過程，最終差異越來越小，最后落在了167~360之間。

最初的評估結(jié)果相差100倍，到最后，縮小到了2倍。借助這一工具，既能讓專家達成普遍的共識，又不會擔心出現(xiàn)什么偏見。

敏捷開發(fā)中也是使用該方法對用戶故事進行估點的，具體方法會在第5章中介紹。

4. 為什么敏捷估算要使用修正后的斐波那契數(shù)列

標準的斐波那契數(shù)列是1、2、3、5、8、13、21、34、55……，但是目前絕大多數(shù)團隊敏捷估算時使用的斐波那契數(shù)列是1、2、3、5、8、13、20、40、100……，數(shù)列的前面6個數(shù)字是一樣的，但是從第7個數(shù)字開始，就完全不一樣了，這是為什么呢？

Mike Cohn在他的Why the fibonacci sequence works well for estimating一文中提到，早期他都是根據(jù)真實的斐波那契數(shù)列進行的估算（1、2、3、5、8、13、21、34、55……）。

這個數(shù)列越往后數(shù)字越大，也就說明估算越不準確，所以對于21、34、55這樣的估算值，很多人都覺得很奇怪：既然已經(jīng)估不準了，為什么非要使用21，而不將其四舍五入為20或25呢？

于是Mike Cohn就接受了這個建議，他在之后的團隊輔導及授課中就都開始使用20而不是21了，并且一直持續(xù)到了現(xiàn)在。

后來他又嘗試使用了40和100這兩個數(shù)代替了數(shù)列的其他值，之所以這么使用，是因為任務的粒度越粗，估算就越不準確，也就越不需要糾結(jié)到底是80、90還是100了。

同時，使用40和100也是不違反韋伯定律的，它們分別比之前的數(shù)字增加了100％（20 →40）和150％（40 →100）。這比黃金分割比例的61.8％大得多，人們是可以輕松的分辨出這些工作量的區(qū)別的。

于是在Mike Cohn的影響下，現(xiàn)在大部分公司在敏捷估算中都是使用的修正后的斐波那契數(shù)列：1、2、3、5、8、13、20、40、100、∞。

5. 如何估算故事點

5.1. 確定基準故事點

每次估算時，最好使用相同的標準用戶故事作為1個點，這樣對于整個項目的統(tǒng)計有很大幫助。使用相對值進行估算，可以有效的統(tǒng)計團隊的生產(chǎn)能力在各個迭代的變化。

對于初次實施敏捷的團隊，對故事點的評估可能還是不太容易理解，根據(jù)我的實踐經(jīng)驗，初次評估故事點時，可以嘗試使用1人天的工作量作為一個故事點。如果團隊成員的水平參差不齊的話，那就建議用其中一個中等水平的研發(fā)作參考，使用他的1人天的研發(fā)產(chǎn)出作為1故事點的參考。

5.2. 相對估算的依據(jù)

基準故事點確定好以后，其他的故事怎樣與它對比呢？怎樣確定另一個故事的工作量是基準故事的幾倍呢？我們可以從以下3個因素考慮：

1. 要開展的工作數(shù)量（The Amount of Work）
   如果要開展的工作越多，工作量的估算值當然就會越大?？紤]兩個網(wǎng)頁開發(fā)的案例。第一個網(wǎng)頁只有一個字段和一個要求輸入姓名的標簽。第二個網(wǎng)頁有100個只需要輸入一小段文本的字段。
   第二個網(wǎng)頁并不比第一個網(wǎng)友更復雜。字段之間是不存在交互的，每個字段只不過是一點文本而已。因此第二個網(wǎng)頁并不存在額外的風險。這兩網(wǎng)頁之間的唯一區(qū)別就是第二頁有更多的事情要做。
   應該給予第二個網(wǎng)頁更多的故事點數(shù)。但它即使有多了100倍的字段數(shù)，可能仍然得不到多100倍的點數(shù)。畢竟，由于規(guī)模經(jīng)濟效應，第二個網(wǎng)頁的工作量可能只是第一個網(wǎng)頁的工作量的2或3或10倍。
2. 風險和不確定性（Risk and Uncertainty）
   產(chǎn)品待辦項的風險和不確定性會影響其故事點估算值。
   如果產(chǎn)品待辦項的干系人在詢問需求時說得不清不楚，那么團隊在估算時應當把不確定性也反映在估算結(jié)果中。
   如果要實現(xiàn)一項功能時需要改動一段缺乏自動化測試、結(jié)構(gòu)脆弱的老代碼，那么估算結(jié)果中也應該反映這個風險。
3. 復雜度（Complexity）
   在進行故事點估算時，還應該考慮復雜度?；仡櫼幌轮澳莻€有100個瑣碎文本字段且字段之間無交互的Web網(wǎng)頁開發(fā)的例子。
   現(xiàn)在考慮另一個也有100個字段的網(wǎng)頁。但這些字段中，有些是采用日歷控件彈出的日期字段；有些是格式化的文本字段，如電話號碼或社會安全號碼；另一些字段則需要做信用卡號碼的校驗和驗證。
   頁面上的字段之間還需要相互交互。如果用戶輸入一個VISA卡，會顯示三位CVV字段。但是如果用戶輸入美國運通卡，則需要顯示四位CVV字段。
   盡管這個頁面上仍然只有100個字段，但這些字段更難實現(xiàn)。它們更復雜，需要花更多時間才能實現(xiàn)。開發(fā)人員出錯的可能性更大，因此不得不采取一些預防和糾正措施。
   這種額外的復雜度都應該反映在所提供的估算結(jié)果中。

5.3. 使用規(guī)劃撲克集體估點

規(guī)劃撲克

在3.2節(jié)介紹了怎樣使用“德爾菲法”降低從眾效應的影響，在敏捷開發(fā)中，我們可以借助規(guī)劃撲克來進行匿名投票。在估算會議上，團隊中的每位人員都會得到一副紙質(zhì)撲克，當然，隨著移動互聯(lián)網(wǎng)的普及，目前大多數(shù)敏捷團隊使用了更為便捷的電子撲克。這里有2張撲克的含義需要解釋下：

1. 如果有人出了“??”這個撲克，說明需要休息一會了；
2. 如果有人出了“？”這個撲克，說明他不了解需求，無法估算工作量，PO需要嘗試重新澄清需求。

同3.2節(jié)介紹的案例一樣，我們在規(guī)劃故事點數(shù)時，第一輪大家的估點可能也會有很大的差距。如果估算值差距明顯，代表大家對該用戶故事的工作量、風險和不確定性、復雜度沒有獲得共識，估點高和估點低的人需要給他們一個機會闡述如此估點的理由。大家對該故事所包含的細節(jié)達成共識后，再對故事點數(shù)進行重新評估，直至大家對故事點數(shù)的評估基本達成一致。

如果對于同一個用戶故事的評估中，可能評估的故事點數(shù)不完全一致，但點數(shù)之間差距不大，比如在3和5個故事點之間，該用戶故事評估故事點數(shù)可以采用平均值法進行計算，將平均值結(jié)果與斐波那契數(shù)列比較，并把與評估故事點差值較小的故事點數(shù)作為用戶故事的最終點數(shù)。

如在A故事的評估中，共有7人參與評估，其中4人評估的故事點數(shù)為3，3人評估的故事點數(shù)為5，則取平均值后的故事點數(shù)為3.85，與斐波那契數(shù)列中的3和5比較，平均值與故事點3差值更小，所以，該用戶故事的最終點數(shù)為3，該用戶故事點數(shù)評估完成。

5.4. 其他

關(guān)于故事點估算還有很多小細節(jié)，我大概列一下我的看法，就不詳細展開了，各位看官如果有更好的做法，歡迎留言指教：

• 在哪一個會議上進行故事點估算？
  如果有梳理會，就在梳理會進行；如果沒有的話就在計劃會上進行。
• 估算完成后，可以任意亮牌嗎？
  不可以，必須一起亮牌，并且在估算過程中，團隊成員之間也不可以互相討論預估的點數(shù)。
• PO和SM參與估算嗎？
  不參與。只有開發(fā)團隊參與估點，注意是開發(fā)團隊，包括研發(fā)和測試人員。
• 超過多少點數(shù)用戶故事需要重新拆分？
  每個團隊的基準故事點規(guī)模不一樣，所以沒法給個確切數(shù)字，但是建議剛組建的敏捷團隊最好不要超過5，后期可以根據(jù)團隊的反饋進行調(diào)整。
• 實際開發(fā)中發(fā)現(xiàn)了估算失誤要不要修改點數(shù)？
  不要。估算是為了輔助我們的工作安排，而不是用來管理員工的績效表現(xiàn)。為了達到精準的估算而耗費過多的時間精力，這是本末倒置。而且就我的經(jīng)驗來看，一個迭代中確實會有些故事被低估，但是也會有一些高估的故事，所以就迭代整體來看，故事點不會波動太多。
• 很小的需求，也必須要團隊集體估算嗎？
  要。估點是團隊對需求理解對齊的過程。如果需求真的很小，估點的過程也會很快達成一致的，不會耽誤大家多少時間。

參考資料

1. 《敏捷革命》，Jeff Sutherland，中信出版集團。
2. Why the fibonacci sequence works well for estimating，Mike Cohn。
3. The main benefit of story points，Mike Cohn。
4. What are story points，Mike Cohn。
5. 韋伯定律，百度百科。
6. 黃金比例分割，百度百科。
7. 斐波那契數(shù)列，百度百科。
8. 德爾菲法，百度百科。