敏捷開發中的故事點究竟是什麼？如何預估故事點？

故事點 是敏捷項目管理和開發中的一種抽象的度量單位，用於估計實現一個或多個用戶故事的複雜度，它是對工做量的一種描述方式。一個故事點就是一個數字，透過這個數字告訴整個團隊用戶故事的複雜度。複雜度包括功能的難易程度、風險和花多大的功夫。

故事點（story point）和預估時間（estimated）不同，故事點是一種相對的估計，它並不能和相似「人/天」這樣的單位畫等號，由於每一個人完成一樣複雜度的工做所需的時間是不一樣的。咱們舉個例子說明一下：

假設T團隊有A、B、C三位員工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能這樣對比的，這裏只是方便說明問題），T團隊約定10天爲一個迭代，如今他們想計劃一下將來的工做。若是按照預估時間的方式，一個用戶故事B君以爲須要1天，A君以爲0.5天就能夠，C君以爲須要2天，那麼他們最終定多少呢？

這裏可能出現兩種結果：

第一種結果，A君說這個我來作，寫0.5天吧！若是按照這個方式，那麼整個計劃會議就演變成分工會議，A君挑若干的用戶故事，本身進行估時，B君和C君也是如此，當每一個人的總估時都逼近10天的時候，那麼這個迭代的目標就肯定了。這是不少團隊實際採用的方式，看起來好像沒問題，可是長此以往，這種方式的弊端就會顯現出來。

1. 本身幹本身的，不關心全局的進展。既然每一個人本身的工做內容都已經肯定，那每一個人安排好本身的工做就能夠了，何須關心別人的工做呢？
2. 抗風險能力差。若是A君請假1天，須要C君花4天才能彌補。不只對C君的計劃影響巨大，也讓整個團隊的預估和實際相差甚遠。
3. 看不到團隊的真實速率。每當PO詢問某些用戶故事能不能安排到下個迭代時，一般獲得的答案是「這要看誰有沒有空」。
4. 不利於團隊成員的成長。C君很難有機會作一些複雜的，對本身能力有提高的工做，由於出於時間成本的考慮，複雜的工做都交給A君來處理。

固然，還有第二種可能，你們決定取箇中間值，但是中間值定多少纔算合理呢？預估的時間多就意味着總體完成的工做量變少，預估的時間少意味着完不成的機率會增大。

不一樣於預估時間，故事點關注的是複雜度，讓全部人對同一個用戶故事有相同的複雜度認知。爲了作到這一點，T團隊能夠找到一個基準的用戶故事（下文稱爲基準故事），基準故事不必定是最小的，可是必定能在T團隊中每一個人心中引發共鳴，而後T團隊將第一個基準故事定義爲1個故事點。

在估算一個新的用戶故事X時，全部人都須要思考，故事X比基準故事更花時間嗎？若是故事X的複雜度是基準故事的2倍，那麼很顯然，故事X的故事點應該爲2。須要注意的是，故事點的取值要遵循斐波那契數列（一、二、三、五、八、1三、2一、34… ），不過爲了方便記憶，在實際的操做中，不少團隊將21替換20，34替換成40等等。下圖是個人Scrum撲克牌。

這些紙牌表示的意思是：

1. 0表示喝口水的時間就能完成。
2. 其餘數字是根據和基準故事對比得出的結論。
3. ?表示複雜度未知，一般須要對用戶故事進行討論或者拆分。
4. 咖啡表示估算的過久，有點累了，須要休息一下。

原則上，一個好的敏捷團隊，不該該爲超過8個故事點的用戶故事估算，大於等於8個故事點的用戶故事應該被拆分爲更小的用戶故事。而隨着時間的推移，T團隊中會出現愈來愈多的基準故事，這些基準故事對應的故事點多是1，也多是2，也多是3。這使得全部人對於新用戶故事的估算愈來愈準確。

固然在實際的工做中，因爲每一個人實際狀況的不一樣，即便全部人都明白1個故事點意味着什麼，依然會爲一個用戶故事的故事點是2仍是5而產生爭論。有的人考慮的多，有的人考慮的少，有的知道一些近路，有的人一臉茫然。正確的步驟是這樣的：

1. 全部人先不要說出本身的故事點，而是將對應的紙盤扣在桌子上。
2. 當全部人的紙牌都扣在桌子上時，你們一塊兒翻開本身的卡牌。
3. 請估算差別最大的兩位成員討論，各自估算的緣由。
4. 全部人收回紙牌，重複步驟1-4。直到全部人的估算一致爲止。

使用這種方式的好處是顯而易見的，它能讓全部人對這個故事點有一個共識，這意味着，無論誰來完成這個用戶故事，那麼他是承認這個故事點的。並且它能夠有效的避免不假思索的跟風行爲，每一個人必須對用戶故事的複雜度進行思考，才能給出一個相對可靠的故事點，不然就要向全部人進行解釋。

使用這種方式也有它的弊端，那就是計劃會議很是耗時。在實踐中，有的團隊將估算的環節放在計劃會議以前，而有的團隊不借助撲克牌，而是直接經過全員討論得出一個相對正確的故事點。

T團隊對於用戶故事的估算是須要不斷的磨合的，同時還有一個須要不斷磨合的是團隊速度。A君B君C君已經在計劃會議中爲若干個用戶故事完成了估算，總故事點約爲40，那麼T團隊可以完成這個40個故事點嗎？實踐是檢驗猜想的惟一方式。

隨着幾個迭代的嘗試，T團隊發現30個故事點的工做量剛恰好，不緊也不慢，那麼T團隊的團隊速度即爲30個故事點/10天。

團隊速度的做用之一是，若是T團隊在一個迭代中規劃了總計爲30個故事點的用戶故事，無論每一個用戶故事是A君B君C君誰來作，理論上這些用戶故事T團隊都能按時完成。固然T團隊的速度不是一成不變的，下圖是我所在的團隊最近三個迭代的團隊速度。

（截圖來自Worktile Agile）

根據過去一段時間的團隊速度來規劃下一個迭代的工做規模，是很是科學的。

T團隊對本身團隊的能力有着清晰的認識，也對迭代的目標充滿着信心。另外，T團隊還能夠根據本身的團隊速度，在迭代中插入必定比例的非功能性需求。

除了團隊速度，使用故事點也能夠很是直觀的體現T團隊在一個迭代中的工做進展，下圖是我所在的團隊Sprint 10的燃盡圖。

（截圖來自Worktile Agile）

燃盡圖的趨勢能夠有效的體現T團隊目前是否失控，若是燃盡圖老是居高不下，全部人須要在站立會議中進行討論，共同發現、承擔並解決問題，這才能稱得上是一個團隊，不是嗎？

Worktile 官網：worktile.com

本文做者：孫敬雲

文章首發於「Worktile官方博客」，轉載請註明出處。