敏捷軟件開發(fā)實(shí)踐-Sprint Story Point Estimation

介紹：

對于story來說，一個很重要的衡量它的大小的因素就是story point,它不等同于軟件工作量評估中的Function Point,因?yàn)閟tory point只是用來粗略的相對的估計(jì)story的大小，而Function Point則是用來衡量功能模塊的精確大小并且要參與到公式計(jì)算的，這里澄清下。

story point的估算是一門很深的學(xué)問，而且我們不能馬虎，因?yàn)槿绻覀児浪闵倭?，那么就會?dǎo)致實(shí)際我們的花費(fèi)時間遠(yuǎn)高于估算時間從而導(dǎo)致team加班加點(diǎn)，如果估多了，會導(dǎo)致我們team很閑，team productivity很低，從而會面臨削減resource的風(fēng)險(xiǎn)，因?yàn)檫@個很關(guān)鍵，所以我們估算必須要慎重， 而且都必須讓一些很有經(jīng)驗(yàn)的人估算，比如在我們team,這件事情多數(shù)由我和一個最資深的前端工程師來共同完成。

實(shí)現(xiàn)方式：

其實(shí)估算story point要根據(jù)歷史數(shù)據(jù)，這些歷史數(shù)據(jù)來源于我們的過去的報(bào)表，我們跑了幾十個Sprint了，然后我們可以通過很典型的若干的sprint的比較，然后看那些sprint我們團(tuán)隊(duì)的運(yùn)行能力來粗略的估算出我們團(tuán)隊(duì)能容忍的合理的story point的區(qū)間。

比如我們列出如下的歷史數(shù)據(jù)報(bào)表：

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

(1)Sprint 39是一個非常糟糕的例子，因?yàn)樵谶@個sprint我在休婚假，所以并沒有參與到Sprint Setup Meeting ,然后并沒有去估算story point，事后也沒時間去重新review, 所以整個團(tuán)隊(duì)在一個預(yù)先估計(jì)的一個很亂的story point下工作，大家都累癱了。所以，雖然planned story point才22 ，但是實(shí)際上團(tuán)隊(duì)一共貢獻(xiàn)了356.5小時去完成這些分配的story和sub-tasks,以至于最后3天我一看形勢不對，我自己都去參與開發(fā)寫代碼了，因?yàn)槲业闹饕氊?zé)是領(lǐng)導(dǎo)team和技術(shù)方面的support,很少能逼我沖到一線去寫代碼的。最終雖然按時完成了，但是實(shí)在太累，我后來反思了下，這個sprint應(yīng)該安排在40個story point才算合理。

(2)Sprint 35是另外一個極端的例子，這個sprint中，我們team接受了3個新成員，因?yàn)樗麄冃枰欢ǖ纳鲜制诤瞳@得可以使用的賬號，權(quán)限等，所以這個數(shù)據(jù)毫無參考價值。

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

所以綜上所述，我覺得對于我們的團(tuán)隊(duì)來說，放22-26個story point是一個很合理的區(qū)間。

總結(jié)：

在估算Story Point時候，一定要參考?xì)v史數(shù)據(jù)，歷史數(shù)據(jù)越多，那么分配Story Point總量時給出的數(shù)據(jù)就更合理，否則無論算多或者算少，對于團(tuán)隊(duì)都是不利的。