01
为什么要做估算
我们的业务方经常抱怨资源不足，团队需求的吞吐率太低，资源和需求量的不匹配是一个永恒的话题，解决方案应该不只是增加资源，增加了资源如果需求的输入量不能稳定保证，那资源就会处于持续浪费的状态当中。
1、工作量透明出来
其实这个问题不一定是要从补充资源的角度来考虑，可以让我们的需求工作量透明出来，让我们的业务方知道团队的需求吞吐率，也可以辅助梳理优先级，合理安排资源。业务方对于一个需求需要的工作量其实是不清楚的，经常他们一个很简单的需求，其实实现起来是比较耗时的。
2、促进深度思考
估算可以让团队对所做的事情有更加深入的思考，当我们要对外提供一个估算值的时候，团队会更加倾向于仔细考虑自己的工作。
当有一个需求需要你给出估算时，出于责任心的考虑，会让我进一步做出深入思考，这个过程也会促进了团队对需求的理解，及时识别依赖和风险，避免在后期出现“惊喜”。
3、帮助确定优先级
如果一个需求完成的工作量需要5天，可能业务方会更加倾向于这个功能在下个迭代交付，但是如果这个工作量需要2个月，可能业务方会考虑这个需求的价值，是否值得团队去做，是否有其他更低成本的替代方案来实现，或者优先实现其他更优价值的工作。如果这个工作量需要耗费近半年的时间，可能业务方会考虑这个需求是否从需求列表中移除，因为实现这个需求的成本如此之大，或者对这个需求做进一步的拆分，采用分步验证的方式去实现。
4、帮助了解团队速率
几个迭代下来，会发现团队能够完成的故事点数是比较恒定的，这也有助于我们的产品经理合理安排需求，对于一个高速发展期的业务，产品经理的待办列表中会有非常多的需求，但是接下来需要选取哪些需求进行细化，需要在当前迭代安排哪些需求的评审，如果没有估算，产品经理对自己需要梳理或者评审哪些需求其实是比较模糊的。
举个我们现实中遇到的问题：
产品经理在迭代开始前评审了需求，但是这些需求需要2个迭代甚至更久的时间才能完成。评审完成，一方面在下个迭代开始之前这些需求的优先级可能变化了，另一方面，评审了很长时间的需求，团队在开始做之前还需要进行重新熟悉和理解，这里就出现了重复的工作量。
有效避免这样的重复现象出现的方法，就是在迭代开始之前，由我们的SM及核心开发人员对需求进行估算，结合历史团队的交付速率，可以快速评估出接下来迭代可以交付需求的工作量，这样产品经理可以合理的安排需要评审的需求，帮助提升团队效率。
02
估算的方法
作为项目经理，估算是一个基本功，不管在敏捷实践中，还是在传统方式的项目管理中。另外，估算也是计划的前提，只有对工作量做出合理的评估，才能给出一份可执行的计划。
那估算的方法有哪些呢？常见的有类比估算、三点估算、自下而上估算及专家估算法。
1、类比估算
适用于：项目立项、项目计划阶段初估
通过和过去类似项目进行类比估算，如果这类项目过去已经做过，可以用这种方式快速的给出预估时间。对于项目型交付组织来说，如果过去做过类似项目，可以快速的评估出项目需要交付的周期。估算方法其实并不局限，这里也可以融入专家估算，如果有相关项目经验的专家，通过专家的经验，能够快速给出可靠的项目周期估算。
2、三点估算
适用于：项目立项、项目计划阶段初估
在没有相关历史数据参考的情况下，可以相关专家（至少3人以上）参与估算，一般会有一个估算的最小值（最乐观的值），和估算一般值（一般的值），估算的最大值（最悲观的值）。
3、自下而上估算
适用于：项目阶段性计划，迭代计划等
自下而上的估算，一般需要先进性WBS的拆分，拆分之后，由项目组成员对各自活动进行估算后求和，这种估算相对来说更加详细，相对耗时比较长，所以可以项目的阶段性计划中采用这种方式。
4、Delphi专家估算
特点：匿名
Delphi估算需要一个专家组，是一个逐步达成共识的方法，每个专家通过匿名提交估算，并 对他们进行评审和讨论，如果不能达成共识需要重复该过程。
关于估算的方法就介绍到这里，估算的方法有很多，作为项目经理学习了这些方法之后需要进行灵活的应用。有些估算非常耗时，需要项目经理结合耗时和准确性进行取舍，选择合适的方式进行。
