基本思路是将复杂的软件分解为一个一个独立的粒度一致的功能点，附加一些调整系数，得到软件规模。
我们的项目大部分是数据库四轮马车的操作（查询、增加、修改、删除），功能点法从比较高的层次对这些工作进行抽象，有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。
功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：
1.只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。
2.我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。
3.两个方法的规则都很详细，要花大量时间学习和实战才能掌握。
4.由工作规模导出工作量这样的思考方式，难以适用于软件项目。项目组还是习惯列出具体的任务，逐条任务估计时间，而且只有这样的工作方式才能让项目组感觉更加踏实。
Dephi估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。
Delphi法的大致方法如下：
1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。
2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。
3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。
4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。
普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也就是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。
有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊！
微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后（即俗称的wbs：work breakdown structure，工作分解结构），每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。
这个方法还是有这样的一些问题的：
1.有人会估算偏小，比方他说需要5天，但往往10天还完不成。
2.有人估算过于保守。
3.项目的进度要求就是很