软件开发计划_敏捷软件开发实践：估算与计划读书笔记109第7章重估-CSDN博客

本文链接：https://blog.csdn.net/weixin_39870664/article/details/111379528

《敏捷软件开发实践：估算与计划》第 7 章重估，重点和要点的思维导图及文字内容。

第 7 章重估

There's no sense in being Precise when you don't even know what you're talking about.

故事点或理想人天是对要实现的功能的总体规模和复杂度的估算。故事点并不是对实现一个功能所需时间的估算。实现一个功能所需的时间是一个关于功能的大小(以故事点或理想日表示的估算)和团队的进度率(以团队的速度来表示)的函数。

请牢记故事点和理想日是对大小的估算。因此只有在我们确信一个用户故事的相对大小发生了变化时，才需要重新估算。

7.1 SwimStats Web 站点

一个假想的 Web 站点 SwimStats，这是一个针对游泳运动员和游泳教练的网站。该站点将被作为一项服务卖给不同年龄组、学校和大学里的竞赛性游戏队。

7.2 不进行重估的情况

以 SwimStats 为例，假设有 4 个用户故事，每个故事的故事点数值分别为 3 点。一个不应该重估的场景如下：假设在第一次迭代结束时，团队完成了两个用户故事，假设为 6 个故事点。团队认为一次迭代应该完成两倍的故事点数(也就是 12 而不是 6 )。他们认为每个故事的大小或复杂度都是一开始预想的两倍，这是他们花了两倍的时间才完成的原因。但是，在项目开始前，团队认为 4 个用户故事具有相同的大小和复杂度，所以每个都被估算为 3 个故事点。由于这些故事是相当的，所以另外两个故事的估算值也要被加倍。团队为已经完成的故事给了自己更多的点数，使得速度加倍，但是，由于他们也让项目剩下的工作量加倍，所以，团队所处的状况与保持每个故事为 3 点但速度为 6 是一样的。

速度是很好的均衡器

对每个功能的估算是相对其他功能的估算做出的，因此无论我们的估算是正确的、稍微有点错误还是错了很多都不重要。重要的是它们是彼此一致的。只要我们的估算保持一致，在开始几次迭代中对速度的测量就可以让我们修订出一个可靠的进度表。

7.3 需要重估的情况 7.3.1 场景 1：不进行重估

对所有低估的故事不进行重估。由于估算相对大小存在部分不一致，那么可能无法在一次迭代中完成选中的那些低估的故事。

7.3.2 场景 2：重估完成的故事

那么被低估的故事，只对完成了的进行重估，而未开始的不重估。那么由于估算相对大小存在部分不一致，会导致无法在一次迭代中完成选中的那些低估的故事。

7.3.3 场景 3：相对大小改变时进行重估

对所有低估的故事都进行重估。由于估算的相对大小一致，则能确保在一次迭代中完成所选的故事。

重估只在这第三个场景中有用。这意味着你应该只在用户故事的相对大小发生变化的时候进行重估。

7.4 重估部分完成的故事

首先，建议在计算速度的时候采用“要么全有，要么全无”的态度。在一次迭代结束时，评估的最简单方法是：如果每件事都做完了，就得到所有点数；如果缺少任何元素，就得不到点数。

若团队在下次迭代中处理该故事的剩余部分，这样做是可以的。只要每个人都记得重要的是团队一段时间的平均速度，而不是速度在某次迭代中的升高或降低，这样做就不会有什么问题。