在软件开发过程中，估算始终是一项具有挑战性的任务，因为软件开发包含很多不确定因素，而且任何项目都不尽相同。虽然很难（或几乎不可能）做到完美估算，但还是有必要努力提高估算的准确性。本文将根据自己的经验和深入研究来解释软件估算的原则。我保证，有了这些可操作的原则，你可以显著改善项目估算的结果。

为什么估算很重要？为什么客户、高管、销售人员或其他利益相关者总是问："需要多长时间？""你们什么时候能完成？"他们会根据估算采取什么行动？答案是为了业务决策。估算的最终目的是支持业务决策。估算会直接影响时间和成本，这也是商人一直关心的问题，以便衡量他们的投资能获得多少收益，也就是所谓的投资回报率（ROI，Return on Investment）。估算不是为了降低风险、提高速度或确保质量，而是为了辅助决策。我见过很多人误以为自己在做软件开发，但实际上他们做的是业务。

在敏捷项目中，产品负责人（Product Owner）代表业务并负责决策，他根据三个因素做出决定：范围、资源和时间。估算与时间有关，产品负责人要监控这三个因素之间的平衡，以确定应该开发什么以及何时开发。例如，如果一项任务需要一天或一年的时间，做出的决定就会不同。如果任务估计只需要一天的时间，他可能会决定立即着手进行。相反，如果估计需要一年，就可能会取消或推迟。估算对产品负责人的决策有巨大的影响。在敏捷项目中，产品负责人（Product Owner）代表业务并负责决策，他根据三个因素做出决定：范围、资源和时间。估算与时间有关，产品负责人要监控这三个因素之间的平衡，以确定应该开发什么以及何时开发。例如，如果一项任务需要一天或一年的时间，她的决定就会不同。如果任务估计只需要一天的时间，她可能会决定立即着手进行。相反，如果估计需要一年，她可能会取消或推迟。估算对她的决策影响巨大。

敏捷项目和瀑布式项目的决策方法不同。在敏捷项目中，资源和时间是固定的，而范围是灵活的。由于敏捷是为快速迭代交付而设计，因此产品负责人要考虑的是如何在有限的时间和资源内实现产品价值的最大化。如果估算的范围过大，无法在目标时间内完成，则应按照优先级缩小范围。

另一方面，在瀑布式方法中，范围是固定的，而资源和时间是灵活的。决策者的角色与敏捷项目中的产品负责人相同，需要考虑完成所有项目需要多少资源和时间。他需要采购必要的人力资源，并根据范围大小和估算制定计划。

虽然上述决策方法广为人知，但固定和灵活的因素可能会根据业务环境发生变化。例如，在敏捷方法中，如果利益相关者要求通过推迟交付时间来完成所有工作，那么时间就会延长。如果客户预算有限，而软件开发的成本超出了他们的预期，那么瀑布式方法中的时间范围就会缩小。应根据实际情况调整决策，同时牢记这些基本方法。

第一条原则是明确需求。不确定性三角的研究表明，明确的需求最能提高估算的准确性。换句话说，需求越明确，估算就越准确。
原则 2：定义"完成"的含义

第二个原则是定义项目中完成的含义，即"完成的定义"（DoD，Definition of Done）。DoD 可以区分已完成和未完成的 PBI（Product Backlog Item，也称为 ticket、issue 或 tasks），并提高产出质量。估算中最常见的误区之一就是忽视质量保证过程，这往往会导致估算过低。为了让客户满意，产品必须达到一定的质量，质量保证流程应定义为 DoD。增加质量保证步骤会让开发人员认识到他们需要更多的时间来完成任务，以防止低估。下面列出了一些例子。

• 必须编写单元测试，覆盖率必须超过 80%。

• 代码审查必须由两名软件工程师进行。

• 质量检查必须由测试人员进行。

• 功能必须向产品负责人展示，以获得反馈和最终批准。

尽管 DoD 被定义为敏捷最佳实践，但也可以（或应该）用于瀑布式项目，因为无论项目管理类型如何，它都能带来巨大的好处。而根据项目的不同，DoD 也有很大的不同。

第三个原则是避免追求完美，这意味着估算只是最佳的猜测，而不是开发团队无论如何都必须遵守的最后期限。软件开发中的估算具有挑战性，因为任何项目都不尽相同。史蒂夫-麦康奈尔（Steve McConnell）是不确定性三角（The Cone of Uncertainty）的作者，他说，没有一个项目具有相同的需求、相同的人、相同的业务背景、相同的技术和相同的限制。因此，所有项目都包含大量的不确定性和不可预测性，这给估算带来了困难。

与其追求完美的估算，不如随着时间的推移不断提高准确性，这就是所谓的"Kaizen"或"持续改进"。在开发结束时，软件工程师会回顾实际花费的时间，检查估算时间与实际时间之间的差距，相互分享经验，并在下一次开发中加以利用。在敏捷开发（Scrum）中，Sprint 回顾是分享经验的最佳时机，估算时间也会在 Sprint 中得到改善。如果一个软件工程师被一个复杂的错误困住了，花费的时间超出了他的预期，他就会分享问题是如何解决的，这样其他软件工程师就不会被同样的错误困住。尤其是，必须分享瓶颈所在，因为这将大大提高估算的准确性。

另一个避免完美的技巧是估算范围，而不要进行精确估算，只估算最小值和最大值。例如，一项任务估算的最小时间为 3 天，最大时间为 5 天。不同项目的范围各不相同，应与产品负责人和业务人员协商。只要估算能帮助他们做出决策，范围大小并不重要。三点估算也是一种估算技术，有三个点：最坏情况、最好情况和最可能情况，是相同的概念。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。