如果你的项目正在用敏捷的方式运作，相信你已经开展了估算的工作。通常来说，在迭代开始前，我们会对迭代中计划的任务进行估算，确保我们计划的工作量相对合理。但这种预测和天气预报一样是存在误差的。在迭代过程中，我们经常可以听到这样的声音：
之前的点估小了，这张卡（story）还需要几天；
这个卡比之前想的简单，估计可以提前完成。
面对这些情况，我们应该如何应对呢？是保持原始估点不变？还是按实际的工作量修改原始估算？要回答这个问题，我们分别看看这两种方案。
更新原始估算
既然计划要持续的做，那估点的变化当然需要更新，这样可以准确的判断出变更对整体迭代计划的影响。比如，一张卡（story）从3个点涨到了5个点，这意味着我们很可能要从迭代计划中舍弃一张2个点的卡。这时就需要我们和客户一起找出可以排到下个迭代的任务，如果是砍需求，过程很可能是痛苦的，相信做过项目经理的同学一定有体会。这种方式增加了信息的透明度，而最终各卡的估算也与实际工作量相匹配。看起来很完美，但是当下个迭代开始，新的问题来了，我们应该计划多少需求呢？假设我们的资源和工时不变，我们是否可以按上个迭代完成的工作量计划呢？我们再看看另一种方案。
保持原始估算不变
对于上面的例子，如果不改变原始估算，当迭代结束时，我们会比之前的计划少完成2个点。这时，对当前迭代计划的影响则需要手工计算，此时如果有多张卡存在上下浮动，那计算的复杂度将会随之上升。在后续计划的制定中，我们同样需要考虑计划多少的问题。
应该计划多少
两种方案都指向同一个问题：如何制定后续计划？
当实际完成量减少时，如果是乐观的项目经理（PM），你应该认为上次砍需求，这次该轮到加需求，于是你会按之前迭代的实际完成量做计划。如果你相对悲观，你会认为昨天的悲剧今天可能还会再次上演，于是你想在实际完成量的基础上减去估算总偏差；当实际完成量增加时，相信你会选择相反的方案。
此时，我们隐约看到了一种更科学的计算方案。相比于一个固定点数的计划，我们可以通过估算偏差让计划浮动起来：
计划工作量 = 过去完成工作量 +- （过去完成工作量 X 估算偏差）
也就是说，我们后续的计划最多完成之前加偏差的工作，最少完成之前减偏差的工作。而偏差可以通过每个需求的原始估算与实际完成工作量对比得出：
估算偏差 = 相对变化量 / 实际完成工作总量
这个偏差应该是迭代范围内相对的，如果有两个需求，一个加1点，一个减1点，则偏差应该为零，因为我们关注的是整体迭代的计划情况。所以，敏捷中的迭代计划应该是在一个范围内，而不是一个确定值。而这个范围的大小，取决于我们估算的准确度。
点vs人天
从定义的角度看，功能点反应的是完成这件工作的实际工作量。应该说，点与人天应该是成正比的，之所以在计划时选择点，是为了简化估算的过程，通过点数的抽象，快速达成共识。这也要求我们在估算过程中更多的关注对需求的澄清和解决方案的设计，避免陷入精确天数的讨论。
团队速率怎么办
提起估算，不能不提它的另一消费者团队速率（Velocity），很多团队通过对实际完成点数的跟踪实现对团队速率的计算。并认为团队速率反应实际的生产力。但实际的过程中，我们很难用统一的标尺评估不同时期需求的工作量。因为随着时间的发展，团队人员的能力，项目的技术、业务复杂度、需求的不确定性都是在发生变化的。众多的影响因素使得我们不能简单的认为今天的15个点一定好于昨天的10个点。如果生产力真的提升了，以前3个点的工作量，今天可能1个点就可以完成，这样算总团队速率反而会下降。
综上，正确使用团队速率的办法是用其计划未来，而不是度量生产力的变化。
估算三要素
估算不是免费的，它是一项非常昂贵的活动，而作为这笔投资的回报，我们得到了对项目的预测能力。实际应用中，我们需要在投入时间，成本，估算偏差上做出平衡。以我的实际经验，两周的迭代周期下，估算应该在2小时内完成（需求的讲解不算），而准确度上，20%的估算偏差是完全可以接受的。选择敏捷，最大的转变在于接受失败的心态，一个完全透明的项目，就会是有些迭代超过预期，有些迭代低于预期。要想完全消除偏差，只会把项目经理逼上做假的绝路。当然，如果你的项目需要精确的交付日期，那你需要在估算上做更大的投资，甚至加入缓冲（buffer）。估算并不是越准越好，找到合适自己的度最为关键。如果交付节奏够快，客户足够信任，我们完全可以取消估算。
