14.6  任务估计值和故事点的联系

经常有人要我解释在迭代规划中对任务的估计值与长期的发布规划中使用的故事点或理想日之间的关系。我看到一些小组走入歧途，开始相信在一个故事点和确定的小时数之间存在很强的联系。例如，我最近帮助过一支小组，他们跟踪在每次迭代中的实际生产小时数和速度。从得到的结果中，他们计算出每个故事点大约需要12个小时的工作。于是，他们开始错误地相信每个故事点总是等于12个小时的工作。但是，实际的情况却是接近于图14-5中所示。

图14-5显示出，平均起来大约需要花12个小时来完成一个1点的用户故事。但是，它也显示出某些1点的故事花费的时间较少，某些则花费得更多。在小组对用户故事下所隐藏的任务进行估计之前，很难知道一个特定的故事处于图中曲线的哪一个位置。

图14-5  完成1点的用户故事所需时间的分布

图14-5显示了1点的用户故事完成时间的分布，而图14-6则显示了1点、2点和3点的用户故事完成时间的假想分布。在这个图中，平均下来每个故事点仍然当于12个小时。但是，有些1点的故事所花费的时间可能会超过某些2点的故事。

图14-6  完成1点、2点和3点的用户故事所需时间的分布

开发某些2点的用户故事所需时间少于某些1点的故事是完全合理的，而且要为此做好准备。只要在迭代中有足够数量的用户故事来把这些超出常规的家伙平均掉，就不会有问题。项目中的每个成员都应该记住即使最初的高层次估计值一样，某些故事也可能会需要比其他故事更长的时间。

迭代的起止时间

在我刚开始管理敏捷开发项目的时候，我的小组按照常规在星期一开始一次迭代，在星期五结束迭代。无论小组使用的是2周、3周还是4周的迭代长度，我们都这样做。看上去星期一很自然就是开始一次迭代的日子，而星期五显然就是结束的日子。后来我指导一支负责开发一个网站的小组。这个网站在工作日很繁忙，而周末则很少有人使用，这时我的看法发生了改变。

供这支小组部署新网站更新的最合逻辑的时间是星期五晚上。如果出现了问题，他们可以在周末进行修改，而且可以把产生的影响降到最低，因为站点在这段时间很少使用。为了适应这种情况，小组决定采用2周一次的迭代，在星期五开始，星期四结束。效果非常好。星期五被用来进行迭代回顾和规划下一次迭代。这项工作通常进行到星期五下午3点左右，然后小组要么开始新的迭代的工作，要么偶尔会出去喝一杯或者打打保龄球。新的迭代在接下来的星期一才真正开始。这样做很好的原因在于，不用再担心像以前用星期一作为回顾和规划的日子一样，星期一整天都要开会。

小组偶尔会在星期五上午来对星期四没来得及完成的最后一些工作进行收尾。他们并没有把它养成一种习惯，只发生过很少几次；但是，在星期五早上花几个小时来收尾比把工作拖过周末还是要好一些(用星期一作为迭代启动日时他们就会这样做)。