第四章 估算误差来源

四个方面：

• 有关被估算项目的不准确信息
• 和将实施该项目的开发组织能力相关的不准确信息
• 项目过于混乱而无法为准确估算提供有效支持（也就是说，试图对有变动的目标进行估算）
• 估算过程本身带来的误差

4.1 估算不确定性的来源

一幢新房子的成本是多少？这取决于房子本身。一个Web站点的成本是多少？这取决于这个站点。在清楚地理解了每个详细的特性之后，才能准确估算软件项目的成本。在对“某事物”进行准确定义之前是无法估算构建该事物所需的工作量的。

软件开发是一个逐步精炼的过程。你从一个大致的产品概念（待构建软件的愿景）开始，然后根据产品和项目目标来细化该概念。有时候估算的目标是交付特定量的功能所需的成本和时间。其他一些时候的目标是估算在预定的时间和确定的预算限制下能够实现多少功能。还有许多项目是在成本、进度和功能方面都有一定灵活性的令人愉快的环境中进行的。在任何一种情况下，实现软件的不同途径都会让最终的成本、进度和功能出现巨大的差异。

假设你正在开发一个订单录入系统，而与录入电话号码相关的需求还没有定下来。从需求活动到发布的过程中会有许多可以影响到软件估算的不确定性因素，例如下面这些：

从这个简短的不确定性清单中可以看到，对任何给定的特性，在如何说明、设计和实现单个特性上的潜在差异可以导致在实现时间上累积产生100倍以上的差异。考虑到大型特性集中有成百上千个特性，而每个特性都存在这样的不确定性，其结果就会导致项目本身存在的不确定性非常之大。

4.2 不确定性锥

软件开发要对4.1节中描述的特性相关的事项逐个制定数千个决策。在制定这些决策时可能出现的不确定性会导致软件估算中的不确定性。随着这些决策的制定，特定的选项会减少，估算的不确定性就会降低。

软件估算的准确度取决于对软件定义的细化程度。定义越细化，估算就越准确。估计值中存在可变性的原因在于软件项目本身就存在可变性。减少估计值中的可变性的唯一方法是减少项目的可变性。

4.3 混乱的开发过程

不要期望单纯采用更好的估算实践就能为混乱的项目提供更准确的估算。不可能准确估算一个失去控制的过程。作为起始步骤，消除混乱比改善估算更重要。

4.4 不稳定的需求

许多报告指出，需求变更是产生估算问题的常见来源。不稳定的需求会带来各种挑战，包括两个关于估算方面的特定挑战。

第一个挑战是不稳定的需求代表了特定方式的项目混乱。

第二个挑战是由于未常常对需求变更进行跟踪，项目往往没有在需要的时候被重估。在增加新需求或修改旧需求时，就要对成本和进度估算值进行修正来反映这些变更。而实际上，项目经理常常会在需求变更时忽略了对有关成本和进度的假设进行更新。

4.5 遗漏的活动

被遗漏的工作主要有3类：遗漏的需求、遗漏的软件开发活动和遗漏的非软件开发活动

在持续时间长于数周的项目中，同时也要为休假、病假、培训和公司会议等活动的开销留出空间

4.6 没有理由的乐观主义

不要减少开发人员给出的估算值——他们可能已经过于乐观了

乐观主义同样影响到管理层。项目经理和主管可能不会假设项目可以比实际情况快30%或便宜30%完成，但他们毫无疑问希望项目能更快、更便宜地完成，这本身就是一种乐观主义。

这种乐观氛围的常见表现包括：

• 我们在这个项目中的生产率会比上一个项目高；
• 上一个项目中出了很多问题。这个项目中不会出现那么多的问题；
• 这个项目启动得很缓慢，而且爬上了一个陡峭的学习曲线。我们得到了许多教训，但是所有这些教训可以让我们完成项目的速度比开始时快很多。

4.7 主观性和偏差

主观性以乐观主义、有意识的偏见和无意识的偏见的形式对估算值产生影响。我将估算中的偏差（bias）和主观性（subjectivity）加以区分，前者是指试图将估算向某个方向进行（无根据的）调整，而后者只是指人的判断受到经验的影响，这种影响可能是有意识的，也可能是无意识的。

就偏差而言，客户和管理人员在发现估算值与业务目标不一致时，做出的反应就是从估算值开刀、向项目和项目团队施加更多的压力。在75%~100%的大型项目中会出现过高的进度压力（Jones 1994）。

就主观性而言，在考虑不同的估算方法时，我们自然会认为某种估算方法中的“控制按钮”越多，也就是为了匹配特定项目可以对它进行调整的地方越多，估算结果就会越准确。

事实刚好相反。估算方法中的控制按钮越多，受主观性影响的可能性就越大。问题并不是由于估算者故意让估算值出现偏差，而更多的是由于每个主观输入都会让估算值略微偏高或略微偏低。如果估算方法中有大量的主观因素，最后累积起来的影响就会非常显著。

4.8 即兴估算

人们单纯根据个人记忆进行估算时犯的一个错误是，他们会把新项目和记忆中过去的项目花了多长时间或者需要多少工作量进行比较。然而，人们有时记住的是他们对过去项目的估算值而不是过去项目的实际结果。如果他们使用过去的估算值作为新估算的基础，而过去项目的实际结果是超出了估算值，猜一猜会怎么样？估算者把对新项目的估算值校准到了已造成项目超出的估算了。

4.9 无根据的精度

在随意的谈话中，人们往往把“准确度”和“精度”当作同义词。但对估算而言，两个术语之间的区别是至关重要的。

准确度（accuracy）是指数值离真实值有多远。精度（precision）仅仅是指一个数值有多精确。在软件估算中，精度等同于估算值中有多少位有效数字。一个测量值可能很精确但不准确，也可能准确但不精确。以圆周率为例，数字3是只有1位有效数字的准确表示，但不精确。而3.37882虽然是比3更精确的表示，但却没有它准确。

航班时刻表精确到分钟，但它们并不准确。按整米数来表示人的身高会很准确，但根本就不精确。

对软件估算而言，准确度和精度之间的区别至关重要。项目干系人会根据表示估算值的精度来做出有关项目准确度的设想。当把估算值表示为395.7天时，干系人会设想这个估算值准确到了4位有效数字！因此，估算需要1年、4个季度或者13个月而不是395.7天可能可以更好地反映估算值的准确度。使用395.7天而不是1年的估算值，就如同使用3.37882来表示圆周率——数字的精度更高，实际上却更不准确。

应该让估算值中有效数字的位数（它的精度）和估算值的准确度相匹配

4.10 其他的误差来源

• 不熟悉的业务领域
• 不熟悉的技术领域
• 从估算时间到项目时间的不正确转换（比如，假设项目团队会每周5天，每天8小时完全专注于项目上）
• 对统计概念的误解（尤其是把一组 "最好情况" 估算值或一组 "最差情况" 估算值分别累加起来）
• 破坏有效估算的预算编制过程（尤其是在不确定性锥较宽的部分要求批准最终预算）
• 有准确的规模估算，但在把规模估算转换成工作量估算时产生误差
• 有准确的规模和工作量估算，但在把它们转换成时间进度估算时产生误差
• 夸大了新开发工具或方法所能节省的成本
• 在管理层层层上报或进入预算的过程中对估算值的简化，等等