成都创新互联网站制作重庆分公司

敏捷软件开发实践-SprintStoryPointEstimation-创新互联

介绍:

网站制作、网站建设的开发,更需要了解用户,从用户角度来建设网站,获得较好的用户体验。创新互联多年互联网经验,见的多,沟通容易、能帮助客户提出的运营建议。作为成都一家网络公司,打造的就是网站建设产品直销的概念。选择创新互联,不只是建站,我们把建站作为产品,不断的更新、完善,让每位来访用户感受到浩方产品的价值服务。

对于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的区间。

比如我们列出如下的历史数据报表:

敏捷软件开发实践-Sprint Story Point Estimation

就拿最近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总量时给出的数据就更合理,否则无论算多或者算少,对于团队都是不利的。


当前标题:敏捷软件开发实践-SprintStoryPointEstimation-创新互联
分享地址:http://cxhlcq.com/article/ieigi.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部