认识达内从这里开始

我们在开展一项工作之前都会为这个工作准备一些前期的素材，比如说工作计划。同样的，在开发一些软件的时候，我们也需要根据用户需求以及市场变化来分析这款软件的价值如何。下面我们就一起来了解和学习一下软件估算的方法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

聚焦于五个核心度量

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

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

测定规模和范围

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

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

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

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

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

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

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

作者：Larry Putnam Jr

译者：盖磊

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。