敏捷軟件開發實踐-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總量時給出的數據就更合理，否則無論算多或者算少，對于團隊都是不利的。