75年生人,程序员,在西安。

如何理解Story points?

今天看到几篇不错的英文Blog,关于如何理解Story points,这个Scrum中的概念,现分享如下:

总的理解如下:

Story points 是为了让客户或老板预估什么功能什么时间大概会发布。因此它肯定是与时间有关的,也与最后的工作成果有关的,但这个单位不能简单理解成其中任何一个单项,如时间(人天)或复杂度、难度等。

其中Story Points Are Still About Effort 这篇文章中用“到达某个地方”这一目标事件举了一个很好的例子,不同的人要到达这个地方可能用的时间不同,如甲用1小时,而乙用3小时,路途是一样的,这时我们请甲和乙都把“到达这个地方”理解为1个Story point,那么下次在预估另一个目标点时,他们就都可以参考这个预估。

比如另一个目标,甲感觉需要2小时走到,而乙可能感觉需要5小时,这时甲的预估差不多就是2个Story point,而乙也感觉差不多要2个Story point,这样大家就可以有一个“相对的单位”,而不是用时间这个“绝对的单位”来讨论了。

另外,还要考虑与最后的工作成果有关的因素,在上面走路的例子中,大家可能很自然想到用“距离”来评估工作成果,但现实世界中还要考虑很多其他因素,比如道路的难易程度,同样距离的目标,可能一个很好走,因此用时就少,而另一个可能路难走、拥堵等,因此用时就多,那么前一个也许Story point在预估时给了2,但后一个可能就要考虑风险因素,预估为3或4了。文中的例子是说在路途中有几个火车道,有可能会等待火车通过等。

同时,Story point 却不是衡量复杂度的单位,比如文中举了例子说到达同一个目标,是普通走过去,还是边走边唱江南Style过去,复杂度是不一样的,但这个因素就不应该放在Story point中来考虑,因为唱着过去和普通走过去用的时间不会差太多的情况下,它们在Story point来说是一样的。

这样在一个Sprint阶段中,一个Team团队所能完成的工作成果,基本会有一个预估,如一个Sprint(一个月)该Team,甲能做10个Story point,乙能做6个Story point,丙能做9个Story point……,最终整个Team能做的Story point大概就是40个,而这样将Backlog(任务堆)中相应Story point大小的功能需求放进来,就八九不离十了,也就基本是可预估的了,这样老板、客户心里就有底了,开发人员们也基本可以保证按时发布,皆大欢喜啦!

最后,还是回归到Agile的本质,Story point不期望精确衡量软件开发中的工作量,仅仅是用来预估个大概,八九不离十就可以了,软件开发的管理中对于这方面请不要太较真,特别是不要用这个来作为开发人员绩效的衡量,实际上最好不要有任何的绩效衡量,这需要另文再述。

这里只是解释了一下为什么不用时间、人天(时)或复杂度、难度、代码行等绝对精确的单位来预估,而是采用了这样一个大家感觉上较易统一,但又不很精确,模模糊糊的一个相对单位来预估的原由和理念,希望大家能“大概”明白了,哈哈……

评论

© 世风十三 | Powered by LOFTER