14.5  我的建议

速度驱动的和承诺驱动的迭代规划方法都是可行的方法；不过，我更喜欢承诺驱动的方法。虽然速度在发布规划中扮演了关键的角色，但我并不认为它在迭代规划中也要扮演同样重要的角色。这样说的原因有两个。

首先，由于速度是对粗粒度估计(故事点或理想日)的度量，它在规划短时间的迭代中的工作时是不够精确的。我们可以使用这些粗粒度的估计值来估计小组在一次迭代中将要完成的工作总量。但是，我们不能同样使用它们来规划单次迭代中的短期工作。

其次，小组会需要每次迭代完成20～30个用户故事才能把故事点或理想日估计中的误差平均掉。很少有小组能在一次迭代中完成这么多的故事。

要看到这些问题的影响，我们假设有一个小组在过去5次迭代中的速度都是30。这个速度是稳定的，他们很可能在接下来这次迭代中也能完成30点。但是，我们知道并不是所有5点的用户故事都一样。如果我们对一大堆5点的故事进行排序，我们知道可能会发现有6个5点的故事看起来比5点的故事要容易一些。这样做有些时候也许会有一些差错，但是如果我们是第一次这样做，还是很可能会成功的。我们也许可以把速度从30提高到40。另一方面，我们也可以只选择看起来要难一些的5点故事。我们还是认为它们应该被估计为5点，但是它们比其他的5点故事要稍微难一些。

在一个项目中，我们不会把所有的用户故事都翻一遍来找“容易的5点”或是“难的5点”。但是，大多数小组会给一次迭代规划3到12个用户故事。在一次迭代中选择那么少的故事时，小组就很有可能很幸运地在无意中都选择了容易一些的，也可能会很不幸地选择了都要难一些的。

由于在单次迭代中完成的用户故事数目太少，不能把这个差异平均掉，我倾向于在规划一次迭代的时候不使用速度。但是，因为在一次发布的进程中确实可以平均掉这些差异，所以速度对于发布规划还是非常有效的。