最近评论
正在载入评论列表...
7.3 需要重估的情况
我们继续使用SwimStats Web站点，这一次使用表7-2中的用户故事和估计。
表7-2 对一些SwimStats用户故事的初始估计
|
故 事 编 号 |
用 户 故 事 |
估 计 |
|
1 |
作为运动员，我可以用折线图查看我在某个项目上的成绩 |
3 |
|
2 |
作为教练，我可以用折线图查看我所有的运动员在整个赛季中在某个项目上的进展 |
5 |
|
3 |
作为运动员，我可以用饼图来查看我得到过多少冠军、亚军、季军和更低的名次 |
3 |
|
4 |
作为教练，我可以看到一个显示每个运动员在每个项目上的最佳成绩的文字报告 |
3 |
|
5 |
作为教练，我可以把一次比赛使用的计时系统输出文件中的比赛结果上传到Web站点 |
3 |
|
6 |
作为教练，我可以让系统根据每名运动员所能参加项目数的限制推荐每个项目应该由谁参加 |
5 |
这些故事的前3个都需要向用户显示一张图。假设开发小组规划在第一次迭代中包含表7-2中的用户故事1、2和6。他们计划的速度是13。但是，在迭代结束的时候，他们只完成了故事1和6。他们说完成得较少的原因是故事1比预想的困难很多，它应该“至少是6点”。假设小组整个低估了显示图形的整体难度，而不只是低估了一个困难的用户故事。这样，如果故事1是预期规模的两倍，我们可以预计故事2和3也同样如此。
我们来看一下这种情况在下面3个场景中分别有什么影响。
7.3.1 场景1：不进行重估
在这个场景中，我们对所有的估计值都不作修改。开发小组在最近一次迭代中达到的速度是8。这导致我们期望在接下来的迭代中平均可以达到8点的速度。但是，开发小组知道他们无法在一次迭代中同时完成故事2和故事3，虽然它们总共只有8点。由于这两个故事都包含了作图，而且开发小组预期每个需要作图的用户故事的规模都是当前估计值的两倍(就像故事1一样)，因此小组的结论是他们不能在一次迭代中处理故事2和故事3。它们是只有8个点，但是也太多了。
7.3.2 场景2：重估完成的故事
在这个场景中，我们看看只调整故事1的估计值能否解决问题。在完成这次迭代之后，开发小组认为故事1应该是预期规模的两倍。于是他们决定把它重估为6而不是3。也就是说前一次迭代的速度是11—— 故事1的6点加上故事6的5点。
由于没有对其他的故事进行重估，于是小组计划在下一次迭代中包含故事2、3和4。这些故事值11点，与第一次迭代中完成的工作量一样。但是，他们会遇到与第一个场景中一样的问题：故事2和3很可能需要预期值两倍的时间，小组不可能达到期望的平均每次迭代11点。
7.3.3 场景3：相对规模改变时进行重估
在这个场景中，开发小组对每个作图故事都进行重估。对故事1、2和3的新估计值都是表7-2所示值的两倍。与第二个场景中一样，第一次迭代的速度是11—— 故事1的6点加上故事6的5点。由于第一次迭代的速度是11，因此小组预期下一次迭代的速度也大约是这么多。但是，当他们对下一次迭代进行规划的时候，只会选择故事2。这个最初估计为5点的故事被加倍到了10点，它的规模导致迭代中不能再容纳别的用户故事。
重估只在这第三个场景中有用。这意味着您应该只在用户故事的相对规模发生变化的时候进行重估。
