做敏捷估算，请忘掉人/天

估算的方法之前，我们先来回顾一下基于人／天的传统估算的思路。传统的工作量估算是估计是一个绝对值，单位是人／天或者人／时。

比如：

David喝完一小杯热咖啡花费1.2个小时（工作量 1.2人／时）

David喝完一大杯热咖啡花费2.4个小时（工作量 2.4人／时）

由于人的能力是有差异的，所以David的工作量对于Tom来讲可能就不适用，Tom喝完一小杯热咖啡可能需要1.5小时。

这样一来，工作量、参与人以及完成这些工作的时间周期就是强相关的，因为强相关会带来如下挑战：

1. 做计划时必须把人和周期关联到具体的任务上，会让计划很复杂。

2. 团队成员的分工发生变化时对计划的影响比较大，管理和维护计划成本高。（这是甘特图的价值所在）

3. 由于第二条的原因，这种工作量的估算方式不利于团队协作。

接下来，我们来看看敏捷估算的思路。 在探讨具体的思路之前，我们先思考一下做估算的目的什么，通常有两个目的：

1. 核算成本和周期，我们要了解这这个项目或产品的投资回报。

2. 做计划，根据项目的需要，我们要知道什么时间点应该交付什么内容才可以满足市场、用户或客户的期望。

做敏捷估算时，请先忘掉人／天或人／时，敏捷估算关注的是工作量的规模（大小），而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位——故事点，故事点是一个相对值，是一个相对倍数，和人／天，人／时没有关系，它和公里、吨、摄氏度类似，只是一个计量单位而已。我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍， 是2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。

敏捷估算的步骤：

1. 找一个参考基准，作为一个故事点。比如：把开发一个简单的查询页面工作量作为基准，定义为一个故事点。

2. 拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如：查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。

3. 累计产品backlog中的所有故事，得到所有故事总的故事点数。

得到了总的故事点规模，我们还要知道团队速度。团队速度是指：1个敏捷团队在一个迭代中完成的故事点总数。比如：某Scrum团队1个迭代可以完成 80个故事点，那么80个点就是他们的速度。

有了总的规模，我们也知道了团队一个迭代的速度，我们就可以很容易推算多少个迭代可以做完。 如下图所示，总的规模是1600个点，团队总共8个人，每个迭代完成80个点，我们就可以推算20个迭代完成。 每个迭代2周，所以40周可以完成，8个人40周的成本投入也可以很容易得出。

敏捷估算要点小结：

1. 相对估算，使用故事点作为单位，故事点是一个相对倍数。

2. 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人／天，人／时无关。

3. 敏捷估算关注团队的速度，不关注单个人的速度。

4. 通过总规模和团队速度，推算周期