敏捷开发中的故事点究竟是什么？如何预估故事点？

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

故事点（story point）和预估时间（estimated）不同，故事点是一种相对的估计，它并不能和相似“人/天”这样的单位画等号，由于每一个人完成一样复杂度的工做所需的时间是不一样的。咱们举个例子说明一下：

假设T团队有A、B、C三位员工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能这样对比的，这里只是方便说明问题），T团队约定10天为一个迭代，如今他们想计划一下将来的工做。若是按照预估时间的方式，一个用户故事B君以为须要1天，A君以为0.5天就能够，C君以为须要2天，那么他们最终定多少呢？

这里可能出现两种结果：

第一种结果，A君说这个我来作，写0.5天吧！若是按照这个方式，那么整个计划会议就演变成分工会议，A君挑若干的用户故事，本身进行估时，B君和C君也是如此，当每一个人的总估时都逼近10天的时候，那么这个迭代的目标就肯定了。这是不少团队实际采用的方式，看起来好像没问题，可是长此以往，这种方式的弊端就会显现出来。

1. 本身干本身的，不关心全局的进展。既然每一个人本身的工做内容都已经肯定，那每一个人安排好本身的工做就能够了，何须关心别人的工做呢？
2. 抗风险能力差。若是A君请假1天，须要C君花4天才能弥补。不只对C君的计划影响巨大，也让整个团队的预估和实际相差甚远。
3. 看不到团队的真实速率。每当PO询问某些用户故事能不能安排到下个迭代时，一般获得的答案是“这要看谁有没有空”。
4. 不利于团队成员的成长。C君很难有机会作一些复杂的，对本身能力有提高的工做，由于出于时间成本的考虑，复杂的工做都交给A君来处理。

固然，还有第二种可能，你们决定取个中间值，但是中间值定多少才算合理呢？预估的时间多就意味着总体完成的工做量变少，预估的时间少意味着完不成的几率会增大。

不一样于预估时间，故事点关注的是复杂度，让全部人对同一个用户故事有相同的复杂度认知。为了作到这一点，T团队能够找到一个基准的用户故事（下文称为基准故事），基准故事不必定是最小的，可是必定能在T团队中每一个人心中引发共鸣，而后T团队将第一个基准故事定义为1个故事点。

在估算一个新的用户故事X时，全部人都须要思考，故事X比基准故事更花时间吗？若是故事X的复杂度是基准故事的2倍，那么很显然，故事X的故事点应该为2。须要注意的是，故事点的取值要遵循斐波那契数列（一、二、三、五、八、1三、2一、34… ），不过为了方便记忆，在实际的操做中，不少团队将21替换20，34替换成40等等。下图是个人Scrum扑克牌。

这些纸牌表示的意思是：

1. 0表示喝口水的时间就能完成。
2. 其余数字是根据和基准故事对比得出的结论。
3. ?表示复杂度未知，一般须要对用户故事进行讨论或者拆分。
4. 咖啡表示估算的过久，有点累了，须要休息一下。

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

固然在实际的工做中，因为每一个人实际状况的不一样，即便全部人都明白1个故事点意味着什么，依然会为一个用户故事的故事点是2仍是5而产生争论。有的人考虑的多，有的人考虑的少，有的知道一些近路，有的人一脸茫然。正确的步骤是这样的：

1. 全部人先不要说出本身的故事点，而是将对应的纸盘扣在桌子上。
2. 当全部人的纸牌都扣在桌子上时，你们一块儿翻开本身的卡牌。
3. 请估算差别最大的两位成员讨论，各自估算的缘由。
4. 全部人收回纸牌，重复步骤1-4。直到全部人的估算一致为止。

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

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

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

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

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

（截图来自Worktile Agile）

根据过去一段时间的团队速度来规划下一个迭代的工做规模，是很是科学的。

T团队对本身团队的能力有着清晰的认识，也对迭代的目标充满着信心。另外，T团队还能够根据本身的团队速度，在迭代中插入必定比例的非功能性需求。

除了团队速度，使用故事点也能够很是直观的体现T团队在一个迭代中的工做进展，下图是我所在的团队Sprint 10的燃尽图。

（截图来自Worktile Agile）

燃尽图的趋势能够有效的体现T团队目前是否失控，若是燃尽图老是居高不下，全部人须要在站立会议中进行讨论，共同发现、承担并解决问题，这才能称得上是一个团队，不是吗？

Worktile 官网：worktile.com

本文做者：孙敬云

文章首发于「Worktile官方博客」，转载请注明出处。