【软件开发】软件估计的不确定性锥介绍

目录

• 软件估计的不确定性锥介绍
• 缩小不确定性的范围
• 不确定性锥与承诺之间的关系
• 不确定性锥与迭代发展
• 相关资源

不确定性锥简介

在项目的早期，要构建的软件的性质的具体细节、具体需求的细节、解决方案的细节、项目计划、人员配置和其他项目变量都不清楚。这些因素的可变性导致了项目估计的可变性——对可变现象的准确估计必须包括现象本身的可变性。随着对这些可变性来源的进一步调查和确定，项目中的可变性会减少，因此项目估算中的可变性也会减少。这种现象被称为“不确定性锥”，如下图所示。如图所示，在项目总日历时间的前20-30%期间，不确定性锥显著缩小。

Figure 1 The Cone of Uncertainty?

横轴包含常见的项目里程碑，如初始概念、批准的产品定义、需求完成等。由于其起源，这个术语听起来有点面向产品。“产品定义”只是指商定的软件愿景或“软件概念”，同样适用于web服务、内部业务系统和大多数其他类型的软件项目。

纵轴包含在项目中各个点由熟练的估算人员创建的估算中发现的误差程度。估计可以是特定功能集的成本和交付该功能集所需的工作量，也可以是特定工作量或时间表可以交付多少功能。本书使用通用术语“范围”来指代项目的工作量、成本、功能或某些组合。

从图1中可以看出，在项目早期创建的估计值有很大的误差。在初始概念时间创建的估计可能不准确，高侧为4倍，低侧为4×（也表示为0.25x，仅为1除以4）。从高估计值到低估计值的总范围是4倍除以0.25倍，即16倍。

缩小不确定性的范围

经理和客户会问的一个问题是，“如果我再给你一周的时间来做你的估计，你能完善它吗？”这是一个合理的要求，但不幸的是，不可能满足这个要求。研究发现，软件估计的准确性取决于软件定义的细化程度。定义越精细，估计就越准确。估计包含可变性的原因是软件项目本身包含可变性。减少估算可变性的唯一方法是减少项目本身的可变性。

一个重要但困难的概念是，不确定性锥代表了在项目中不同点的软件估计中可能具有的最佳情况准确性。Cone表示由熟练的估算者产生的估算误差。做得更糟很容易。再准确不过了；只有更幸运的可能。

Cone代表最佳情况估计的另一种方式是，如果项目没有得到很好的控制，或者如果评估人员不是很熟练，估计可能无法改善，如Cone所示。图2显示了当项目没有以减少可变性的方式进行时会发生什么——不确定性不是Cone，而是持续到项目结束的Cloud。问题并不是估计值不一致；问题是项目本身没有收敛，也就是说，它没有排除足够的可变性来支持更准确的估计。

Figure 2 The Cloud of Uncertainty

只有当您做出消除可变性的决策时，“圆锥体”才会变窄。如图3所示，定义产品愿景（包括承诺你不会做的事情）可以减少可变性。定义需求——再次包括您不打算做的事情——进一步消除了可变性。设计用户界面有助于降低因误解需求而产生的可变性风险。当然，如果产品没有真正定义，或者产品定义后来被重新定义，那么Cone会变得更宽，估计精度会更差。

Figure 3 Forcing the Cone of Uncertainty to Narrow

不确定性锥与承诺之间的关系

软件组织在不确定性锥中过早地做出承诺，无意中破坏了他们自己的项目。如果一个组织在初始概念或产品定义时做出承诺，其估计误差为2到4倍。在项目中过早做出的承诺会破坏可预测性，增加风险，增加项目效率低下，并削弱项目管理的能力。

在锥体早期广泛的地区不可能作出有意义的承诺。有效的组织推迟其承诺，直到他们完成了迫使锥缩小的工作。在项目的早期和中期（约占项目的30%）做出有意义的承诺是可能的，也是适当的。

不确定性锥与迭代发展

不确定性锥在迭代项目中的应用比在顺序项目中更为复杂。

如果您正在处理一个项目，该项目在每次迭代中都有一个完整的开发周期——也就是说，从需求定义到发布——那么您将在每次迭代上经历一个小型Cone。在你为迭代做需求工作之前，你将在Cone的“批准的产品定义”部分，从高到低的估计值有4倍的可变性。通过短迭代（不到一个月），您可以在几天内从“批准的产品定义”转变为“需求完成”和“用户界面设计完成”，将可变性从4倍减少到1.6倍。如果您的时间表是固定的，1.6倍的可变性将适用于您可以在可用时间内交付的特定功能，而不是工作或时间表。

对于在每次迭代开始之前都没有定义需求的方法，您放弃的是对成本、进度和功能组合的长期可预测性，您将在未来交付几次迭代。你的企业可能会高度重视这种灵活性，也可能更喜欢你的项目提供更多的可预测性。

许多开发团队都选择了中间立场，其中大多数需求都是在项目的前端定义的，但设计、构建、测试和发布都是在短时间内完成的。换句话说，项目依次通过用户界面设计完成里程碑（大约占项目日历时间的30%），然后从那时起转向更迭代的方法。这将Cone产生的可变性降低到约±25%，这允许足够好的项目控制来实现目标，同时仍然利用迭代开发的主要好处。项目团队可以在项目结束时为尚未确定的需求留出一些计划时间。这引入了一点与功能集相关的可变性，在这种情况下，这是正可变性，因为只有当您确定要实现的理想功能时，您才会使用它。这种中间立场支持成本和进度的长期可预测性，以及适度的需求灵活性。