为什么说软件估算现在前所未有的重要

文化&方法

摘要： 当前人们日渐疏远传统的瀑布式开发，并转型为敏捷开发方法。有观点认为，开发中已不再需要做软件项目估算。这个观点看上去合情合理，但并不正确。实践中，即便是那些已经采用敏捷方法的企业，软件估算依然十分有价值。

作者： Larry Putnam Jr

审校：Shane Hastie

正文：

本文要点

• 软件项目估算并未消亡。实践中，即便是对于那些已经采用敏捷方法的企业，估算依然十分有价值。

• 团队总是倾向于对自己的估算过于乐观。而在事情发生变化时，团队无法做出重新估算。另一方面，团队常采用单点估算，而非范围估算。

• 为使软件估算步入为组织增加价值的正轨上，利益相关者可使用多种最佳实践。这些最佳实践包括采用自顶向下的方法给出估算、聚焦于五个核心度量，以及使用“球场”方法估算规模。

• 谨记，估算仅是一种估计。团队应该给自身留出一定的灵活空间，而非拘泥于某一点。R

• 软件估算不一定是难以实现、繁琐或是无效的。如果做事方式正确，估算将成为一种有助于项目经理为组织提供价值的高效工具。

当前人们日渐疏远传统的瀑布式开发，并转型为敏捷开发方法。有观点认为，开发中已不再需要做软件项目估算。这个观点看上去合情合理。许多敏捷实践者已经采用了小增量和Sprint并梳理Backlog。在他们看来，软件估算是一个毫无意义的过程。

但是，这一观点并不正确。

在近期的一次采访中，Scrum的创始人Ken Schwaber和Jeff Sutherland就“#NoEstimate”运动发表了自己的看法。在Schwaber看来，更适用的标签应该是“#NoMeaningfulCommitments”。他认为人们总是将估算与承诺混为一谈。事实上，估算是用于作出承诺的。Sutherland提到了Rally（即现在的CA）最近开展的一次调查。调查对象包括了7万名Scrum团队的成员，调查问题涉及他们所使用的估算技术，目的是将所使用的估算技术与交付的速度关联起来。该调查发现，那些回避估算的人，交付时间最慢；而那些根据项目范围作出估算的人，交付速度最快。

组织不应该放弃软件估算，而是应聚焦于如何给出更好的估算。施行自顶向下、宏观层面的估算，并专注于一些核心指标，这有助于管理人员更好地控制他们的项目，并制定出切合实际的开发方案。这样所生成的项目，将符合管理人员的期望，并可按时按预算交付。

在仔细研究一些最佳实践之前，我们首先应了解为什么团队应继续花费一些精力去完成软件估算。事实表明，有多个原因会导致项目经理在估算过程中遇到困难。

他们可能会过于乐观

项目经理和软件开发人员总是倾向于对他们正在开展的项目持乐观态度。看上去，一个自然而然的趋势是高估了自身对首次创建、交付和执行项目的能力。他们会认为凡事顺利，一路坦途。

不幸的是，总是不可避免地会突然出现一些障碍物。它们会导致项目中断，产生意料之外的进度变更，以及其它一些影响项目进展的不可预见情况。

进而，管理人员会犯两个错误。

首先，他们将无法利用类似项目所给出的历史数据，尤其是在人员方面。人员情况可用于准确地估算项目的规模和进度。我们的研究表明，当管理人员仅依靠一些开发方法学，而非去理解和优化他们的可用资源时，项目最终会出现人员配备过多、预算过度和缺陷显著增加的问题。QSM公司对敏捷性能的十五年研究一贯表明，成功开发软件的关键在于良好的规划，而非开发方法。历史数据在有效的规划和评估中发挥着不可或缺的作用。这就是为什么我们在不断创建并更新软件项目数据库的原因所在。这将为我们的客户提供最高质量的历史信息和趋势，以便他们在软件开发过程中做出明智的决策，无论他们使用何种方法。

其次，管理人员倾向于将估算与承诺、价值目标或最终成就混为一谈。价值目标是人们想要促成的事情。相反，估算是根据对可能发生事情的一种定量分析。两者绝对不能混为一谈。应该对目标和估算进行独立的评估，确认它们是否一致。这有助于团队保持更现实的乐观情绪。在做出成本和时间表承诺之前，应始终以估算为输入。

未能在事情发生变化时给出重新估算

如前所述，难免会发生一些改变开发工作进程的事情。例如，团队可能会在开发周期中发现需要对项目的范围和要求做出调整。这些改变可能会对进度产生影响，也可能会影响其它一些因素，诸如项目工作所需的团队成员规模、总成本等。在此类情况下，管理人员必须准备给出重新估算，以更准确地衡量项目的状态。

不幸的是，很多人并不会这样做。他们继续遵循原来的估算。一旦估算出现了偏差，例如项目落后于计划或超出了预算等，他们就会将责任推脱到软件估算过程上。但这并非估算过程失败了，而是由于团队固守了原有的估算。

项目经理必须谨记，估算并非一成不变的。当开发过程发生变化时，他们可以也应该对估算做相应的调整。这是敏捷从业者很久以前就接触到的原则，也正是促使他们改变开发方法的潜在因素。

做出的是单点估算而非范围估算

就估算而言，管理人员倾向于在项目中使用单点估算（即给出单一值）。他们会明确表示，“我们的项目将于2018年5月1日发布”，不留任何余地。

但是，估算在本质上是不确定的。例如，它们会受到我们所未知一些因素的驱动，诸如规模、范围和生产力等。在我们做估算时，我们事实上在试图给出一个可为之奋斗的时间表，而非一个不容置疑的时间点。拘泥于某个特定日期的团队，更有可能使自己陷入到潜在的失败危险中。

项目经理应该制定的是一个估算的范围，而非给出单点估算。例如，“我们的项目很可能将于4月15日之前交付，但不迟于5月1日”，或者“我们的项目预算不会少于100万美元，但不超过300万美元”。这为团队提供了一个灵活的空间，使他们免于承担一些无所保留的承诺。同时，也向管理层给出了一个明确的期望目标。

以飓风预测模型为例。气象学家在预测飓风的路径时从来不使用细线标识。相反，他们把路径作为一个随时间推移而变得更加宽泛的不确定性锥体表示。尽管这样的模型并非十分精确，但足以确定哪些人口中心应该考虑撤离。这个想法同样适用于建模和预测软件项目结果。和气象学家使用不确定性来解释可能的飓风过程一样，项目经理可以使用范围估算给出一个合理的风险缓冲区，同时依然能够向管理层交代出一个现实的期望。

有助于完成软件估算的最佳实践

上面，我们审视了一些人们正在犯的错误。下面，我们将详细介绍一下软件开发人员应如何实现软件估算流程，进而向他们的组织提供卓越的价值。

采用“自顶向下”、宏观层面的方法

在传统的项目管理中，启动阶段就要分配估算的人员规模以及特定任务上的工作小时数。这通常发生在团队已经确定了每个人的任务的具体要求之前，或者是在估算整个系统的总持续时间和工作量之前。这种“自底而上”的软件项目估算方法，通常会导致对不准确的猜测和重新规划，进而导致组织支出额外的时间和费用。

更有效的做法是采用自顶向下，宏观层面的估算方法。自顶向下的估算从一开始就考虑了整个项目情况。它采用基于历史和经验的模型来准确估计规模、成本、工作量及其它一些因素。管理人员可以运行一些“如果发生”（What-if）的情景，解决在整个开发过程中可能发生的各种挑战（即“如果我们超出预算会怎样？”或“如果我们必须重做一些工作？”）。他们可以在工作开始之前就根据需要做出调整，从长远看，这种做法将节省大量的时间和费用。

聚焦于五个核心度量

为确保估算过程的成功完成，项目经理不必获取多种各异的度量。他们只需关注下面五个核心度量，即持续时间、工作量、规模产力和可靠性。这五个度量可以给出非常准确和可靠的估算。

我的父亲Larry Putnam, Sr.在他所著的《五项核心度量：成功的软件管理背后的智慧》（Five Core Metrics: The Intelligence Behind Successful Software Management）一书中最先提出了这一理论。在这本书中，我父亲提出，将估算流程简化并调整到真正起作用的领域，将有助于管理人员更好地评估风险因素、做出预测和应对变化，并在必要时成功地重新规划项目。该理论解决了对软件项目估算是过于困难和复杂的这一常见误解。正如我父亲所提出的，软件估算并非一贯如此困难和复杂。

测定规模和范围

考虑到特定软件版本中的功能数量，在这五个核心度量中，往往最麻烦之处在于如何确定项目的规模。团队常常会发现非常难以量化项目的规模。如果项目涉及大规模的软件开发工作，情况尤其如此。团队通常需要使用多种项目规模确定方法，具体取决于项目所处的生命周期阶段，以及他们为确定复杂任务规模所掌握的信息。

当然，估算规模是非常重要的。如果没有估算规模，利益相关者将无法确定软件项目完成所需的时间、所需的成本和人员数量、人员的工作效率如何，以及在测试期间可能会发现多少缺陷。忽略规模将会导致给出糟糕的估算。

能给出确切的工作单元固然很好，但这并非总是可以做到的。团队可以使用工作单元很好地控制规模估算。工作单元可以使用“大”、“中等”、“小”，或是这些术语的一些变体，也可以采用“业务需求”、“用户故事或Epic的数量”等高层级测量单元。

可使用一些估算工具，作为对这些初始参考框架的补充，并解决任何可能存在的不确定因素。经过初步估算后，管理人员可对项目规模具有一个良好并可靠的想法。进而，他们可以根据行业趋势审查该估算，确定项目的总体成本和时间表。

估算并未消亡，依然至关重要

软件估算并不一定是难以实现、繁琐或是无效的。相反，估算对于项目的及时开发和交付是绝对必要的。它可为组织提供有价值的解决方案，帮助团队更好地了解所需花费的时间、精力和费用。它还可以向项目经理提供利益相关者所要求的信息，给出他们投资的管理情况。

简而言之，软件评估远未消亡。事实上，它依然非常活跃。对于使用任何方法、具有任何规模的项目，组织只要在估算上稍作投资，就能充分利用估算结果所给出的有价值见解。

本文作者简介

Lawrence H. Putnam Jr.是QSM的联合首席执行官。QSM是软件过程改进和系统开发评估领域的引领企业。Larry在QSM的主要职责是监督企业产品业务的战略方向，包括实现收入目标、战略产品方向、客户关怀和研究等。Larry在软件测定、估算和项目控制方面具有25年以上的工作经验。他于1987年加入QSM，并涉足了企业各个方面的业务，包括业务发展、客户支持、专业服务，以及当前的执行管理。

查看英文原文： Why Software Estimation Is More Important Now Than Ever