今天IPM纠正了一个我长期的误解，现把经过记录下。
在IPM中，我们会对这个迭代要做的User Story进行简单的讲解，然后开发人员会对该User Story进行估计。现在存在这么一个问题：假如我们现在要对Story #1: Provide RSS for Latest Articles进行估点。但是我发现我们之前曾经做过Provide RSS for Most Viewed Articles。基于对已有工作的经验，我认为现在这个Story将很容易完成。因为数据源已经有了，我们只需要借用一下以前那个Story里已经实现的RSSFormater就可以很容易实现了。那么按照我原先的想法，我将这个Story估计为1个点。
不过今天IPM的时候讨论了一个问题：对当前Story的评估，是否必须根据过往Story的开发经验或知识。按照我以前的误解是需要。
但是今天同事讲，对Story的估计是为了衡量这个Story的大小，是根据该Story的复杂度进行评估。比如我们拿以前一个Story #x作为基准点1，看看当前这个Story相对于这个作为基准点的Story是多大，然后做出评估，而不依赖你对该Story中的某些知识的熟悉程度。也就是说给Story估的点是一种相对复杂度，而不是工作量（这是我的误解）。
那么就可能存在这样的情况：我们先完成了一个点数为2的Story #1，现在要做一个点数为4的Story #2。可能因为Story #2中有部分工作在Story #1里已经准备好了基础设施，导致这个4点的Story比2点的花更少的时间。同事说，这是正常现象，这表示我们对系统的熟悉程度正在逐渐提高。所以一般就会出现这样的情况：在项目刚刚开始的时候我们完成点的速率会很低，随着项目的深入速率也就会不断的提高。比如在刚开始我们每个迭代完成了10个点，后来我们每个迭代可以完成15个点了，这就表示我们对项目越来越熟悉了。后来某个迭代，我们完成点数突然降低了，我们就可以立马发现这个信号，然后寻找原因：比如是不是步入了系统里一个不熟悉的领域？是不是士气有问题了？是不是请假的人太多了？等等，这样就更利于可视化，更利于我们发现问题所在。
还有一点是，如果我们对Story的估计基于以后的知识，那么问题就来了，可能团队里，你比较熟悉这个背景知识，但是别人并不了解。那如果依赖背景知识到底怎么估计呢？如果按照你的估计方式，那这个Story是不是一定要你做呢？这又是另外一个问题。
那如果不基于过往的经验我们到底估计这个点呢？
首先就是划分任务，我们可以让熟悉这个领域的团队成员对这个Story进行划分。比如上面这个RSS，一种可能的划分方式：
- 获取RSS所需数据源
- 提供针对的RSSFormater
- 编写格式化生成RSS的Velocity模板
因为划分任务后，每个任务都相对很小，也更明确了，我们就可以更好的评估该Story的复杂度。
那么如果碰到一个大家都不熟悉的领域呢？比如拿到一个Story后，大家都不知道到底该怎么下手，不知道水儿有多深。那么一般的建议就是不要对这个Story进行估计，我们需要让一个人先对这个Story Spike一下，然后拿到Spike结果后再划分任务，然后再估计。
总结一下
敏捷估计中对Story的估计是对Story复杂程度的衡量，并不表示完成该Story需要的工作量（因为工作量这东西还需要看完成该Story的人）。