估计完成任务的时间

Question

我知道这个问题已经在这里/程序员多次被问过，这是一个非常常见的经典问题：

您如何准确估算任务需要多长时间？

我遇到的问题是Windows中的点击式任务，我可以给出准确的估算。对于新的编码（如使用我不熟悉的API），我无法估计挽救生命的准确时间。这是一个思考和说出我头脑中的第一个数字（几天/几周/无论什么）的情况。对于使用我熟悉的API的代码和我可以立即说出我可以开发的应用程序（例如记事本型应用程序），我可以给出准确的估计值。

任何帮助表示感谢。

由于

Answer 1

专注于作品。当您尝试高级别地估算任务时，不仅令人生畏，而且您将无法准确地计算构成总时间的所有内容。

相反，甚至不要试图猜测总数（不仅没有用，而且实际上可能会偏倚你对个别任务的估计），而是坐下来试着想一下构成的所有子任务任务。如果那些感觉太大，可以将它们分解成更小的子任务。

完成此操作后，请为每个子任务进行估算。如果它们中的任何一个大于约4小时，那么子任务可能还没有被分解。添加所有这些子估算值。这是你的估计。

使用此方法会强制您推断完成任务所需的实际内容，并让您产生更好的估算值。

确保您考虑完成任务所需的非显而易见的步骤。如果您正在编写一段代码，那么您是否包含了编写相关单元测试的时间估算值？用于测试代码？为了记录它？

将小时数转换为天数时，请使用实际的期望来确定实际花费多少时间。普遍的共识是，开发人员可以在任何给定的8小时工作日内完成4-6小时的工作。这大致符合我的个人经历。

如果您有其他团队成员，可以尝试一种名为Planning Poker的技术。最简单的想法是让团队的每个成员离开并单独估算每个任务。完成后，团队聚集在一起，比较估计出现大偏差的情况。如果任务不够明确，如果团队成员拥有其他人没有的相关信息，或者不同团队成员有不同的假设，那么这往往会暴露出来。

在进行估算时，请注意您的假设并将其作为估算的一部分进行记录。假设x，y和＆amp; x，任务q需要n个小时。这些可能是假设有一个QA工程师可用于测试该功能，假设有一个开发环境可用于部署该功能以进行测试，假设两个第三方框架的兼容性尚未经过一起测试，假设任务依赖的特征z在某个特定日期准备就绪......等等。我们一直在做大量的这些假设而不了解它们。记录它们会迫使您了解它们并允许其他方验证您的假设是否正确。如果估算确实是错误的，那么您可以获得更多信息来分析原因。

即使遵循所有这些建议，您仍然会经常做出不准确的估计，但不要感觉太糟糕，因为我们的大脑硬连线会对抽象任务产生可怕的估计。我们有许多认知偏差会影响我们衡量任务规模和工作量的能力。

我建议您阅读本文以获取更多信息和建议：

http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/

Answer 2

我主要从事“持续时间较短”的项目，但对我来说效果很好的事情就是将任务分解成足够小的子任务，我认为我可以在大约一天内完成每项任务。对于某些项目，这意味着只有两个或三个子任务，对于其他项目，这可能意味着数十或数百个。添加一些浪费在非生产性活动上的开销百分比，一些用于探索错误方向的开销，并希望您将得到一个在最终结果的合理范围内的数字。

Answer 3

我通常做的是将任务分解为小任务。最大的任务不应超过2天。估算小任务并不困难。每个小任务的测试时间都包含在估算中，因此我不会在项目结束时使用大量未经测试的代码。

如果有高级设计，则可以将任务分解为小块，否则估计只是一个粗略的猜测，通常为2周，这是大多数开发人员使用的着名2周;）

在项目结束时添加一些时间进行整合 - 稳定错误修复使其成为一个合理的估计。

Answer 4

类似于 sarnold 提到的，分解任务是关键......但如果您不理解该域，则可能更难将其降低到细粒度的1天增量/涉及的技术。在您的情况下，我会建议以下内容（特别是如果这显然不是一项需要不到几天才能完成的任务）：

1）首先，您需要询问您的团队/同事，看看他们是否能够解决问题（和/或他们是否使用了您正在使用的相同API /技术）。如果没有人知道任何事情，你将不得不承认这样一个事实：你根本没有足够的数据来冒险进行合理的猜测，需要花费X天的时间进行调查（需要花费大量时间进行调查）与您正在使用的API /域的复杂性保持一致）

2）在您分配调查新技术的时间结束时，您应该能够使用API​​（编译，链接和运行正常）做一个非常基本的hello，world-ish类型的应用程序。到这个时候，您应该处于有利位置，以确定您的任务是否需要数天，数周或数月。

3）接下来要做的关键是，尽快，找出任何会破坏你的预测的主要障碍/打嗝...这是关键。您可以做的绝对最糟糕的事情是在截止日期前不断向您的经理/客户提出，并提及您需要大量额外的时间来交付。他们需要尽快抬头，以帮助纠正这种情况和/或制定B计划。

这就是它......它不是火箭科学，但你基本上提供了一个估计，一旦你能够给出一个，然后确保你根据新的，意料之外的事件更新估计影响你预定日期的能力。