让我们回想一下前面多次提到过的那辆车。要想高效前进，3件事情最重要：方向不能错，跑得要快，车不能散架或翻倒。
如果目标只是从苏州跑到北京，而没有任何时限上的约束，那么不做任何估算工作也没有关系—大可以想跑就跑，不想跑就歇息一下。只可惜现实往往并非如此，而是希望能预先知道到达目的地的时间，并且希望能够尽快到达。这样就必须在两个极端间取得平衡。既不能跑得过慢，浪费能力；也不能把万米当百米来跑，累死在半途上。最好是能保持一种恰当的、均衡的行进速度。
对于软件开发而言，由于变数太多，寻找这一均衡点尤其艰难。而估算正是达成这一目的的主要手段。总结来看，完美的估算方法具有如下的特征。
●对软件进行分类，在特定类别下统一单位。
●详细分解，使用彼此独立的不同视角进行多次估算，互相参照。
●控制精度在一定的程度上适可而止。
●确保估算数据能够和实际数据进行比对（当然也要有基于统一单位对最终结果进行度量的工具）。
除此之外，需要再次强调的是
到现在为止，许多估算和度量方法似乎都遗漏了一个关键的东西，即表达软件规模需要两个数字而不是一个数字。
软件是一种固化的思维，那么其两个关键产出物是：固化什么（需求规格说明），固化成了什么（代码）。这两个东西说的是同一个东西，但表现视角和形式不一样。
从估算和度量的角度看，事实上需要分别对两者（需求和代码）进行估算和度量。眼下来看，可以用来度量需求的单位是功能点，可以用来度量代码的则是代码行。
单纯从估算人月的角度看，分别估算似乎是不需要的。但从追踪进度和估量投入产出的角度看，两者则是同时需要的。
假设说，一个杯子的平均成本是5元，那A公司花了100元钱，做了15个杯子，无疑是差的，而B公司花了100元钱做了30个杯子，那生产效率是高的。其中100元是投入，而15个或30个杯子是产出。有投入有产出，就可以计算投入产出。
在软件中，需求类似于杯子数，而代码行则类似于花的钱。有需求的规模，也有代码的规模，才知道程序是否写的合适，才知道进度是否真的合适。比如说，一般来讲，1个功能点对应100行代码，那么如果执行过程中，完成100个功能点写了15000行代码，那很可能是代码质量出问题了。
缺乏这个维度，事实上除了Review和判断，很难找到有效的数字来对软件项目进行横向比较，即使是模糊的数字。(www.xing528.com)
当前的问题是，无论功能点和代码行都会导入比较多的偏差，尤其是代码行。在8.1节中我们会提出一个改善的方案来度量代码的规模。
帕金森定律和项目的失败率
有些事情如果参照起来看就特别有意思，比如说帕金森定律和项目的失败率。
帕金森定律说：不管你给项目组多少时间，项目组都能够把它耗完。
而IT这个行业中加班相对比较多，这一事实似乎可以证明帕金森定律深入人心—为防止它起作用管理人员都在制定乐观的日程。
与此相应的另一个现实则是很多软件项目并不成功。
根据CHAOS的报告，2009年的统计数据是：
32%的项目取得成功，成功意味着不延期，不超支，功能完整。
44%的项目受到挑战，受到挑战是指或者超支，或者延期或者取消某些预定的功能。
24%的项目彻底失败，失败是指项目取消或者从来没有被使用过。
如果能有一份国内的数据会更有意义，但可惜国内暂时好像还没有机构做类似的统计，因此只能暂时使用国外的。
这两项事实让我们看到一个充满矛盾的现象：在一个并不乐观的行业中，却往往有比较乐观的任务安排。
人浮于事一定是不好的，但为防止人浮于事而制定相对紧张的进度，其中所得未必就大于所失去的。而为想更好地把握这其中的尺度，首先需要回归到尽可能客观的标准，而唯有尽可能精确的估算，才可能构筑这种尽可能客观的标准。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
