7.4  重估部分完成的故事

开发小组在一次迭代中只部分完成了一个用户故事的时候，您也可能希望进行重估。假设开发小组正在处理的用户故事的内容是：“作为教练，我可以让系统推荐每个项目应该由谁参加。”这个故事最初被估计为5点，但它比表面上要复杂得多。

参加一场游泳比赛的游泳队会按照队员的名次获得积分。但是，为一次游泳比赛作规划，并不只是把队伍中每个项目游得最快的队员安排到那个项目中那么简单。每名运动员所能参加的项目数目是有限的。这意味着也许因为我们更需要Savannah游100米蛙泳，就不能选择她游100米仰泳。所以，假设开发小组达到迭代结束的时候，系统已经可以为独立的项目优化分配运动员。但是，小组还没有开始考虑如何为接力项目分配人员。小组应该把当前这次迭代的速度计算为多少点？他们又应该为剩下的工作分配多少点？

首先，请允许我指出，在计算速度的时候我一般赞同要么全有要么全无的态度：如果一个用户故事已经完成(已编码、已测试、并被产品所有者接受)，开发小组就得到所有的点数；但是如果用户故事的任何一部分工作没有完成，他们就什么都不能得到。在一次迭代结束的时候，这是评估的最简单方法：如果每件事都做完了，就得到所有点数；如果缺少任何元素，就得不到点数。如果开发小组有可能在下次迭代中处理该故事的剩余部分，这样做是可以的。他们在第一次迭代中的速度会略低于预期，因为他们没有得到部分完成的用户故事的点数。但在第二次迭代中，虽然在这次迭代开始之前他们就完成了部分工作，但仍然得到了所有的点数，所以速度会高于预期。只要每个人都记住我们最感兴趣的是小组的长期平均速度，而不是速度在某次迭代中的升高或降低，这样做就不会有什么问题。

但是，在某些情况下，可能不会在下一次迭代中处理用户故事未完成的部分。这时，让开发小组获得这个用户故事已完成部分的点数可能更合适。应根据小组现有的知识对剩余的故事(初始故事的一个子集)进行重估。在前面的例子中，原始的故事被估计为5点。如果小组觉得他们已经完成的子集(安排独立的项目)等价于3个故事点或者理想日，他们可以给自己那么多的点数。这时，原始故事的剩余部分可以改写为：“作为教练，我可以让系统推荐每项接力应该由谁参加。”开发小组可以把这个较小的故事相对其他故事进行估计。新估计结果和已完成部分点数的和并不需要等于最初的估计值5。

不过，解决未全部完成用户故事的点数分配问题的两个最佳方法是：避免出现未全部完成的故事，以及使用足够小的用户故事从而不存在部分点数的问题。