估算指南-20090527.docVIP

目的 此文档作为软件质量体系中的估算过程的具体使用指南，用来指导本行项目过程中的估算活动实施的进行。 本指南假设读者已了解并熟悉软件质量体系的估算过程，在此前提下，对于过程中已作了明确要求和解释的内容，将不再详细说明，指南将着重说明与本行实际情况相结合的关键事项。 估算的目标范围 2.1什么是估算 估算就是对项目将花费多少资源、持续多长时间或将花费多少成本的预测，通过估算结果与项目目标进行比较来确定项目目标是否足够现实，在无法通过控制项目达到目标时，必须调整项目目标使其更符合实际情况。 良好估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策，为项目跟踪提供重要的支持。 估算与计划、承诺的区别： 估算是客观的过程。估算结果构成了计划的基础，但计划并不一定要与估算结果相同。如果估算结果与目标之间存在显著的区别，进行项目计划时就要认识到两者之间的差距，并考虑可能存在较高的风险。 计划是有目的性的主观设计过程去寻求特定的结果。我们经常会让计划倾向某个方面以得到特定的结果，通过计划一些特定的方法来达到特定的目标。 承诺是许诺在特定日期之前以特定质量水平交付规定的功能。承诺可以与估算相同，可能比估算更激进，也可能比估算更保守。也就是说，不要假定承诺必须和估算是一样的；它们是不相同的。计划的结果往往在很多时候是一种承诺。 2.2估算对象 通常估算的对象有规模、进度、成本、工作量等。在实际的估算过程中，我们常常直接进行工作量估算，所以很容易混淆项目规模和工作量。为了区分这两个概念，在本指南中，“规模”特指软件系统本身的规模大小而不指工作量大小，一般使用诸如代码行、功能点、用户案例（Use Case）或者其他度量单位来估算给定项目属性集的技术工作的范围。 对于一个项目的估算活动，最困难的估算在于规模与总工作量，而其他的目标值，如：进度、资源、成本等都可以从中计算出来。 因此： 当前本行的软件项目估算的目标范围包括有： 规模（建议使用代码行（单位：千行）或功能点数（单位：个）统计） 工作量（单位：人月） 进度（单位：工作日或月） 成本（单位：万元） 首要的估算目标为：项目规模、总工作量。 2.3进入估算的思想准备 2.3.1什么是好估算 要做好估算，首先应当先明确的就是“好估算”。良好估算是指对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。 从数据统计上看，一个估算良好的项目，单点估算值可能和最终结果有所偏差，但最终结果始终在估算范围之内，并且随着项目的进行，估算范围是越来越小的。如图1： 图1：良好估算过程的数据比较图 图2是一个估算较差且有低估倾向的项目的估算过程数据统计，该项目一直处于低估状态，并且估算的范围太窄以致于始终没有将最终结果估算进范围内。 图2：不好的估算过程的数据比较图 2.3.2为什么我的估算总是不准确 2.3.2.1估算不准确罪魁祸首之一：低估 大多数人都这样认为，如果你给一个开发者5天时间去做一件4天就能完成的工作，他必然会去寻找一些事情来把多出来的一天用掉；如果你给一个项目组6个月时间来完成4个月就能完成的项目，他们同样会找到办法来把多出来的2个月用掉，所以管理者都希望通过挤压估算来避免这个现象。当然还有一些人认为如果给了太多的时间，开发人员往往会把任务放到后面来开展，这样他们还是匆匆忙忙的完成甚至无法按时完成。这些担忧都是正确的，而且也是客观事实，但是在软件开发中，高估的代价是线性的可控的，顶多就是浪费掉多估出来的那些时间。 图3：高估和低估代价示意图 但是低估就没有坏处么？有，而且低估的代价是非线性的不可控的（见上图），例如估算错误造成计划5%-10%的延迟本身并不是很要紧的问题，但是很多时候估算造成的是100%以上的偏差，基于这样估算上的计划就是在猜想了，计划也就根本没有意义了；同时，由于低估带来的计划延期等问题在严格规范管理的组织里需要进行延期原因分析、影响评估、计划变更评审等等相关工作，这些工作所需要代价往往是非线性增长的。 所以不要有目的的去低估，低估的代价比高估的代价更高，更何况程序员一般是乐观主义者，他们往往给出的估计值就已经是较少的时间和成本了。 2.3.2.2估算不准确罪魁祸首之二：拍脑袋 在估算中拍脑袋的表现就是即兴估算，就是根据个人记忆在未仔细考虑前给出的看似思考分析过的估算值。因为个人记忆常常出现错误，比如并不是记住项目的实际结果而是估算值或者是直觉，所以这种估算也常常出现错误。根据McConnell收集的24组估算人员的即兴估算数据，并对即兴估算的平均误差和经过小组评审的估算结果的平均误差进行比较，见下图： 图4：即兴估算与评审过的估算的平均误差比较图 可见一般的即兴估算的平均相对误差量为67%，而一般评审过的