project-management - 估计完成任务的时间

Question

我知道这个问题已经在这里/程序员上被问过好几次了，这是一个很常见的经典问题：

你如何准确地估计一项任务需要多长时间？

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

任何帮助表示赞赏。

谢谢

Answer 1

专注于碎片。当您尝试在高水平上估计一项任务时，不仅令人生畏，而且您将无法准确地考虑构成总时间的所有因素。

相反，甚至不要试图猜测总数（它不仅没有用，而且它实际上会影响您对单个任务的估计），而是坐下来尝试思考构成任务的所有子任务。如果这些感觉太大，请将它们分解为更小的子任务。

完成此操作后，对每个子任务进行估算。如果其中任何一个大于大约 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/

Answer 2

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

Answer 3

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

只有在有高级设计的情况下才可能将任务分解成小块，否则估计只是粗略的猜测，通常是 2 周，这是大多数开发人员使用的著名的 2 周；）

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

Answer 4

与sarnold提到的类似，分解任务是关键……但如果您不了解所涉及的领域/技术，将其归结为细粒度的 1 天增量可能会更加困难。在您的情况下，我会建议以下内容（特别是如果这显然不是一项需要不到几天时间才能完成的任务）：

1）首先，您需要询问您的团队/同事，看看他们是否可以提供一些启示（和/或他们是否使用了您正在使用的相同 API/技术）。如果没有人知道任何事情，您将不得不承认您根本没有足够的数据来进行合理的猜测，并且需要花费 X 天来调查（调查的时间需要是与您正在使用的 API/域的复杂性保持一致）

2) 在您分配研究新技术的时间结束时，您应该能够使用 API 做一个非常基本的 hello、world-ish 类型的应用程序（编译、链接和运行良好）。到这个时候，你应该可以很好地确定你的任务是需要几天、几周还是几个月的时间。

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

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