假设您有一个项目将涉及两个 Web 应用程序（将共享 DAL/DAO/BO 程序集和一些 OSS 库）：
我们中有两个人具有中等估计能力，即使我们想要/必须这样做，我们也无法在两天内完成。至少这将是一个遥远的估计。
由于我们使用敏捷方法（特别是 Scrum），因此我们比用户确定优先级花费的时间长了大约一个小时。
更多的时间不会导致更高的准确性。
因此，困难的部分是让用户确定优先级。我们经常听到这样的讨论“如果整个事情没有按时完成，那一切都是一文不值”。“除了 XYZZY 组件，它确实有一些价值。” 这种争论可能会持续几个小时，直到确定 XYZZY 应该是第一个。
通常，我们会尝试创建 4 周的 sprint。前几个很复杂，因为总是有新的东西。在前两个（或三个）之后，我们似乎设定了稳定的步伐。
每个用例都有一个相对简单的、主观的评估来评估完成它需要付出的努力。任何超过一个完整 sprint 持续时间的东西都必须分解。大多数时候，一些用例被捆绑到一个冲刺中。
这是对每个用例进行评分的正式方法，以更好地处理成本和进度问题。我们不使用它们，因为额外的努力没有帮助。
在前两次冲刺之后，
有新的和不同的功能，
优先事项都变了，
每个用例的细节都进行了大幅修改。
当您尝试估计的事物在每个 sprint 结束时发生变化时，“准确性”是什么意思？
一个教训。我公司的一些部门花了很长时间来完全定义将要交付的内容，然后衡量他们是否准确地交付了他们想要的东西。
客户注意到了这一点，有人说我们“花了很多时间交付合同所说的内容，但这不是我们所需要的。”
坚定的预先估计的问题在于，他们过着自己的生活。您在估算中“投资”的越多，估算似乎就越有用。它们没有用，因为它们通常是完全错误的。它们基于完全错误的预先假设。
在估算上投入更多时间是一个糟糕的政策。“准确”的答案并没有更准确，但更被每一层管理人员所珍视。随着您和客户的学习，您使许多假设无效，并且您绝对必须不断地重新估计。
不要在前面做。如果您的合同要求您提前完成，请确保您有变更控制条款，并告诉客户您绝对会在前进的过程中进行更改。正如您和客户所了解的那样，你们都必须做出改变。
有趣的问题。恐怕答案是“这真的取决于！” 我知道这不是非常有用（尽管它是真的）所以这里有一些因素：
1) 需求及其规范的质量和完整性。对我来说，这通常是项目估算的杀手。如果你没有质量要求，你就没有合理的估计依据。我们在这里使用“RUP-lite”风格的产品开发，所以作为工程经理，在我们完成“细化”阶段并得到产品管理部门的批准之前，我只会给出最粗略的估计。核心 80% 的产品功能其实都被准确覆盖了。
2）产品的范围和性质。更大/更昂贵/更复杂 = 估计要长得多。我多年来一直从事电信运营商陆上交付解决方案的工作，这些解决方案具有正常的稳健运营商要求（SLA 要求的“5 个 9”正常运行时间意味着您必须真正做好解决方案设计和故障恢复！）。在那种具有跨业务功能领域的所有移动部件的环境中，工作估计将取决于了解整个情况……具体而言，跨职能依赖和外部依赖在这里可能是一个真正的杀手。也就是说，我还构建了许多收缩包装和企业软件。在这些环境中，它更容易，因为范围通常要小得多，因此更容易估计。
3）这个项目有多“新”？团队对这个产品或技术集有多“新”？产品或团队越新，您应该分配的缓冲区越长越多。
4）我们需要具体到什么程度？如果这是一个“粗略的猜测”，那么我将依靠我的工程主管来提供一个保守的估计，然后我会填充它。如果我们需要一个“真实的”估计（例如，我的老板使用的并且我将负责打击的估计），我需要来自许多不同经理和团队成员的输入，他们需要时间来评估分析需求并相互协商。
这可能需要几天或几周的时间......这完全取决于大小。坦率地说，“两三天”的时间不足以确定除了最琐碎的项目之外的任何事情。
您可以做的最好的事情是提高您的估计质量，以提高您的需求质量，并无情地识别隐藏的依赖关系。
最后一件事：FWIW，自 81 年以来我一直在这样做，我认为准确估计项目的持续时间/成本是工程管理中最困难/充满危险的部分。
为了做出可靠的估计，您确实需要创建一个要完成的任务列表。将其分解为故事/任务（即使您不使用敏捷）并评估它们。这可能已经花费了很多时间——尤其是研究量（寻找图书馆来做这个通知程序以降低成本）。我至少需要 3 天 - 但是 1-2 周对我来说听起来更合理。这似乎不是一个小项目。
如果你不想得到一些合理的结果，我不敢加快估计过程。估计永远不会准确，你只会让事情变得更糟。
一个选择是在几个小时内做出一个完全粗略的猜测，然后已经开始工作（大约一周左右）。在一周结束时，您可能能够根据您当前的进度做出更好的估计。然而，创建一个好的原型很重要（它看起来很垃圾，但在所有区域都有一点代码）。
嗯，一个常见的报价是“价格将在我们最初估计的 50% 到 400% 之间”。这句话越来越大的原因是它是真的。估计的准确性很大程度上取决于您的领域知识。如果这是您第 100 次出售给定类型的博客引擎，那么您对估算值非常肯定。但是，通常情况下，您对该领域没有那么深入的了解（如果应用程序已经存在，为什么要创建一个新的应用程序？）。
敏捷开发之所以变得流行，是因为人们在很大程度上认识到传统的“瀑布”思维方式不适用于大多数现实世界的项目。您应该将相同的思维方式应用于您的估计。显然，您需要某种卖点，但一定要告诉您的客户这些信息非常模糊（而且无论任何竞争对手会告诉他们什么，他们的估计也是模糊的）。
您需要出售迭代，因此还要估计迭代。我敢肯定，任何公司的一些营销人员都会知道如何处理文书工作和相关的法律事务，所以这应该没什么大不了的。
考虑一个 5 次迭代的项目：
大多数客户宁愿有部分估价和部分交货，也不愿一些西装卖给他们的不切实际的目标:)
与您最初的问题略有不同，但通过保留有关完成您估计的事情实际需要多长时间的信息，从您过去产生的估计中学习也很重要。
我们估计制作这些页面需要 5 天，实际上需要 10 天，等等。
从长远来看，这样的信息将（希望！）使您能够产生更准确的估计。