敏捷開發之如何進行故事點估算？
敏捷估算的價值
敏捷估算，就是在敏捷開發中，對即將開始的工作進行工作量、複雜度和持續時間的相對估算。通常情況下，軟體開發過程中有很多未知數：技術更新，需求變更，系統之間的依賴關係等，它們都會影響估算結果，所以說估算是一項費時費力的工作，並且得到的結果也是不精確的。既然如此，我們為什麼還需要進行敏捷估算呢？
- 估算和計劃是緊密相關的，估算結果是計劃的重要依據。決策者需要這個估算結果，來調整需求優先順序，進行資源安排，甚至砍掉這個功能。
- 對客戶來說，估算結果可以給出一個功能上線的預期更甚至於承諾，儘管這不是絕對準確的。
- 估算對團隊來說，給了團隊一個機會來提前討論需求，建立對需求一致的理解，消除疑問。
- 估算需要團隊深入研究還未開始工作，提前考慮將會涉及到的團隊合作甚至是跨團隊的合作，大大提升實際工作中的團隊效率。
估算的初衷雖然是得到完成功能時間的預期，但是我認為這項活動最重要的價值在於估算過程中對需求建立的深入理解，以及事先為實現功能的方法和策略做的全盤考慮。這一定會在接下來的實際工作中起到相當重要的作用，甚至決定了整個迭代能否完成目標。
為什麼使用故事點
估算是一件很困難的事，它同所有預測未來的事情一樣，結果往往都存在巨大的誤差。想要得到精確的預測結果，則需要花更多的時間來了解細節。而團隊進行估算所花時間的邊際效益必然是遞減的，因此花太多時間在估算上是相當不划算的。那我們該如何進行估算？
別忘了，人類的本質是什麼？不是說復讀機！
我的意思是，人類生來更擅長相對估算而不是絕對估算。因此，相對值的估算會更快和更容易理解。比如，我面前有兩棟樓，一棟的高度是另一棟的兩倍，我可以迅速判斷出來。但是我可能無法得出一棟樓是100米，另一棟是200米的結論。所以，在敏捷估算中，我們引入了故事點。
故事點是一個對工作量、複雜度或者持續時間進行估算的相對計量單位，最早在scrum和極限程式設計這一類的敏捷方法中開始使用。因為主要估算物件是使用者故事，所以被稱為故事點。
槓精本精有必要出來槓一下了，故事點不一樣是1個故事點，2個故事點的度量單位麼，怎麼就成相對估算了？
這是因為故事點的大小沒有標準。也就是說，每個團隊的故事點都是不一樣的。對一個團隊來說3個故事點的工作，可能對應了另一個團隊5個故事點的工作。用故事點進行估算，我們不會說這個功能需要100個小時來完成，而是說這個功能是8個故事點，工作量大概是4個故事點的某功能的兩倍。
故事點採用數字計數同時也帶來了一個問題，它會讓人自然的想追求精確，這和相對估算是衝突的。因此，我們建議採用斐波那契數列（0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144）來進行估算。因為當一個需求的估計值越大的時候，我們進行估算的結果誤差也越大。我們要避免去糾結這個需求到底是20個故事點還是21個故事點，這是沒有任何意義的。
估算的物件
由於估算需要我們同時做到儘量快速和準確，所以估算的物件選擇也是相當重要的。敏捷開發中，需求經常被分為史詩、特性和使用者故事三個等級，使用者故事下又能拆分成任務。這麼多型別，我們到底對誰進行估算？
首先，過大的工作量會導致估算結果誤差過大，導致史詩和特性不太適合故事點估算。其次，任務又太過細緻，對任務進行估算的話耗費時間。所以，按排除法我們還剩下使用者故事。（當然，根據實際情況，有時候我們也可以對特性或者對缺陷進行估算。）
如何進行估算
估算的結果是屬於團隊的，不屬於個人。首先，因為負責某個需求的人並不確定，所以整個需求是由團隊負責。其次，團隊決定的估算點數可能比個人估算更加合理。更重要的是，團隊一起估算時，團隊成員針對一個需求的討論和見解分享是整個團隊成長的契機。因此，比起個人估算，我們建議進行團隊估算，團隊中絕大部分成員參與估算是有必要的。
我們常用的團隊估算方法是撲克估算，具體操作流程如下:
- 每個團隊成員分發一套寫著0、0.5、1、2、3、5、8、13、20、40、∞、？的卡片。
- 產品負責人負責講解需求待辦列表挑選出來的需求，團隊成員提出自己的疑問，產品負責人一一解答。
- 團隊成員進行估算，選出自己估算結果對應的卡片蓋在桌上，不要告知其他團隊成員。
- 所有人都確認自己的估算結果後，大家一起翻開卡片，展示自己的估算結果。
- 團隊評估估算結果，讓給出估算點數最大和最小的成員分別陳述自己給出當前結果的理由，團隊討論，消除分歧，得到一致的結果。（這一步尤為重要，討論過程是團隊分享知識和經驗絕佳機會。）
- 選擇下一個故事，重複第2步。
不過，既然到了鬥地主都必須是線上活動的9012年了，撲克估算這種小事當然不再需要人手一副紙質卡片。
一、線上建立房間，新增估算需求，支援多種打分方式（撲克估算、T恤估算）。
二、成員快速打分，標記最高最低分，支援多種得分計算方式（算術平均數、切尾平均數、中位數、眾數、自定義）。
三、記錄最終結果，隨時回顧。
這麼好用的寶貝哪裡找？掃一掃下圖二維碼就可以啦！
“劃重點”
- 故事點對於不同團隊有著不同的定義。所以故事點不能作為評估團隊績效的標準！同時也要避免估算時點數膨脹，給出真實的估算結果。
- 估算的時候保證參與成員都對估算物件有足夠的瞭解，有疑問的地方一定要提出並得到產品負責人的解釋。
- 不要過度關注故事點的絕對大小。保證3個故事點的需求比2個故事點大，比4個故事點小就夠了。
- 團隊有必要始終堅持統一的故事點標準。
- 請使用上面的小程式進行敏捷估算。
本文作者：Worktile 產品經理 彭東鍇
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出