敏捷软件开发实践-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总量时给出的数据就更合理,否则无论算多或者算少,对于团队都是不利的。

你可能感兴趣的:(敏捷,agile)