敏捷估算与规划—规模估计

1 使用故事点估算规模

　　故事点是对用户故事规模的相对度量。具有10个故事点的用户故事的规模、复杂度或者风险应估计为具有5个故事点的用户故事的两倍。具有10个故事点的用户故事的规模、复杂度或者风险同样应该估计为一个20点的用户故事的一半。有意义的只是分配给不同用户故事的点值得相对大小。

　　速度是对开发小组每次迭代的进度率的度量。在每次迭代结束的时候，开发小组可以看看他们完成了哪些用户故事，通过计算完成的用户故事的故事点估计值之和来得到小组的速度。

　　故事点知识对要进行的工作的规模估计。与其说一个项目的持续时间是估计出来的，不如说是通过求取项目的总故事点数，再除以小组的速度而推算出来的。

 

2 使用理想日进行估算

 

　　理想时间和耗用时间是不同的。异常橄榄球赛的理想时间是60分钟，但在一场60分钟的比赛结束前，时钟上通常可能已经过了3小时或更多。当然，导致这一差异的原因是比赛过程中可能出现的各种干扰。

 

　　使用理想日而不是耗用日，更容易估计开发一个用户故事所需的时间量。按照耗用日进行估算要求我们考虑在处理这个用户故事时所有可能出现的干扰。而如果我们是以理想日进行估计，就只需要考虑这个用户故事所需要的时间。这时，理想日是对于规模的估算，虽然它的意义没有故事点那么严格。

 

　　采用理想日进行估算的时候，最好只为每个用户故事分配单一的估计值。应该把所有需要的时间加在一起，说某个用户故事需要9个理想日，而不是说它需要6个开发日，3个测试日。

 

3 估计方法

 

　　花更多的时间和精力来得到一个估计值，并不一定会提高它的准确性。应该根据估计的目的来决定在估计中投入多少工作量。虽然中所周知将要做某项工作的人才能给出最好的估计，但在一个敏捷开发小组中，我们无法提前知道谁将负责这项工作，因此估计应该是小组合力完成的一项活动。

 

　　估计应该基于一个预先定义的尺度。将在最近处理的功能以及需要非常可靠估计的功能应该足够小，从而可以使用一个1~10之间的非线性尺度进行估计，例如1、2、3、5、8或1、2、4、8。不太可能在最近几次迭代中实现的大功能可以不用分解，并且用大的单位估计，例如13,20,40,100。有些小组选择在估计尺度中包含0。

 

　　要得到一个估计值，我们可以依赖专家意见、类别和裂解（大用户故事分解为小用户故事），规划扑克是一个有趣且有效的方法，它结合了上述3种办法。在规划扑克中，每个估计者有一叠写着有效估计值的卡片，每讨论一个功能，每个估计者就选择一张代表他的估计值的卡片。所有卡片都同时展示出来，小组对估计值进行讨论，重复这个过程知道达成一致的估计。

 

4 重估

 　　故事点和理想日是对功能规模的估计，可以帮助我们知道何时应进行重估。只有在对一个或多个故事的相对规模的看法发生变化时，才应该进行重估。不要只因为进度没有预期的那么快二进行重估。让速度这个均衡器来解决大多数估计中的不准确性。

　　不建议在一次迭代结束的时候给出部分完成的用户故事的部分点数，而是让小组在速度计算中要么得到所有的估计点数，要么就什么也得不到。但是，小组也可能会选择对部分完成的用户故事进行重估。通常，这意味着对一个代表这次迭代中已完成工作的用户故事和说明剩余工作的用户故事进行重估，而这些用户故事估计值之和并不需要等于最初的估计值。

 

5 在故事点和理想日之间进行选择

　　开发小组可以选择使用故事点或理想日进行估计，两者都是具有一定有点的可行方法。

　　故事点的优势是可以帮助促进小组的跨职能行为。此外，由于故事点是更为纯粹的对规模的估计，因此即使小组在技术上或者领域知识上取得了进步，也并不需要重估他们。用故事点进行估计往往比用理想日估计要快。最后，与理想日不同，可以在小组成员之间对故事点进行比较。但是如果一个小组成员认为某件事情需要他4个理想日，而另一个成员认为他只需要1个理想日，也许他们都是对的，但他们缺乏讨论的共同基础，无法建立一个单一的估计。

　　理想日的优势在于更容易向开发小组之外的人进行解释，同时它更容易开始。

　　我的倾向是使用故事点，使用故事点进行估计的有点更有说服力。如果小组对单纯的规模估计存在困难，可以让他们用理想日开始估计，再转化到故事点上。我会更多的问“这个功能的规模与我们刚才估计的那个相比怎么样？”而不是“它会需要多少个理想日？”。大部分小组几乎不会注意到这种逐渐的转变，而当他们意识到的时候，他们已经是在使用故事点而不是理想日进行思考了。