软件估算速度和准确性

Question

假设您有一个项目涉及两个 Web 应用程序（将共享 DAL/DAO/BO 程序集和一些 OSS 库）：

• 一个半复杂的管理应用程序，使用 Windows Live ID 进行身份验证，并且还能够与各种通知程序服务（电子邮件、短信、twitter 等）进行通信，目标通知程序约占功能的 10%
• 低到半复杂的用户应用程序，功能较少但更稳健，还使用 ​​Windows Live ID 进行身份验证

我们两个人的估计能力中等，即使我们想要/必须在两天内完成，我们也无法完成。至少这将是一个 遥远 估计。

问题

1. 您通常需要多长时间才能做出可靠/有价值的估计？
2. 您有什么建议可以在不牺牲准确性的情况下加快估算速度？
3. 根据估计速度（当您说： 我可以多估计一下，因为我认为还差得很远)

Answer 1

有趣的问题。恐怕答案是“这真的取决于！”我知道这不是很有用（尽管是真的），所以这里有一些因素：

1) 要求及其规范的质量和完整性。对我来说，这通常是项目估算的杀手。如果你没有质量要求，你就没有合理的估算依据。我们在这里使用“RUP-lite”风格的产品开发，因此作为工程经理，我不会给出任何内容，除了最粗粒度的估计，直到我们完成“精化”阶段并获得产品管理部门的批准为止。事实上准确覆盖了产品80%的核心功能。

2) 产品的范围和性质。更大/更贵/更复杂=估计时间要长得多。我在电信运营商陆地交付解决方案方面工作了多年，这些解决方案具有正常的稳健运营商要求（SLA 要求的“5 个 9”的正常运行时间意味着您必须真正做好解决方案设计和故障恢复！）。在那种跨业务职能领域的所有移动部分的环境中，工作的估计将取决于了解整体情况……具体来说，跨职能依赖性和外部依赖性可能是真正的杀手。也就是说，我也构建了许多收缩包装软件和企业软件。在这些环境中，这要容易得多，因为范围通常要小得多，因此更容易估计。

3）这个项目有多“新”？团队对该产品或技术的“新”程度如何？产品或团队越新，您应该分配的缓冲时间越长、越多。

4）我们需要具体到什么程度？如果这是一个“粗略的猜测”，那么我将依靠我的工程团队提供保守的估计，然后我将对此进行补充。如果我们需要一个“真实”的估计（例如，我的老板使用的估计，我将负责实现），我需要许多不同的经理和团队成员的输入，他们需要时间分析需求并相互协商。

这可能需要几天或几周的时间……这一切都取决于大小。坦率地说，“两三天”的时间不足以确定除了最琐碎的项目之外的任何项目的规模。

为了提高估计的质量，你能做的最好的事情就是提高需求的质量，并毫不留情地识别隐藏的依赖关系。

最后一件事：FWIW，我自 81 年以来一直在这样做，我认为准确估计项目的持续时间/成本是工程管理中最困难/充满危险的部分。

Answer 2

由于我们使用敏捷方法（特别是 Scrum），因此我们比用户确定优先级所需的时间多了大约一个小时。

更多的时间并不会带来更高的准确性。

那么，困难的部分是让用户确定优先级。我们一直都在听到这个讨论，“如果整个过程没有按时完成，那都是一文不值。” “除了具有一定价值的Xyzzy组件。”该论点可能会持续数小时，直到解决Xyzzy应该首先。

一般来说，我们尝试创建 4 周的冲刺。前几个很复杂，因为总是有新的东西。在前两个（或三个）之后，我们似乎设定了稳定的步伐。

每个用例对于完成它需要付出的努力都有一个相对简单、主观的评估。任何超过一个完整冲刺持续时间的事情都必须分解。大多数时候，几个用例被捆绑到一个冲刺中。

这些是对每个用例进行评分的正式方法，以更好地处理成本和进度问题。我们不使用它们，因为额外的努力没有帮助。

在前两次冲刺之后，

1. 有新的和不同的功能，

2. 优先事项都变了，

3. 每个用例的细节都经过了大幅修改。

当您尝试估计的内容在每次冲刺结束时发生变化时，“准确性”意味着什么？

---

吸取了一个教训。我公司的部分部门花费了 长的 时间完全定义 确切地 将交付什么，然后衡量他们是否准确地交付了他们想要的东西。

客户注意到了这一点，有人说我们“花了很多时间来交付合同中规定的内容，但这不是我们所需要的。”

严格的预先估​​算的问题在于它们有自己的生命力。您在估算中“投入”的越多，估算的交付成果就越有用。它们没有用，因为它们通常是完全错误的。它们基于完全错误的预先假设。

投资政策不好 更多的 时间在估算中。“准确”的答案并不是更准确，而是每层管理层都更珍惜。当您和客户了解时，您会发现许多假设无效，并且您绝对必须不断重新估计。

不要预先这样做。如果您的合同要求您预先进行更改，那么请确保您有变更控制条款，并告诉客户您绝对会在以后进行更改。作为 两个都 你和客户都学习 必须 做出改变。

Answer 3

为了做出可靠的估计，您确实需要创建一个要完成的任务列表。将其分解为故事/任务（即使您不使用敏捷）并评估它们。这可能已经花费了大量时间 - 尤其是大量的研究（寻找库来执行此通知程序以降低成本）。我至少需要 3 天 - 然而 1-2 周对我来说听起来更合理。这看起来不是一个小工程。

如果你不想得到合理的结果，我不敢加快估算过程。估计永远不会准确，你只会让事情变得更糟。

一个选择是在几个小时内做出完全粗略的猜测，然后开始研究（一周左右）。在本周末，您也许能够根据当前的进度给出更好的估计。然而，创建一个好的原型很重要（它看起来很糟糕，但在所有区域都有一些代码）。

Answer 4

常见的说法是“价格将在我们最初估计的 50% 到 400% 之间”。这句话之所以被广泛传播，是因为它是真实的。估计的准确性很大程度上取决于您的领域知识。如果这是您第 100 次销售特定类型的博客引擎，那么您对估算非常确定。然而，通常情况下，您对该领域没有深入的了解（如果应用程序已经存在，为什么要创建一个新应用程序？）。

敏捷开发之所以变得流行，是因为人们在很大程度上认识到传统的“瀑布”思维方式不适用于大多数现实世界的项目。您应该将相同的思维方式应用于您的估计。显然，你需要某种卖点，但一定要告诉你的客户，这些信息非常模糊（而且无论任何竞争对手会告诉他们什么，他们的估计也很模糊）。

您需要销售迭代，因此也需要估算迭代。我确信任何公司的营销人员都会知道如何处理文书工作和法律事务，所以这应该不是什么大问题。

考虑一个 5 次迭代的项目：

• 从设立里程碑开始。这些可能会发生变化，但将为您提供对最终产品的初步估计。
• 计划迭代#1。
• 估计迭代#1，相应地调整总估计。
• 进行迭代 #1
• 冲洗/重复直到迭代#5
• 你完成了 ：）
• 反思你的项目。您的估计是如何演变的？原因？通过实践学习 ：）

大多数客户宁愿部分估计和部分交付，也不愿某些西装向他们推销的一些不切实际的目标:)

Answer 5

稍微偏离了您最初的问题，但通过保留有关完成您估计的事情实际需要多长时间的信息，从您过去生成的估计中学习也很重要。

我们预计制作这些页面需要 5 天，实际需要 10 天，等等。

从长远来看，这样的信息将（希望如此！）使您能够做出更准确的估计。