第一章 估算的关键概念

楔子

管理人员

管理层的合理预期是使软件估算结果在一个可以控制的范围之内，即管理下限和管理上限之间。如果今后的项目执行情况都能够落在这个区域，那么就意味着是可控的；而如果有大量的数据点都落在管理上限之上，或管理下限之下，就意味着控制性很差。

项目经理

如果你是一名项目经理，首先要理解在项目初期，估算的结果是一个靶子，而不是马上给出一个靶心，也就是说得到的结果应该是“需要30~40个人月，最可能的值是36个人月”，而不是精确的35.2个人月。如果对这个概念还有些模糊，建议你回头看看上一小节，理解理解“管制图”的概念，不管怎么说你也是一个“经理”，算是个管理岗位吧！

除此之外，还需要建立几个关键的理念，而如果你开始有了点感觉，那么就不要等待，马上翻开正文，让自己接受一次全新的思维洗礼吧。

1.总估算值不能谈判，只对单个估算项进行修改

你向高级管理人员汇报，整个项目要5个月的时间，但却被要求只能3个月完成！然后基于这个数字展开的讨价还价的场景，怎么听怎么像在菜市场。这既不是一个严谨态度，也没有采用科学的方法！

问题出在哪里呢？想想工程预算（诸如家装）时，你要调整整体造价时，不会直接修改总价吧！该怎么做，谁都知道应该修改某个单项预算，因为总价是用公式自动累加出来的嘛。因此要想避免前面说到的问题，就应该提供包含各种单项预算的表格，当高级管理人员需要减少时间时，要商量的就是去掉哪些单项。放心吧，高级管理人员早在年度预算会上就适应这种模式了。

2.估算不是玄学

3.经验数据是提升估算准确率的关键

经历并不意味着经验，这是我常挂在嘴边的一句话，放在估算领域也是如此。许多项目经理、开发人员虽然早已身经百战，但每当遇到新的开发任务时，却仍然由于没有经验数据而难以给出较好的估算，甚至连自己的产能都不太了解。

估算的结果需要进行校准，才能够更加准确。而最无奈之举则是使用估算模型提供的行业平均数据进行校准，要想真正有效就必须收集、记录自己的经验数据。本书不仅指出了应该收集、记录哪些数据，还指出了项目初期的数据能够用来修正项目中、后期的计划，这一理念必将为你的“经验数据收集工程”注入强有力的引擎。

4.分解是复杂性的克星

对于任何复杂的问题，都可以借助“分解”这一伟大的工具来应对。因此 WBS （Work Breakdown Structure，工作分解结构）分解的质量对于估算而言意义重大，而仅从软件开发过程的阶段、活动来划分是不足以支撑估算的；

因此必须从软件开发的产物（诸如用例、用户故事）的角度进行分解，这样才能为估算奠定良好的基础。因此将需求开发的输出作为 WBS 的基础，让负责具体实现的开发人员对每个单项进行估算，然后在此基础上进行累加、考虑缓冲、重组，最后才能够得到真正合理的估算结果。

5.估算的问题不仅困扰你一个

第一部分 估算的关键概念

第一章 估算的含义

估算在字典上的定义是：

1．试验性的估价或粗略的计算。

2．对项目成本的初步计算。

3．基于印象做出的判断；看法/意见。

当别人要求你给出估算结果时，他是否希望得到符合上述定义的结果呢？他要求你给出的是否就是尝试性的（tentative）或初步的（preliminary）计算结果——也就是说，你是否希望以后还可以对现在给出的答案进行修改（如果是做出承诺，以后就不能改变了，译者注）？

也许别人想得到的并不是上面定义的那种估算。当主管要一个“估算值”时，他们要求的往往是一个承诺或者是达到某个目标的计划。

1.1 估算、目标和承诺

严格地说，字典上对估算（estimate）的定义是正确的：估算就是对项目将持续多长时间或将花费多少成本的预测。但是软件项目中的估算与业务目标、承诺和控制之间存在着相互影响。

目标（target）描述了期望达到的业务目的。下面是几个目标的例子：

我们要准备好 2.1 版，以便在 5 月份的展览会上进行演示。”

“我们要及时做好这个版本的发布准备，以便满足节假日销售季节的需要。”

“必须在 7 月 1 日之前完成这些功能，这样才能符合政府的相关法规。”

“我们必须将下一版本的成本控制在两百万美元以内，因为可以提供的最大预算额度只有那么多。”

目标描述的是期望达到的业务目的，而承诺（commitment）则是许诺在特定日期之前以特定质量水平交付规定的功能。承诺可以与估算相同，可能比估算更激进，也可能比估算更保守。也就是说，不要假定承诺必须和估算是一样的；它们是不相同的。

区分估算、目标和承诺。

1.2 估算和计划的关系

估算结果构成了计划的基础，但计划并不一定要与估算结果相同。如果估算结果与目标之间存在显著的区别，进行项目计划时就要认识到两者之间的差距，并考虑可能存在较高的风险。如果估算结果接近于目标，在进行计划时就可以认为风险较低。

下面这些在计划中要考虑的问题在一定程度上依赖于准确的估算：

• 建立详细的进度表
• 确定项目的关键路径
• 建立完整的工作分解结构
• 确定要交付的功能的优先级
• 将项目按多次迭代进行分解

1.3 有关估算、目标和承诺的沟通

在这次谈话中，项目负责人在离开时很可能会认为这个主管失去理智了，因为他要求团队在3个月时间内交付需要5个月工作量的功能。而主管在离开时会认为项目负责人没有“认清”业务现实，因为他没有理解在3个月内为展览会做好准备有多么重要。

请注意这个例子中的主管并不是真的要得到一个估算值，其实他是要求项目负责人提出一个实现某个目标的计划。大多数主管都不具备必要的技术背景，无法区分估算、目标、承诺以及计划之间的细微差别。因此，技术负责人就要负责把主管提出的要求翻译成更为明确的技术术语。

对于前述的沟通过程，可以采用如下更为有效的方式：

当有人要求你提供估算值时，要确定他是期望你进行估算还是期望你给出如何达到某个目标的计划。

看到单点“估算结果”时，要问清楚该数字是一个估算值还是一个事实上的目标。

1.4 以概率的方式表示估算结果

看到单点估算值的时候，应认识到该数值的概率并不是 100%。要问清除该数值的概率。

1.5 对 ‘良好’ 估算的常见定义

1986 年，S. D. Conte、H. E. Dunsmore 和 V. Y. Shen 三位教授提出：一个良好的估算方法应该在 75% 的时间内都能提供与实际结果相差不超过 25% 的估算结果（Conte, Dunsmore, and Shen 1986）。这一标准是用于评价估算准确度的最常见的标准（Stutzke 2005）。

1.6 估算与项目控制

有时，大家在讨论软件估算时会把估算当作是纯粹的预测活动，就好像是由一个端坐在太空的公正估算者来进行估算，而与项目计划及确定优先级的活动没有任何联系。

实际上，软件估算中没有什么是完全不受其他事情影响的。一旦做出了估算，并且在此估算的基础上承诺在特定日期之前交付具有一定质量的功能，就要控制项目以使其达到目标。典型的项目控制活动包括去掉非关键的需求、重新定义需求、用更有经验的人员替换缺乏经验的人员等等。

1.7 估算的真正目的

软件项目面临着相似的两难局面。项目计划者常常发现在项目的业务目标与进度和成本的估算值之间存在差距。如果差距不大，计划者也许可以通过精打细算或“挤压”项目进度表、预算或特性集来控制项目成功结束。如果差距很大，就要重新考虑项目的目标。

软件估算的首要目标并不是预测项目的结果，而是确定项目目标是否足够现实，从而让项目在可控的状态下达成这些目标。是可以把你旅行中想携带的衣物放入小行李箱，还是必须拿大箱子？如果做出少量调整的话，是否就可以拿小箱子？主管们希望得到同样类型的答案。他们想要的往往不是一个告诉他们说需要的衣物无法放进行李箱的准确估算，而是想要一个放入尽可能多的衣物的计划。

当项目的业务目标和达到这些目标所需的进度和工作量之间的差距过大时，就会出现问题。我发现，如果初始目标和初始估算之间的差距不超过20%，项目经理就有足够的机动空间来控制特性集、进度、团队规模和其他参数，从而达到项目的业务目标。如果业务目标和达到目标的实际需求之间的差距过大，项目经理就无法通过对项目参数作出细微调整来使项目获得成功。在项目经理可以控制项目达到项目之前，必须让项目目标更符合实际情况。

1.8 对 ‘良好的估算’ 的初步定义

良好的估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。