第十七章 标准化估算规程

标准化估算规程就是在开发组织一级采用的定义好的估算过程，它可以为单个项目的估算提供指导。标准规程可以避免诸如即兴估算和猜测之类的不良估算实践的影响，可以避免由于某个强势的干系人不喜欢某一结果而任意改变估算值，还可以促进整个机构采用一致的估算过程。而且，在出现特别不良的估算时，它们还有助于对估算步骤进行回溯，以便逐渐改进估算规程。

标准化规程对大型项目、小型项目、迭代式项目和顺序式项目都同样有用，但是细节情况在各类项目中会有所不同。

17.1 标准化规程的常用要素

标准化估算规程通常包括：

• 强调尽可能应用计数和计算方法，而不是使用判断；
• 要求使用多种估算方法，并对结果进行比较；
• 协商在项目预定时候进行重估的工作计划；
• 定义如何根据项目的进程改变要求采用的估算方法；
• 包含对估算值的不准确程度的清楚说明；
• 定义何时可以使用某个估算值作为项目预算的基础；
• 定义何时可以使用某个估算值作为内部和外部承诺的基础；
• 要求存档估算数据，评审估算规程的有效性。

标准化估算规程要起作用，很重要的一点是开发组织必须把这个规程当做标准来执行。背离该标准的情况必须有书面材料证明其必要性，而且应该很少发生。

17.2 采用阶段-门槛过程进行估算

SDLC（软件开发生命周期）

从估算的角度来看，阶段-门槛过程既带来了机会也带来了挑战。出现挑战通常是因为许多阶段-门槛过程最初是为硬件产品、消费产品或者其他非软件产品建立的。虽然这些过程的基础框架可以用于软件项目，但需要根据软件开发的要求对它们进行改造，才能使它们在软件项目中也能像在其他类型的产品开发中一样起作用。

一个常见的挑战是，开发往往被作为单独的阶段列出（如表17-1中的阶段3）。在开发阶段进行的活动占整个软件项目总工作量的75%~90%，所以我通常希望在这个阶段中可以看到更多的标志来显示项目的进展，而不是只能在整个开发阶段结束到达唯一的那个门槛时进行评审。无论开发组织是否鼓励在某个阶段中进行重估，都应该在该阶段中周期性地对估算值进行修正，以便为项目计划和控制工作提供有效支持。

第二个常见问题是，表17-1中定义的确定范围和计划两个阶段常常被合并成一个阶段。这种做法的主要影响是使3号门槛出现在不确定性范围缩小到±25%时，可能是项目进行到总日历时间的15%~35%之间的任何时候。（第21章“计划参数的估算”将更详细地讨论这些百分比。）常常需要向非技术领域的干系人解释，为了支持有意义的“3号门槛”评审所需完成的软件开发活动的范围。这些活动的数量和深度常常超过了他们的预期。

17.3 顺序式项目的标准化估算规程

假设开发组织认为软件的特性集最重要，估算的主要目标是提高成本估算值和进度估算值的准确度。

• 强调尽可能使用计数和计算方法，而不是使用判断
• 要求使用多种估算方法，对结果进行比较
• 协商在项目预定时候进行重估的工作计划
• 定义如何根据项目进程改变需要的估算方法
• 包含对估算不准确度的清除说明
• 定义何时可以采用估算结果作为项目预算的基础
• 定义何时可以使用估算结果作为内部和外部承诺的基础

17.4 迭代式项目的标准化估算规程

17.5 一个高级开发组织的标准化估算规程

17.6 改进标准化规程

在每个项目完成后，应该从7个方面评估估算活动的有效性：

• 估算结果有多准确？
• 范围是否足够宽？能否缩小它们但仍然可以容纳那些已经发现的可变性
• 估算值是倾向于偏高、还是偏低，或者误差是两个方向皆有的？
• 会否有对估算产生影响的偏差来源？
• 哪种估算方法产生了最准确的估算结果？这些方法通常都会产生最准确的估算结果，还是只是这次碰巧产生了最好的估算结果？
• 是否在恰当的时候进行了重估？重估的次数过多、过少还是刚好？
• 估算过程是否过于精细？如何在不牺牲准确度的条件下对它进行简化？