估算项目周期，软件行业做项目必备节目，也是每个开发人员在职业生涯中无限循环的痛。
没有经验的开发人员对估算任务这件事来说都带有深深的恐惧，估多了显得自己无能，估少了deadline做不完脸上无光。怎么办？
其实项目的所有干系人，都想得到一个靠谱的估算：
老板需要需要一个估算衡量根据公司现有资源值不值得做这个项目。
市场人员需要根据估算来计算招标成本。
项目经理希望更准确的估算来规划工期。
开发人员希望自己准确的估算来告别无休止的在“最后期限”前的加班。
如何精确的估算项目，这在以前是个玄学，因为有大量因素影响估算结果：
老板说这个项目对公司很重要，一定要在XX月前完成！
销售说竞争对手功能比我们多，报价比我们低，我们也要赶上！
项目经理被老板搞得压力很大，也要求开发估算“时间扣的紧点，不行咱就加班”。
开发被要求1,2天内给个大致结果，没有足够的时间分析需求。
此处省略若干
现在仍有大量公司的项目或多或少存在以上问题（拍脑袋定日期）,那么作为工程鼻祖的基建工程是怎么做的呢？
工程领域成本估算##先看下传统工程领域的方式。工程领域对基建项目的概预算计算已经有很成熟的一套做法，并且有国标手册可以查。如我要建设一个通信基站，里面要安装几套设备，设计院如何估算开支？
分2个步骤：
1.估工作量
这些东西都可以根据手册先查出这些东西的工作量（如大到某个工程机械的工时，小到安装一个设备需要技工多少工时）。根据工作性质还能查出做这个需要几个工人，得到总工时。这些最后都能根据一个价格表对应上查出最终预算价格。
2.估材料损耗
做这些活，要用多少材料，材料的价格，也可以根据手册来查，查完了计算器一算，填表计算即可。
量和价是分开的，无论什么年代，人干的量基本是不变的，变的就是每若干年调整一下的人工材料价格，充分体现了面向对象封装变化的思想。
工程上能这么做是因为大部分项目脱不出这些看得见的工作，前期报价能根据以往经验大致估出一个差不多的造价成本。
软件估算##软件领域由于没有实体易修改的特殊性，估算则不确定性比较多，如：
客户开始也不知道自己要什么
客户知道自己要什么，但做着做着想法就变了
开发组织自身的情况制约（人力资源，硬件资源，内部支持）
开发人员水平参差不齐（多出现于临时拼凑的团队）
组织对于质量的看重程度，越重视则流程越重，速度越慢
双方企业文化的契合度（直接影响合作）
不熟悉的项目领域
不熟悉的技术领域
新的编程工具
团队成员能否不受打扰全神贯注
如果还不知道自己在谈论什么，那么期望谈
论的事达到精确是没有意义的。
— 约翰·冯·诺依曼
做估算首先要要知道估算的目的，估算的首要目标并不是预算项目的结果，而是确定项目目标是否能实现，并且在实施中通过项目控制来可控的达到目的。
业内常用的估算方法有：专家估算，功能点估算，story point估算等。总体的思路都是一样，将粗粒度的需求拆成细粒度的技术功能点，反复递归直到任务为一天到半天的量，再汇总， 标准的分而治之策略。这里就不讨论具体的方法，可以直接看下《软件估算：黑匣子揭秘》这本书，很多疑问可以在这本书里得到解答。
计算机科学是一门实践科学，先有理论支持，再通过实践进行论证及研究。现在一线开发人员都在忙于业务系统的开发，干的是“编码工人”的活，甚至将同样的代码从一个项目挪到另一个项目，认为满足工作需要就行；其实遇到问题适当进行一些理论的研究，就像练内功，内功扎实了，才能无招胜有招。