TW洞见 | 敏捷开发中的故事点数

什么是故事点数？

故事点数是敏捷团队估算用户故事使用的一种主观的计量单位。

故事点数代表了什么？

故事点数代表了完成一个用户故事所要付出的工作量。一些敏捷开发人员认为，它是一种衡量复杂度的方式。不过，只有把故事开发过程中的复杂性和风险量化并计入估算中时，这种观点才能成立。

估计的故事点数包含哪些部分？

它应该包含了完成这个用户故事的工作量。当然，它不仅应该包含完成用户故事的开发工作量，也应该包含该用户故事在类产品环境中的测试工作量。

为什么用点数比用小时和天数更好？

故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式，在有大量样本数据的情况下，比独立估算每个用户故事要准确得多。

举个例子，我们可以很容易的说出，从(印度)德里到(印度)班加罗尔的距离是从(印度)孟买到(印度)班加罗尔的两倍，而不是德里到班加罗尔的距离是2061千米。

这样，团队不用花太多的时间来估算每个用户故事所要花费的准确时间和天数，就可以快速完成所有用户故事的估算。

我们应该如何估点呢？

最常用的方式，就是我们把估算的单位分成1，2，4，8，16...等。有些团队则更喜欢用斐波那契数列(1，2，3，5，8，13)去估算。一旦用户故事准备好了，团队就可以开始先挑选一个代表最小复杂度的用户故事，然后把其他的故事与之对比。

例如，团队可能会把“用户登录”的故事估算2个点，而把“自定义搜索”故事估算4个点，那是因为它是“用户登录”故事工作量的2倍。用这种估算的方式，就可以得到所有的用户故事的点数。

谁应参加故事点数估算？

理想情况下，团队中只要是有职责完成用户故事的，就应该参加点数估算。团队中的测试人员应该参加故事点数估算，并且把用户故事中额外的测试工作量估算进去。

举个例子，我们的搜索用户故事，界面部分要支持2种新的浏览器，可能需要1个点的开发工作量，但需要大量的测试工作。这时，测试人员就需要指出来，把必要的测试工作量计入故事点数中。

在对用户故事进行估点时，应不应该做一个最好情况、最可能、最差情况估计？

这可以通过提供三个不同的点数来做到：最好情况点数、最可能点数以及最差情况点数。当在第一个交付期，还没写什么代码，又需要估计大量的用户故事时，这是非常有效的一种估算方式。这种方式，依据不同的假定结果，提供了一个点数范围。例如，“用户登录”故事，最简单的情况，假定我们需要和本地的LDAP系统集成，估计2个点；但如果假定是和第三方提供的系统集成，就成为最差的情况，估计是8个点。

我们如何用故事点数来计划一个项目？

如果要做项目计划，那么需要计算出团队大致的交付速率，即一个迭代整个团队能交付多少个点。典型做法是使用历史数据来预测，如计算过去3个迭代的交付速率平均值。

如果这是一个刚刚组建的团队，那么我们就需要做一个小练习。首先团队成员需要达成共识，在一个迭代里能够完成多少个用户故事。选取（已经估算过点数）一些故事样本，让团队找出可以在一个迭代内完成的故事，计算它们的点数和，这样重复若干轮。最后计算出每一轮完成故事点数的平均值，从而得出一个迭代的交付效率。

例如，两周为一个迭代，进行了三轮，结果是6，8和10点，那么就可以计算出8点就是我们团队大致的迭代交付速率：(6+8+10)/3=8。

这样，就可以假定我们团队在以后每两周，可以完成8个点，排出一个计划。

不同的开发团队，是否可以使用统一的故事点数基准？

不同的开发团队，对于故事点数有不同的度量基准，取决于各个团队所要估计的用户故事。除非他们是在开发相同的系统，否则团队A开发1个点的工作量和团队B在不同系统中开发1个点的工作量是不同的。这种差异将会影响团队的迭代交付速率。

如果有一个很大的项目，需要分成多个小团队来共同开发，人们很可能想去尝试定义一种点数标准应用到所有小团队。这有悖于估算用户故事点数的目的，每个小团队都会有自己的主观衡量标准。

我们如何估算试探性研究(Spike)的用户故事？

为了弄明白如何实现一个特定的功能，或者验证某种概念，我们需要试探性研究故事（Spike）。由于很难知道到底总共需要多少工作量，通常我们要提前在团队中达成共识，对这种研究做出一定时间限制。这些用户故事可是通过观察交付速率趋势图，转换成大致的点数。

例如，如果需要计划一周的时间来完成一个试探性研究，而交付速率是16个点（迭代周期为两周），那么就可以估算这个故事为8个点。

是否有一种方式可以计算每个点的成本？

每个点的成本可以如此计算：一个迭代的总成本/一个迭代完成的总点数。一些情况下，我们会有一个额外的迭代去准备发布或者是做回归测试，那么这个迭代的成本也应该被计算在内。

用户点数是否是团队不能估计出准确工作天/小时数的借口？

问这个问题，其实就是认为估计每个用户故事所需要的准确工作量和时间（开发天数/小时数），比用相对点数估算更好。而且，按开发天/小时数来估计，会给团队带来过度的压力。迫使在规定时间内交付用户故事，可能导致团队不能够达到一种匀速前进的状态，而是彻底累垮。

用户点数是否和业务价值有关？

用户故事点数是对实现用户故事所需要工作量的团队内部度量。无论如何，与用户故事所能提供多少业务价值没有关系。 很可能在同一个系统中，1个点数的用户故事会比4个点的故事有更大的业务价值。业务价值最好是留给产品经理和相关的业务决策者来衡量。

如果用点数来估计，我们如何知道团队的估算是否是在提升？

业界普遍认为，用人天数去估算工作量更加容易跟踪（估算比较准确的前提下），可以对比每个故事实际消耗的天数和所估计的天数。但是这种方式实际是反作用于工作效率的，因为迫于必须在预计天数完成的压力，团队会花好几个小时来估算很少几个用户故事，以确保每个故事都能有个准确预计的天数。

当团队的用相对的点数来估计的时候，就会慢慢形成一种趋势，开发相同大小点数的故事会有非常近似的开发时间。如果有个故事点数差得离谱，就会非常明显地暴露出来。

随着团队对所开发的系统更加得熟悉，开发人员是否应该修改故事点数？

如果用户故事A被定义为2个点，一个相似的用户故事B在几个月后开发也应该被估算为2个点。当团队完成故事A后，团队因为了解到更多，故事B可以很容易实现，这种情况应视为是团队交付效率的提升。

挑选最初估计时各个尺寸的用户故事，建立起一个“故事大小基准板”，作为估计新用户故事时的对比基准，是非常有帮助的。