有没有人能推荐一项任务在项目估算细目中的最大小时数？

Question

我的意思是，如果我将一个编程项目的估计尽可能多地分解为任务，那么是否会有一个很好的最大值来完成这些任务。这意味着，如果我说最大值是4-6，那么如果任何任务的时间超过这个值，就需要将其分解为更多的任务。我觉得有一点，这并没有变得更有用，但认为最多10-12小时是可以接受的，老板不同意。这里的想法是能够尽可能地知道完成任务需要多少时间，但同时我认为在你真正深入到代码中之前，太多的分解是没有意义的。有什么想法或习惯吗？

Answer 1

使分解结构足够详细，以便您做出正确的估计，但不要太详细，这样以后当事情发生变化时，您将难以维护和跟踪它(如果事情发生变化，则不是，而是当事情发生变化时是)。

在WBS中估计一个任务的小时数并不重要。

Answer 2

当我为一项任务编写自己的时间分解时，我找到了一个最有用的数字，作为单个任务在大约4小时内达到最大值的目标。然后，如果结果真的很难，花费的时间比我预期的要长得多，那就不会那么可怕了。

我不认为将这些项目中的任何一个作为有意义的项目是有用的，除非:1)执行任务的人员创建了投影。2.)创建投影的人对这项工作足够熟悉。

在我的上一份工作中，我甚至没有开始计划任务，直到我在那里工作了三个月。在那之后，又过了一两个月，我的预测才有意义。

我认为这是非常个人化的事情。如果你习惯于在极其详细的层面上思考事情，那么拥有大量的小任务会更有意义。如果你喜欢用更一般的术语来思考事情，那么有几个大任务是有意义的。我相信，如果你和你的老板试图将这种个人偏好强加到任务预测中，你会发现，往好了说，你的预测毫无意义，往坏了说，你的预测是敌意的创造者。

我希望我的经验和表达对你有用。

-Brian J. Stinar

Answer 3

任务是什么样子的？

写一份文档？写一篇文档的章节？在文档中写句子？

写一个程序？写一个类？写一个方法？

我认为以下情况应该是正确的：

1)。一个任务足够大，所以你知道你已经完成了它。一句话或一个方法并不是孤立的。你通常不能孤立地交付那么小的东西，接收器不能“测试”它。

例如，您可以对一些代码进行单元测试、记录和签入到SCM中，这是一个任务。

我无法想象小于一个小时的任务，对我来说通常是半天。

2)。一个任务足够小，你可以有信心在预计的时间内完成它。您已经很好地分析了问题，理解了这些块。