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