估算偏差及管理（转与Rational Edge）

估算偏差及管理

文档选项

将此页作为电子邮件发送

拓展 Tomcat 应用

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1
级别: 初级
Murray Cantor, 杰出工程师, IBM
2006 年 3 月 15 日
本文来自于 Rational Edge：软件开发项目最初的不确定性是经验丰富的项目经理所熟知的，但在估算项目成本及时间进度时常常假设不存在这些不确定性。本文将探究忽略这些偏差的后果，并提出一个减少偏差的数学上的方法，作为估算过程中提供更大准确度的方法。
我最喜欢引用的 Albert Einstein（爱因斯坦）的话是“Keep things as simple as possible, but no simpler”。通过这句话，爱因斯坦告诉我们，虽然朴素是一种美德，但问题的正确解决方案必须涉及所有相关的事实。在本文中，我将此原则应用到准时交付大型复杂开发项目（在预算之内）的问题上，并满足涉众的需求。
开发项目的失败率是众所周知的，并且仍旧没有降低。 1 尽管一贯存在超过预算、项目推迟的记录，而业界却很少采取反映开发的基本事实的实践：在几乎绝大部分的常规项目的开始阶段，完全了解项目的需求是不可能的。因此，高度准确地估算满足需求的工作也是不可能的。事实上，在过去的四十年里，我们了解到项目参数估计的偏差（如进度和预算）是非常高的。
这些项目没有满足涉众需求的真正原因是它们在管理时假设这些偏差不存在。对偏差的忽略大概是因为认为统计太理论了，没有实际意义。这就是过于简化事物的实例。另一方面，包含偏差导致了更好的结果。理论和实践恰当的平衡是关键的成功因素。本文的主题就是达到此平衡。
如我要说明的，项目参数估计中偏差的减少是管理动态系统开发的关键。特别地，我将提出一个将此概念应用到项目管理的实践框架。
说到管理（governance），我的意思是：
建立组织的责任、权限和通信链 执行度量和控制机制，用以有效地推进组织
本文将关注估算对管理的度量及控制部件的偏差的影响。
International Council on Systems Engineering (INCOSE) 手册 2 中对项目风险管理的定义包括技术风险（不能实现系统的技术需求的可能性）及性能风险（不能满足项目成本或进度）。虽然本文中说明的方法一般适用于技术和项目风险，但是技术风险稍有不同，因此我将注意力限制在性能风险上。在之后的文章中将更全面地考虑技术风险及其与性能风险的关系。
本文是写给所有关注软件、系统、产品开发，和集成项目的管理的人。虽然需要一些概率统计估计，用来完全了解此处提出的概念，但是我已经争取将专业内容减小到最少。
作为概述了明确地处理开发项目中不确定性的理论和实际含义的系列文章的第一篇，本文介绍了理论背景并简要地讨论了项目组织、价值及复用的含义，及开发过程分类法。后面的文章将更全面地介绍这些含义。
在项目的开始，不能确定任何事。例如，最好也不过是有根据地推测项目的成本、工作及持续时间。项目估算工具根据可用信息提供工作及持续时间的估计。但是由于对工具的输入是估计的，所以工具的输出也是估计的。
在数学术语中，不完全确定的值称为随机变量。随机变量是一个根据概率分布取值的函数。例如，假设完成一个任务所花费的估计时间值是 3 个月。作为估计，3 个月这个值只能是最可能的值。实际的可能期间是 2.5 或 3.5 个月。不太可能的值是 1 个月或 4 个月。所以任务持续时间不是一个单一的实数，而是描述一定时间范围内完成的可能性的随机变量。
随机变量，如上例中的时间， 与一些特性相关，这些特性不同于那些与单个值相关的特性。取代单个值，随机变量拥有描述估计值可能性的函数，该函数称为变量的概率分布。随机变量的加权平均值是期望值。随机变量的方差衡量随机变量值与期望值偏离的程度。 3 对于许多随机变量来说，一个好的选择是正态分布，常常表现为一个钟型曲线，如图 1 所示。
例如，如果任务的持续时间是正态分布的随机变量，平均值为 3，方差为 1，图 1 中的曲线给出了从 0 到 6 之间取值的概率。这只是无数可能的概率分布的一种。

图 1：平均值为 3 且方差为 1 的正态分布
由于规划更可能超过进度和预算，规划参数的实际分布很可能向右倾斜，更像图 2 中所示的曲线。分布的实际形状可能由应用金融微积分所导出。 4

图 2：规划参数的更现实的分布
实际地说，详述分布的数学描述是没用的。然而，如我下面将讨论的，成功的项目管理需要认识到估计中存在偏差的事实，项目管理的表示包含有用信息的事实，以及应明确描述项目管理的事实。人们可以用随机变量的概念作为比喻，帮助理解项目动态性的思维模型。
在一个或多个区间内的项目计划过程中，认真考虑随机变量是重要的，如任务的持续时间。在数学上，这是绘制在区间之上的分布曲线下面的区域。例如，如果估算的任务持续时间是 3 个月，且方差是 1 个月，那么在 2 到 4 个月完成的可能性如图 3 中所示。在此实例中，落入此范围的可能性大约是 68％。

图 3：方差区间内完成任务的可能性
项目经理必须经常处理风险。在项目的开始，它们获得技术和/或项目参数的估计。那些估计是随机变量。估计的方差是不确定性的度量，其反映出缺乏对有助于项目性能的项目参数的偏差的了解。注意项目参数的估计不确定性由方差提供，不确定性越大，方差越大。例如，项目经理非常确定 3 个月的估计值，分布就可能如图 4 中图形。如果项目经理甚至更确信进度估计，那么分布会如图 5 中所示。

图 4：关于项目参数的标准可信度生成了一个平均值为 3 且方差为 0.5 的正态分布

图 5：关于项目参数的较高可信度生成了一个较紧密的分布，例如，这里平均值为 3 且方差为 0.1。
很明显，随着项目参数估计中方差的增加，成功完成项目的可能性就减少。因而项目参数估计中的高方差对项目来说是高风险的，尽早减少这些方差对项目来说是重要的。
注意到风险的严重程度直接关系到项目参数的估计中的方差。
现在，考虑项目经理如何设置项目计划中的任务持续时间。假设估算的任务持续时间是 3 个月，并且估计的方差是 1 个月。项目经理应如何计划任务？将持续时间设置为 3 个月，项目经理假设任务将在差不多 3 个月内完成，如图 6 中曲线下方区域所示。注意到成功的可能性只有 50％。所以将持续时间设为 3 个月，项目经理在赌注此任务能按期完成。如果计划中有若干任务，每个都是 50％ 的成功几率，全部计划的成功几率是 .5N，N 是关键路径上的任务数量。很明显，这种选择将毁掉项目，如果 N 大于等于 10，成功执行计划的概率小于 0.001。
如果项目经理希望将任务的成功几率提高到，比方说 90％，他必须将持续时间设为 4.3 个月，且要达到 99％ 的几率，持续时间必须为 5.4 个月。当然，对于拥有可接受的风险的项目来说，必须对每个任务都这样做，这将导致几乎将持续时间加倍。执行项目进度以适应所有不确定性在经济上是不现实的。

图 6：完成在正态分布平均值下的现有任务的可能性
很重要的是要注意，如果估计中不存在偏置，那么有可能是一半估算值高，一半低。所以到最后，错误在某种程度上消除了。通常，缩减量随着系列中术语的数量的平方根下降。此现象称作方差的减少（reduction of variance），意思是最终日期是可以达到的，即使没能按照实际计划。
这是过程工程的古老格言，您可以只控制您测量的内容。存在两种软件开发和整合规划的度量和控制的方法：
计划及跟踪 —— 在一开始确定所有的项目活动，衡量规划是否依照预设的计划，并且重置活动以回归计划 迭代开发 —— 设置初始的规划里程碑，并计划一组增量地达到所交付解决方案的规划交付产物
项目通常采用计划及跟踪方法，有时概括为“计划您的工作并执行您的计划”。该方法要求在项目的开始就知道所有的任务及其持续时间。该方法基于一个隐含的假设，即可以肯定地做出计划：也就是，持续时间的方差非常低。如上面所讨论的，如果偏差小的话，团队只能创建并遵守该计划，因为通过选择高估计值来减小风险是不可接受的。因此，计划及跟踪方法只对风险非常低的项目是实用的。
尽管如此，计划及跟踪方法还经常应用于高方差的项目中，通常导致令人失望的结果。以上对项目参数的统计学特性的讨论说明了为什么：对于复杂项目，当方差大时，为了低风险地执行计划而把任务持续时间设置的足够长是不可接受的。另一方面，可以将此方差忽略。回到此实例，如果估算中的方差是 0.1，任务的 90％ 的可信度的日期是 3.15 个月并且 99％ 的可信度日期是 3.3 个月，在持续时间上只有 10％ 的增长。
要点在于：即使，在项目的开始，最初的方差是好的，可以对项目进行管理以便在项目的早期去掉不确定性，使得方差很低。事实上，项目成功的关键是尽可能早地去掉不确定性，这导致制定精确且积极的计划的能力增加。然而，由于减少方差的能力是基于通过项目经验获得的知识的，所以计划及跟踪管理方案不是很适合管理带有风险的项目 —— 即带有高初始方差的项目。
上面的例子使用了正态分布。然而，对所有的分布效果是一样的（对数正态分布，三角分布等等）。当然，实质上对成本和工作的估计可以应用同样的推理。成本和工作是随机变量，需要在项目生命周期中减少它们的方差。
在下面的部分中，我将介绍估算偏差的削减是如何用作指导迭代开发控制的关键量度的。
在开发项目的开始阶段，存在项目不确定性。交付产品的成本和时间存在不确定性。可能存在关于技术参数的不确定性，如项目交付产品的可靠性。不确定性的数值常常反映团队在提出的问题和解决方案中认识到的新颖性的程度，包括要交付的系统、产品，或服务的新颖性。
如上面所讨论的，项目和技术参数是随机变量，而方差会随着项目生命周的演进减少。很容易看到，项目的最开始，所有变量的方差都是高的，并在最后项目快完成时降低了。
为了继续下去，我们需要有用的团队知识的概念 —— 也就是，扩展的开发团队（核心团队，涉众，和供应商）成功地完成项目所需要的信息。有用的知识的实例包括涉众需求及优先权、有效的设计方法、要应用的技术，和内部及外部依赖。
风险排除曲线的推导示例遵循两个假设： 5
规划参数方差（V）与有用的团队知识（K）成反比，即：规划知识随着至今所获得的有用的团队知识而增长。获取的比例与知识分享中的协作工作（Cs）的系数成正比（例如，知识增值的系数）。因此，我们有了此微分方程：
解微分方程产生了

因此，知识随时间按指数增长，由知识 K 开始0。 6 这意味着复用知识来创造新的知识。不论教训及经验是什么，知识总是可再用的，他的价值从来不减少。
因此，

V0是初始方差。
系数 Cs 对应组织在获取知识时的整体有效性。“有效”的实际量度是时间和组织内聚性的函数。一般，Cs 与指数参数成正比，用来衡量在许多估算模型，如 COCOMO II，中发现的非规模经济。换句话说，合作的越多，传播知识的机会就越好。因此，由于在新知识的获取方面进行合作交流，方差随着时间减少了。
由此可见，成功项目中参数的方差近似于图 7 中所示的指数下降曲线。Scott Mathews 在实证研究 7 和更严格的理论分析中还找到了此曲线的证据。 8

图 7：风险排除曲线
实际上，十多年的经验表明，不论组织所实践的生命周期方法是什么，成功的项目经理都能在项目开始时确定出风险，并凭直觉管理它们的项目，以便项目变量遵循图 7 中所示的曲线。有时候，明确地这样做，有时候“暗地里”完成。
理所当然的是，最初，项目会有极度的新颖性及大方差，在成功项目的末尾，方差接近 0。在本文余下的部分中，我们将探究这一观察结果的一些暗示。
现在我们讨论如何管理一个符合风险排除曲线的项目。回答是进行两个活动：
估计项目的成本、工作，和持续时间，以及其方差 采用循环控制迭代生命周期模型，将项目方差用作一个控制器
我们将依次说明这些活动。
估计方差
要想将上面所讨论的所有内容都成为可实行的，团队必须找到一个计算项目参数方差的方法。一个广为接受的预测工具，Delphi 估计，为项目参数及其方差的估计提供了健壮实用的预测方法。Delphi 方法提供一个系统的交互预测方法，关注并量化项目领导的判断力。它是由 RAND Corporation 于 50 到 60 年代开发的，并考虑了专家意见、经验，和直觉的值。
要应用此方法，项目经理要将工作进行划分，然后让负责各部分的团队提供三个估计：
EL = Lowest Value（最好的情况）
EN = Nominal Value（期望的情况）
EH = Highest Value（最坏的情况）
这些估计可以用于所有参数：例如，工作或进度。
依据团队的经验和项目的新颖性程度，这些估计差不多是正式的。可以用项目阶段或一些工作划分（例如，用组件开发团队），或两者都用，来进行分割。甚至可以使用单个分区的平凡的情况。然而，使用的分区越多，计算的越理想，因为以下三个理由：
通过包含更多条件来减少统计误差。 分区可以让更多的团队成员对他们最熟悉的工作部分应用评价。 每个团队都可以应用最适合它们那部分工作的估计方法。例如，子团队可以通过变更拥有乐观、标准，和悲观值的参数并将计算值用作 Delphi 方法的输入，来应用参数化的方法，如 COCOMO。
期望的整体估计（E）值是加权平均值

此和值覆盖所有分区。方差（V）为：

Delphi 方法的重点是它反映出项目中固有的不确定性。不确定性是由开发人员输入的，作为最佳和最坏情况间的差异，或 EL 和 EM。如果差异很大，那么项目经理就知道其团队感觉该组件有成比例的风险。项目经理应进一步探测，确定来源，并计划一组提升团队信心的活动，以便随着时间的推移，他们可以在估计中报告更小的方差。
迭代开发控制循环
在工程中，控制循环的使用对测量中拥有高方差的系统的管理是很平常的。例如，弹道导弹和更精确的巡航导弹之间的差异是后者使用位置及常数航向修正的测定来打击目标。进一步类比，计划及跟踪方法是弹道导弹的到达目标的方法，迭代开发是巡航导弹的方法。
这里是关键原则：
应该用控制循环来管理项目，促使项目方差为零。
由于不可能在项目开始时知道如何减少之后任务的偏差，就必须要采用迭代的方法。
如图 8 中所示，管理人员计划了一系列控制点（成为迭代），并在每个迭代中，根据关键变量及其方差来评审项目状态，并调整活动和资源分配，以促使项目成功。

图 8：项目治理控制循环
这样，项目经理就可以利用所了解的经验来为项目创建反馈循环。
迭代方法在开发实践中的结构良好。一般地，迭代方法追踪针对计划的项目工件（通常部分实现要交付的产品或系统）中的明确的发展。如果在迭代边界内项目没有按照计划交付工件，那么就重新设置活动及人员分配。此经典的迭代方法，虽然有力，但有一个欠缺：为每次迭代计划正确的内容更像是艺术而不是科学。经典的方法缺少推动控制循环的装置。
通常的方法是为去掉风险来计划迭代。如上面所提到的，设计去除风险，以便项目遵从图 6 中所示的曲线的迭代计划的能力是检验高效的项目经理的标志。交给糟糕的项目经理，迭代开发将遭受冲击波作用：早期的迭代描述简单的材料以致这些迭代没有真正的去掉失败的风险。事实上，好的迭代实践首先描述项目的困难（有风险的）面。
图 7 中所参考的额外量度标准应该包含财务和质量量度。如何选择那些度量标准的讨论出现在别处。然而，重要的是，注意它们在推进迭代内容的工作中扮演重要角色。
注意选择度量标准的指导原则是它们怎样影响具体项目参数的方差。例如，与项目成本或持续时间无关的度量标准不能帮助评估迭代中的方差削减。
因此，项目管理方法应包含，但不局限于：
所达到的进展测量 去除的风险测量，即，减少关键项目度量标准的方差 达到其他度量标准的目标
迭代计划用来交付、去除风险，并追踪额外的目标。在早期的迭代中去除风险会提高后面迭代和项目成功的可能性。
管理及团队行为随着遵从风险曲线（如图 7 所示）的项目在生命周期中的进行而变化。如图 9 所示，将生命周期划分为不同风险阶段，为了描述期望的团队行为和有效的管理方法，是很有用的。我们将在下面更完整地讨论这些阶段。
如图 9 所示，项目粗略地分为三个阶段。

图 9：项目生命周期可以分为三个风险阶段。
每个阶段表示方差缩减中的 80 各百分点。也就是说，在阶段 I 的末尾，去掉了 80％ 的方差。在阶段 II 的末尾，去掉了余下风险的 80％。还要注意到风险阶段与 Rational Unified Process（RUP）生命周期阶段结合的很好，如图 10 中所示。 9 RUP 原则和基于阶段的活动提供对如何计划并执行项目的良好指导。

图 10：Rational Unified Process
风险去除（Risk Removal） 阶段中项目的关注点是尽早地提出那些导致最初最高的方差的风险。此阶段中的典型风险包括范围及/或技术方法，以及团队能力的不确定性。在此阶段末尾，应该去掉了项目方差的 80％，此阶段末尾的方差应该将近 20％。
此阶段包含 RUP 起始（Inception） 和精化（Elaboration） 阶段。回想在起始（Inception） 过程中，团队获得对整个范围的一致意见，并在精化（Elaboration）过程中，达成了解决方案方法的一致意见。
由于此阶段着重于做出减少风险的好决策，团队必须以自由的形式合作。因此，团队的活动不好由事务工作流描述。相反，从系统原理中流露出的管理技术更恰当。此阶段的工具很好地支持团队决策。
此阶段着重于去掉余下风险的 80％，以便在此阶段的末尾，方差应大概为 4％。此阶段与 RUP 构建（Construction） 阶段相联合，在此期间，主要的焦点是执行风险。在 构建（Construction） 过程中，团队在迭代中应用阶段方案方法。此阶段是以一个能正常工作的，已测试的，准备迁移到客户端的系统为结尾。在此期间，团队应该是构建良好的。虽然工作流不完全是自动化的，但是可以精心编制大量工作。工具能够支持执行工作流。
此阶段完成了项目。它与 RUP 移交（Transition） 阶段相结合，包括将解决方案揉进“产品”中。在此阶段过程中，活动应该是高度可处理的，主要关注于变更管理，以便不引入新的风险。
在此部分中，我将介绍采用方差治理方法的一些暗示。在之后的文章中将展开这些主题。
经典的风险管理方法包括规划设计人员进行头脑风暴对话，确定项目的风险，它们的可能性（高、中，低），影响（高、中，低），和缓解计划。可能性和影响的结合用于优先化。在项目的过程中，追踪风险及其缓和计划。在此方法中，风险管理和关键项目测量的关系是纤细的。风险属性（可能性及对成功的影响）及其状态至多是共识的问题，且与管理标准不相关。
此规程，尽管有其好处，但不能普及。在许多情况下，风险管理过程更类似危害，常常不过是对过程担保组织的顺应。一种可能的低价值的原因是风险管理活动与其他管理活动分离。这中分离可以使风险管理作为项目附件来出现，不是对项目有利的核心活动。
反之，风险是向项目方差中加入的某个条件。重新考虑以此观点的风险管理实践为项目管理提供了更严格且更有价值的方法。
由此可见，去掉项目偏差是准确地风险去除活动。此外，利用 Delphi 方法，团队可以量化风险的影响。特别地，团队可以估计三个值 —— 最低、标准和最高估计值 —— 交涉去掉了风险，并且应用这些值重新估计项目方差。该实行的输出是对风险及其缓解的效果的测定。
采用此方法将风险管理与项目治理统一起来。
项目常常是在合同的基础上进行构建的，并以竞标过程开始。在此情况中，项目团队开发标准项目参数的估计，并围绕这些参数为项目出价。较有经验的项目经理会提高出价来引起偏差。此实践在有信心交付和竞争之间建立了牵引力。提高出价以引出估计中的不确定层次将可能使提案是非竞争性的。当客户强调可能充满不确定估计的详细的项目计划时，此问题是混合的。
最后，团队获得竞标会留给他们一个有风险的项目，很可能失败或至少没有利益。
另一种方法是让客户及合约团队在项目的开始共享对方差及其原因的了解。多数偏差是由于包含客户的因素引起的。然而客户及项目团队可以一起协作排除偏差。团队的方法，对风险的了解和分享是诚实沟通的基础。 11
无可否认，采用此方法，虽然合理，但背离了当前的合约实践。基于偏差的获取方法要求合同包含分阶段的获取。取代为整个项目签合同，而每次在一个阶段内商讨联系。合约阶段应与风险阶段或 RUP 阶段结合起来。注意到 US Department of Defence 5000.x 采用此分阶段的方法来处理其有风险的项目。
金融分析团体已经将 Black-Scholes 推理（为确定金融投资选择的价值）扩展为称作 Real Options 的技术，它能够估计对一些东西投资的价值，这些东西可能在未来提供某种价值。Real Options 方法对待估计中的方差类似于 Black-Schole 方程中的变动性。
Real Options 方法可以用于在开发项目开始时确定其价值。本质上说，项目的价值是预期利益的需求选择价值。例如，Vinay Datar，西雅图大学金融和经济学副教授，和 Scott Mathews，Boeing Phantom Works，已经开发了 Real Project Value（RPV）， 瞄准产品开发的 Real Options 变量。 12 明确地讲，开发工作的 RPV 是按照购买完整项目的利益的需求选择计算的。这些方法一般应用于开发项目中。
遵照 Datar、Mathews 方法，随着风险的去除，项目价值也增加了。特别地，在大量减少风险时，大部分项目价值在早期阶段生成。此结果与 Pareto 的 Law 一致，80% 的价值由 20% 的工作生成。
关于对价值创建的评论的推论是那些能够成功管理有风险的项目的组织创建最大的价值。
在较早的部分介绍了风险削减等式

引出了明显的矛盾：
增加 Cs 提高了降低偏差的机会，但也降低了生产率。
减少方差需要协作，但较多的协作导致员工花费较多时间交互，而很少的时间生成规划工件。
矛盾的分解要求必须构建并简化协作，用以增加知识而因此减少偏差。不导致偏差降低的协作会导致工作的浪费。因此，在构建团队时，规划经理必须确保协作是多产的。一些考虑包括：
确保技术责任就位，考虑知识的封装。每个人不需要知道所有事情。 创建并维护通信途径。 为获取并共享与规划相关的知识创建所需的基础架构。 为了更准确地沟通，用恰当的语义和实体论来培训团队。
使协作具有生产性的细节将是后面文章的主题。目前，值得说一句的是，在不同的风险阶段中协作风格是变化的。
接受风险并在有风险的项目中取得成功的能力是开发团队如何创造价值的表现。竞争的途径完全包含并处理风险，它不忽略或避免风险。拒绝风险的团队将做一些无价值的日常工作。最终这些团队发现自己陷入价格漩涡中。了解了关键变量的方差对项目的影响之后，可以通过以下方式治理项目
采用计划和跟踪管理方法，并且超出进度来计算偏差，或者 采用控制循环管理方法，该方法将项目活动集中在通过去掉项目早期的不确定性来对方差的减少上。
第二种方法为成功铺平了道路。
感谢 Michael Mott、Vasco Drecun、Scott Mathews、David Lubanko，和 James Cantor 对本文准备工作的帮助。
Murray Cantor，Software Leadership。Addison Wesley 2002 年。
Murray Cantor、Scott Mathews、Vasco Drecun，“Real Metrics to Drive Product Development”。Preprint 2005 年。
Vinay Datar 和 Scott Mathews，“A Simple Algorithm for Valuation of Real Options: An Intuitive Alternative to the Black-Scholes Formula”。 Journal of Applied Finance，已出版。
INCOSE System Engineering Handbook。版本 2a。2004 年 6 月。
Per Kroll 和 Philippe Krutchen，The Rational Unified Process Made Easy。Addison Wesley 2003 年。
Walker Royce, Software Project Management。Addison Wesley 1998 年。
Walker Royce，“Successful Software Management Style: Steering and Balance”。IEEE Software，2005 年 9 月 —— 10 月。
Steve Tokey，Return on Software。Addison Wesley 2005 年。