敏捷式軟體開發 (Agile Software Development)實踐-Sprint Story Point Estimation

介紹：

對於story來說，一個很重要的衡量它的大小的因素就是story point,它不等同於軟體工作量評估中的Function Point,因為story point只是用來粗略的相對的估計story的大小，而Function Point則是用來衡量功能模組的精確大小並且要參與到公式計算的，這裡澄清下。

story point的估算是一門很深的學問，而且我們不能馬虎，因為如果我們估算少了，那麼就會導致實際我們的花費時間遠高於估算時間從而導致team加班加點，如果估多了，會導致我們team很閑，team productivity很低，從而會面臨削減resource的風險，因為這個很關鍵，所以我們估算必須要謹慎， 而且都必須讓一些很有經驗的人估算，比如在我們team,這件事情多數由我和一個最資深的前端工程師來共同完成。

實現方式：

其實估算story point要根據曆史資料，這些曆史資料來源於我們的過去的報表，我們跑了幾十個Sprint了，然後我們可以通過很典型的若干的sprint的比較，然後看那些sprint我們團隊的運行能力來粗略的估算出我們團隊能容忍的合理的story point的區間。

比如我們列出如下的曆史資料報表：

就拿最近5個sprint （S35-S39） 來說，我們可以比較 "Planned Story Point"和"Actual Total Effort" 2列。然後結合發生過的事情，有如下的證據：

(1)Sprint 39是一個非常糟糕的例子，因為在這個sprint我在休婚假，所以並沒有參與到Sprint Setup Meeting ,然後並沒有去估算story point，事後也沒時間去重新review, 所以整個團隊在一個預先估計的一個很亂的story point下工作，大家都累癱了。所以，雖然planned story point才22 ，但是實際上團隊一共貢獻了356.5小時去完成這些分配的story和sub-tasks,以至於最後3天我一看形勢不對，我自己都去參與開發寫代碼了，因為我的主要職責是領導team和技術方面的support,很少能逼我衝到一線去寫代碼的。最終雖然按時完成了，但是實在太累，我後來反思了下，這個sprint應該安排在40個story point才算合理。

(2)Sprint 35是另外一個極端的例子，這個sprint中，我們team接受了3個新成員，因為他們需要一定的上手期和獲得可以使用的帳號，許可權等，所以這個資料毫無參考價值。

(3)從縱觀Sprint 36,37,38，總的說來這3個sprint都是啟動並執行比較穩健的3個sprint,分別是276.2,276,269小時的總effort, 但是Sprint 36,team 非常忙，就算在code frozen day,我們還在做最後的bug fixing.而Sprint 37,我們有很高的品質，ST 只報告了1個defect, Sprint 38，雖然team 不緊不慢，但是我們是在最後一天才完成所有任務的。

所以綜上所述，我覺得對於我們的團隊來說，放22-26個story point是一個很合理的區間。

總結：

在估算Story Point時候，一定要參考曆史資料，曆史資料越多，那麼分配Story Point總量時給出的資料就更合理，否則無論算多或者算少，對於團隊都是不利的。

本文出自 “平行線的凝聚” 部落格，請務必保留此出處http://supercharles888.blog.51cto.com/609344/1261146