故事點 是敏捷專案管理和開發中的一種抽象的度量單位，用於估計實現乙個或多個使用者故事的複雜度，它是對工作量的一種描述方式。乙個故事點就是乙個數字，透過這個數字告訴整個團隊使用者故事的複雜度。複雜度包括功能的難易程度、風險和花多大的功夫。
故事點（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天的時候，那麼這個迭代的目標就確定了。這是很多團隊實際採用的方式，看起來好像沒問題，但是久而久之，這種方式的弊端就會顯現出來。
自己幹自己的，不關心全域性的進展。既然每個人自己的工作內容都已經確定，那每個人安排好自己的工作就可以了，何必關心別人的工作呢？
抗風險能力差。如果a君請假1天，需要c君花4天才能彌補。不僅對c君的計畫影響巨大，也讓整個團隊的預估和實際相差甚遠。
看不到團隊的真實速率。每當po詢問某些使用者故事能不能安排到下個迭代時，通常得到的答案是「這要看誰有沒有空」。
不利於團隊成員的成長。c君很難有機會做一些複雜的，對自己能力有提公升的工作，因為出於時間成本的考慮，複雜的工作都交給a君來處理。
當然，還有第二種可能，大家決定取個中間值，可是中間值定多少才算合理呢？預估的時間多就意味著整體完成的工作量變少，預估的時間少意味著完不成的概率會增大。
不同於預估時間，故事點關注的是複雜度，讓所有人對同乙個使用者故事有相同的複雜度認知。為了做到這一點，t團隊可以找到乙個基準的使用者故事（下文稱為基準故事），基準故事不一定是最小的，但是一定能在t團隊中每個人心中引起共鳴，然後t團隊將第乙個基準故事定義為1個故事點。
在估算乙個新的使用者故事x時，所有人都需要思考，故事x比基準故事更花時間嗎？如果故事x的複雜度是基準故事的2倍，那麼很顯然，故事x的故事點應該為2。需要注意的是，故事點的取值要遵循斐波那契數列（1、2、3、5、8、13、21、34… ），不過為了方便記憶，在實際的操作中，很多團隊將21替換20，34替換成40等等。下圖是我的scrum撲克牌。
這些紙牌表示的意思是：
0表示喝口水的時間就能完成。
其他數字是根據和基準故事對比得出的結論。
?表示複雜度未知，通常需要對使用者故事進行討論或者拆分。
咖啡表示估算的太久，有點累了，需要休息一下。
原則上，乙個好的敏捷團隊，不應該為超過8個故事點的使用者故事估算，大於等於8個故事點的使用者故事應該被拆分為更小的使用者故事。而隨著時間的推移，t團隊中會出現越來越多的基準故事，這些基準故事對應的故事點可能是1，也可能是2，也可能是3。這使得所有人對於新使用者故事的估算越來越準確。
當然在實際的工作中，由於每個人實際情況的不同，即使所有人都明白1個故事點意味著什麼，依然會為乙個使用者故事的故事點是2還是5而產生爭論。有的人考慮的多，有的人考慮的少，有的知道一些近路，有的人一臉茫然。正確的步驟是這樣的：
所有人先不要說出自己的故事點，而是將對應的紙盤扣在桌子上。
當所有人的紙牌都扣在桌子上時，大家一起翻開自己的卡牌。
請估算差異最大的兩位成員討論，各自估算的原因。
所有人收回紙牌，重複步驟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
敏捷到底是什麼？
文 ivar jacobson 在支援軟體工程 比如rational統一過程rup 與敏捷陣營 比如scrum或是xp 之間，人們一直存在著衝突。也不難理解，因為這兩種方法間都是在用著彼此並不相容的方式來描述的。其實大可不必，因為他們背後的觀點全然是相輔相成的。關鍵在於該如何用對兩者來說都公平的方式...
敏捷到底是什麼
我想每個人都有乙個自己的定義 很多人都認為敏捷就是tdd 我就曾經這麼認為，這難道錯了嗎?沒錯，但是這不是敏捷的不夠全部 不是敏捷的核心 那麼敏捷到底是什麼呢？敏捷是關於3件事情的 1.敏捷是一門社會學科 這是最衝要的，也是敏捷的最大特點所在。他關注的是人 而不是 如何讓乙個讓大家像乙個團隊一樣，怎...
敏捷心態到底是什麼？
如果，有這麼一名高管，他並不了解什麼對於敏捷來說最重要，當這位高管在公司酒會上請你回答具有 敏捷心態 意味著什麼時，你能在他喝光杯中酒走開之前做出足夠清晰的回答粘住他嗎，甚至讓他端起第二杯？你應該講什麼內容，如何一針見血地指出培養心態的必要性？我向自己發起了挑戰，試著進行了總結，在此分享一下我的經歷...