假设有1000块砖，它们的大小和重量是一样的，每个工人每天可以搬100块砖，所以我们可以估计需要10天才能搬完。10天意味着1个工人需要10天，10个工人只需要1天。

　　这1000元代表工作规模，生产率为100元/天，可计算工作量为10人日。建筑工程可以获得代表工作规模的数据，如土方量、混凝土量和钢筋量，因此更容易计算完成这些工作所需的工作量。

　　软件工程估计也希望达到类似的效果，但软件项目的工作规模是什么呢？功能点和代码线是两种常见的软件规模表示方法。

　　软件规模与软件的具体生产技术、项目管理方法、项目组人员水平等无关。软件规模只与软件项目本身的性质有关。如果我们能找到合适的统一标准来衡量每个项目的规模，我们就可以在每个软件项目之间进行水平比较。功能点和代码行都希望达到这种效果。

　　功能点法的基本思路是将复杂的软件分解为独立粒度一致的功能点，并附加一些调整系数，以获得软件规模。

　　我们的大部分项目都是数据库四轮马车的操作（查询、添加、修改和删除）。功能点法从相对较高的层次抽象这些工作。有一套严格的规则可以将您的需求分解为一个功能点。代码行也有类似的想法，但分解的结果只是代码行。但一般来说，代码行与软件的实现技术相关性太大，人们会更喜欢功能点法。

　　功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：

　　1.只适用于数据库四轮马车的操作，不适用于游戏软件、计算机负责计算和决策软件等技术含量高、创意高的软件。

　　2.我们的大多数项目需求不明确，设计不明确，工期很快。这两种方法都不能适应这种实际情况。如果需求不明确，基本上就无法获得软件规模。建筑工程之所以能做到，是因为需求和设计都很明确。

　　3.这两种方法的规则都很详细，学习和实战需要很多时间。

　　4.软件项目很难适用于工作规模导出工作量的思维方式。项目组仍然习惯于列出具体任务，逐一估计时间，只有这样的工作方式才能让项目组感觉更实用。

　　Dephi估算法更符合每个人的实际工作习惯，也更容易掌握。

　　Delphi一般方法如下：

　　1.找几位资深专家一起开展项目WBS，将项目工作分为十几个工作项，最多二三十个。

　　2.所有专家都估计每个工作项目的工作量，并向其他专家解释他们的原因。

　　3.每个专家第一次估计的结果可能会有很大的不同，每个专家听取别人的意见后都会重新估计。

　　4.按照上述办法，各专家反复估算几次，一般次数就是2-4第二，各专家估计的工作量会越来越近，此时取所有专家的平均值。

　　一般认为，每个专家的经验和知识水平都会严重影响结果的准确性，我的实践经验是：项目组的每个人都应该自己估计，也就是说，让每个人都成为专家。在此基础上，可以增加项目组外的一两名专家。

　　有时候我觉得估计太复杂了。各种方法是不是太夸张了？其实最简单的方法就是让负责这项工作的人自己估计工作量。微软从底到上的估计方法就是这样做的，可谓回归自然！