敏捷开发

敏捷开发中的故事点到底是什么?如何预估故事点?


故事点 是敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式。一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。

故事点(story point)和预估时间(estimated)不一样,故事点是一种相对的估计,它并不能和类似“人/天”这样的单位画等号,因为每个人完成同样复杂度的工作所需的时间是不同的。我们举个例子说明一下:

假设T团队有A、B、C三位员工,A君的能力是B君的2倍,B君的能力是C君的2倍(能力是不能这样对比的,这里只是方便说明问题),T团队约定10天为一个迭代,现在他们想计划一下未来的工作。如果按照预估时间的方式,一个用户故事B君觉得需要1天,A君觉得0.5天就可以,C君觉得需要2天,那么他们最终定多少呢?

image.png

这里可能出现两种结果:

第一种结果,A君说这个我来做,写0.5天吧!如果按照这个方式,那么整个计划会议就演变成分工会议,A君挑若干的用户故事,自己进行估时,B君和C君也是如此,当每个人的总估时都逼近10天的时候,那么这个迭代的目标就确定了。这是很多团队实际采用的方式,看起来好像没问题,但是久而久之,这种方式的弊端就会显现出来。

  1. 自己干自己的,不关心全局的进展。既然每个人自己的工作内容都已经确定,那每个人安排好自己的工作就可以了,何必关心别人的工作呢?

  2. 抗风险能力差。如果A君请假1天,需要C君花4天才能弥补。不仅对C君的计划影响巨大,也让整个团队的预估和实际相差甚远。

  3. 看不到团队的真实速率。每当PO询问某些用户故事能不能安排到下个迭代时,通常得到的答案是“这要看谁有没有空”。

  4. 不利于团队成员的成长。C君很难有机会做一些复杂的,对自己能力有提升的工作,因为出于时间成本的考虑,复杂的工作都交给A君来处理。

当然,还有第二种可能,大家决定取个中间值,可是中间值定多少才算合理呢?预估的时间多就意味着整体完成的工作量变少,预估的时间少意味着完不成的概率会增大。

不同于预估时间,故事点关注的是复杂度,让所有人对同一个用户故事有相同的复杂度认知。为了做到这一点,T团队可以找到一个基准的用户故事(下文称为基准故事),基准故事不一定是最小的,但是一定能在T团队中每个人心中引起共鸣,然后T团队将第一个基准故事定义为1个故事点。

image.png

在估算一个新的用户故事X时,所有人都需要思考,故事X比基准故事更花时间吗?如果故事X的复杂度是基准故事的2倍,那么很显然,故事X的故事点应该为2。需要注意的是,故事点的取值要遵循斐波那契数列(1、2、3、5、8、13、21、34… ),不过为了方便记忆,在实际的操作中,很多团队将21替换20,34替换成40等等。下图是我的Scrum扑克牌。

image.png

这些纸牌表示的意思是:

  1. 0表示喝口水的时间就能完成。

  2. 其他数字是根据和基准故事对比得出的结论。

  3. ?表示复杂度未知,通常需要对用户故事进行讨论或者拆分。

  4. 咖啡表示估算的太久,有点累了,需要休息一下。

原则上,一个好的敏捷团队,不应该为超过8个故事点的用户故事估算,大于等于8个故事点的用户故事应该被拆分为更小的用户故事。而随着时间的推移,T团队中会出现越来越多的基准故事,这些基准故事对应的故事点可能是1,也可能是2,也可能是3。这使得所有人对于新用户故事的估算越来越准确。

当然在实际的工作中,由于每个人实际情况的不同,即使所有人都明白1个故事点意味着什么,依然会为一个用户故事的故事点是2还是5而产生争论。有的人考虑的多,有的人考虑的少,有的知道一些近路,有的人一脸茫然。正确的步骤是这样的:

  1. 所有人先不要说出自己的故事点,而是将对应的纸盘扣在桌子上。

  2. 当所有人的纸牌都扣在桌子上时,大家一起翻开自己的卡牌。

  3. 请估算差异最大的两位成员讨论,各自估算的原因。

  4. 所有人收回纸牌,重复步骤1-4。直到所有人的估算一致为止。

使用这种方式的好处是显而易见的,它能让所有人对这个故事点有一个共识,这意味着,不管谁来完成这个用户故事,那么他是认可这个故事点的。而且它可以有效的避免不假思索的跟风行为,每个人必须对用户故事的复杂度进行思考,才能给出一个相对可靠的故事点,否则就要向所有人进行解释。

使用这种方式也有它的弊端,那就是计划会议非常耗时。在实践中,有的团队将估算的环节放在计划会议之前,而有的团队不借助扑克牌,而是直接通过全员讨论得出一个相对正确的故事点。

image.png

T团队对于用户故事的估算是需要不断的磨合的,同时还有一个需要不断磨合的是团队速度。A君B君C君已经在计划会议中为若干个用户故事完成了估算,总故事点约为40,那么T团队能够完成这个40个故事点吗?实践是检验猜测的唯一方式。

随着几个迭代的尝试,T团队发现30个故事点的工作量刚刚好,不紧也不慢,那么T团队的团队速度即为30个故事点/10天。

团队速度的作用之一是,如果T团队在一个迭代中规划了总计为30个故事点的用户故事,不管每个用户故事是A君B君C君谁来做,理论上这些用户故事T团队都能按时完成。当然T团队的速度不是一成不变的,下图是我所在的团队最近三个迭代的团队速度。

image.png

(截图来自Worktile Agile)

根据过去一段时间的团队速度来规划下一个迭代的工作规模,是非常科学的。

T团队对自己团队的能力有着清晰的认识,也对迭代的目标充满着信心。另外,T团队还可以根据自己的团队速度,在迭代中插入一定比例的非功能性需求。

除了团队速度,使用故事点也可以非常直观的体现T团队在一个迭代中的工作进展,下图是我所在的团队Sprint 10的燃尽图。

image.png

(截图来自Worktile Agile)

燃尽图的趋势可以有效的体现T团队目前是否失控,如果燃尽图总是居高不下,所有人需要在站立会议中进行讨论,共同发现、承担并解决问题,这才能称得上是一个团队,不是吗?

本文作者:Worktile 孙敬云

智齿客服