项目立项和项目计算都需要估算项目的时间和投入人力，但是计划和实际开发过程总是有偏差。怎么让估算更准确一些呢？
1. 估算很难
- 项目规模越大越难估算，经验欠缺，项目涉及的人很多，需求也会经常变更，各个服务之间的关系也很复杂。
- 个人和团队的工作效率也是一个因素，关系是否融洽，配合是否默契都需要进行考虑。 。
2. 提高估算准确性的手段
2.1 积累历史数据和检查列表
这需要有专门的部门来对项目的历史数据进行统计，并且更新检查列表。做一些统计，如工作经验不同的程序员每天编写的平均代码行数。更新项目中遇到的问题的checklist，从而加入足够的应急措施，应对某些风险，之前的经验也可以重用。
2.2 小组估算
多人估算比单独估算准确度多数情况下更准确一些。但是有一个关键前提，就是估算都是独立完成的，也就是说估算者的专业知识、背景和估算过程都不一样。 ，因为知识的分享能够增加知识的总量，比如完成一个项目需要的工作总和。
敏捷开发过程中，项目组成员通过便签或者“数字扑克”同时展示各自独立做出的估算，这是一个很好的方法
2.3 排除外部环境的干扰
所有的软件开发工作量估算，都需要专家判断。负责估算的人，在估算前或者估算中，了解到预算、客户期望、可用时间或其他因素。在没有意识到的情况下，估算者的估算结果可能很接近这些需求。负责工作量估算的人，应该尽量避免看到误导或无关信息，比如，应该将需求文档中的误导和无关信息去除。
2.4 使用简单的估算模型
无论基于WBS， 三点式，还是基于工作量的方式。选择一个合适的估算模型进行估算，效果会好一些。
3. 常用工作量估算方法
3.1 基于WBS的工作量估算
通常的估算步骤如下： 1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量； 2）进行WBS分解，力所能及地将整个项目的任务进行分解； 3）参考类似项目的数据，采用类比法或专家法，估计WBS中每类活动的工作量； 4）汇总得到项目的总工作量； 5）与第1）步的结果进行印证分析，根据分析结果，确定估计结果。
3.2 基于代码行的工作量估算
基于代码行（SLOC）的工作量估算，是从开发者的技术角度出发来度量软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时，先采用WBS法、类比法等统计出软件项目的代码行数，直接利用代码行数÷SLOC/人天，即得工作量人天数。
3.3 三点式
估算的时候估算三个时间：乐观时间、最可能时间、悲观时间。 估算时间 = （乐观值+4 x 最可能值+悲观值）/ 6
使用过程中，可以进行组合，如WBS+三点式， WBS + 代码量估算。
4. 估算的缺陷
估算不只是预测未来，真的会影响未来。过低的估算会导致过低的质量，可能导致返工，项目设计不足，整个推翻重来；过高的估算可能降低工作效率，每个人都按照估计的时间慢慢来。
“帕金森定律”：
只要你想做事，那就有做不完的事情来填满时间。这是大家公认的事情，帕金森举了一个例子： 一位闲来无事的老太太为了给远方的外甥女寄张明信片，可以足足花上一整天的工夫；找明信片要一个钟头，寻眼镜 一个钟头，查地址半个钟头，做文章一个钟头零一刻钟，然后，考虑去邻街的邮筒投递明信片要不要带把雨伞，又花掉 了二十分钟……就这样，一个忙人总共三分钟就可以办完的事，老太太却要犹豫、焦虑和操劳整整一天。假如完成工作所 需的时间，有如此之大的弹性，那就可以说明工作量和做这份工作的人数之间并不合适。
因此，必须考虑是否的确需要工作量估算。如果可有可无，或是以后才有必要，可能不做更好，或是推迟估算，直到可以得到更多信息。敏捷软件开发——只估算下一个 sprint 或者发布版本的工作量，而且必须使用此前sprint 或者版本发布的反馈信息——可能是避免过早估算带来的潜在危害的良好方法。
5. 如何更好的利用估算
这是我的个人思考， 不是一定是最佳实践哦。
项目总是要有一个整体的计划和时间， 但是项目也要一步一步开发。所以将初始估计和项目执行分开，减少初始估计不准对项目执行过程中的影响。
- 利用工作量估计模型估计整个项目的时间 ——提供初始计划
- 忘记这个时间
- sprint 启动会议，选择故事点。
- sprint review会议，查看进度是否和初始计划有偏差。如果有偏差，进行调整，如增加人力。或者进行重计划。
- 项目没有结束，一直重复2 ~ 4
关键是要在调整后，再进行每个sprint的故事点选择，这样可以尽量减少估算对实际项目过程中的影响。
6. 参考文档
- https://www.infoq.cn/article/software-development-effort-estimation
- https://blog.csdn.net/cuiping1993/article/details/78405974
