我知道这个问题已经在这里/程序员上被问过好几次了，这是一个很常见的经典问题：
您如何准确估算一项任务需要多长时间？
我遇到的问题是 Windows 中的点击式任务，我可以给出准确的估计。为了编写新的代码（比如使用我不熟悉的 API），我无法估计准确的时间来挽救我的生命。这是一个思考并说出我脑海中的第一个数字（天/周/无论如何）的案例。对于使用我熟悉的 API 的代码和我可以立即说我可以开发的应用程序（例如记事本类型的应用程序），我可以给出准确的估计。
任何帮助表示赞赏。
谢谢
【问题讨论】：
标签： project-management estimation
专注于碎片。当您尝试在高层次上估算一项任务时，不仅令人生畏，而且您将无法准确地考虑构成总时间的所有因素。
相反，甚至不要试图猜测总数（它不仅没有用，而且实际上可能会影响您对单个任务的估计），而是坐下来尝试思考构成的所有子任务任务。如果这些感觉太大，请将它们分解为更小的子任务。
完成此操作后，对每个子任务进行估算。如果其中任何一个大于大约 4 小时，则子任务可能还没有被充分分解。将所有这些子估计加起来。这是您的估计。
使用这种方法会迫使您推理出完成任务实际需要什么，并让您做出更好的估计。
确保您也考虑完成一项任务所需的不明显步骤。如果您正在编写一段代码，您是否包括了编写相关单元测试的时间估算？用于测试代码？为了记录它？
在将小时数转换为天数时，请对您实际埋头工作的时间使用切合实际的预期。普遍的共识是，开发人员可以在任何给定的 8 小时工作日内完成 4-6 小时的工作。这大致符合我的个人经验。
如果您有其他团队成员，您可以尝试一种称为Planning Poker 的技术。最简单的想法是让团队的每个成员开始并单独估计每个任务。一旦完成，团队就会聚在一起，比较估计值，寻找较大的偏差。如果任务不够清晰，如果团队中的某些成员拥有其他人没有的相关信息，或者如果不同的团队成员做出不同的假设，这往往会暴露出来。
在进行估算时，请注意您的假设并将其记录为估算的一部分。假设 x、y 和 x，任务 q 应该花费 n 小时。这些可能是假设 QA 工程师可以测试该功能，假设开发环境可以部署该功能以进行测试，假设两个尚未一起测试的第三方框架的兼容性，假设任务所依赖的特征 z 已在某个日期前准备就绪......等等。我们一直在做出大量这些假设，而没有意识到它们。记录它们会迫使您了解它们并允许其他方验证您的假设是否正确。如果估计结果确实是错误的，那么您有更多信息可以分析原因。
即使遵循所有这些建议，您仍然会经常做出不准确的估计，但不要感觉太糟糕，因为我们的大脑天生就会对抽象任务产生糟糕的估计。我们有许多认知偏见，这些偏见会影响我们衡量任务规模和工作量的能力。
我建议阅读这篇文章以获得更多信息和建议：
http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/
【讨论】：
我主要从事持续时间“较短”的项目，但对我来说效果很好的方法是将任务分解为足够小的子任务，我认为我可以在大约一天内完成每个子任务。对于某些项目，这意味着只有两个或三个子任务，对于其他项目，这可能意味着数十或数百个。加上一些浪费在非生产性活动上的开销百分比，一些用于探索错误方向的开销，希望你能得到一个在最终结果合理范围内的数字。
【讨论】：
我通常做的是将任务分解为小任务。最大的任务不应超过 2 天。估计小任务并不难。每个小任务的测试时间都包含在估算中，所以我不会在项目结束时得到大量未经测试的代码。
只有在有高级设计的情况下才可能将任务分解成小块，否则估计只是粗略的猜测，通常是 2 周，这是大多数开发人员使用的著名 2 周；）
在项目结束时增加一些时间来修复集成稳定错误使其成为合理的估计。
【讨论】：
与 sarnold 提到的类似，分解任务是关键……但如果您不了解该领域，则可能更难将其归结为细粒度的 1 天增量/所涉及的技术。在您的情况下，我会提出以下建议（特别是如果这显然不是一项需要不到几天时间才能完成的任务）：
1) 首先，您需要询问您的团队/同事，看看他们是否可以提供一些启示（和/或他们是否使用了与您相同的 API/技术）。如果没有人知道任何事情，您将不得不承认您根本没有足够的数据来进行合理的猜测，并且需要花费 X 天的时间来调查（调查的时间需要是与您正在使用的 API/域的复杂性保持一致）
2) 在您研究新技术的时间结束时，您应该能够使用 API 做一个非常基本的 hello、world-ish 类型的应用程序（编译、链接和运行良好） .到这个时候，你应该可以很好地确定你的任务是需要几天、几周还是几个月的时间。
3) 接下来要做的关键是尽快找出任何会影响您的预测的主要障碍/小问题...这是关键。你能做的最糟糕的事情就是在到期日不断地去找你的经理/客户，并提到你需要大量的额外时间来交付。他们需要尽快抬起头来帮助纠正这种情况和/或制定 B 计划。
差不多就是这样......这不是火箭科学，但你基本上会在你有能力给出一个估计时提供一个估计，然后确保你根据具有重大意义的新的、意料之外的事件更新该估计影响您安排预期日期的能力。
【讨论】：