我的意思是，如果我正在尽可能地将编程项目估计分解为任务，那么完成任务将是一个很好的最大值。这意味着如果我说最大值是4-6那么如果任何任务的时间超过了它，则需要将其分解为更多任务。我觉得有一点，这变得没那么有用，并认为最多10-12小时是可以接受的，老板不同意。这里的想法是能够尽可能多地知道完成任务所需的时间，但与此同时我认为，在您真正深入研究代码之前，有太多故障是没有意义的。有什么想法或常见的做法吗？
答案 0 :(得分：1)
当我为一项任务编写自己的时间分解时，我找到了最有用的数字，作为单个任务在大约4小时内最大化的目标。然后，如果结果真的很困难并且花费的时间比我预期的要长，那就不那么可怕了。
我认为实际持有任何这些项目并不有用，除非： 1.）执行任务的人创建了投影。 2.）创建投影的人对这项工作非常熟悉。
在我上一份工作中，在我去那里三个月之前，我甚至没有开始预测任务。在此之后，在我的预测有意义之前又过了一两个月。
我认为这是一件非常个人化的事情。如果您习惯于在非常详细的层面上思考问题，那么拥有大量小任务会更有意义。如果你想用更一般的术语来思考问题，那么有一些重要任务是有意义的。我相信如果你和你的老板试图将这种个人偏好强加给任务投射，你会发现你的预测充其量只是毫无意义，而且最坏的情况下也是敌意的创造者。
我希望我的经验和表达对你有用。
-Brian J. Stinar-
答案 1 :(得分：1)
使细分结构足够详细，以便您进行适当的估算，但不要过于详细，以便在以后情况发生变化时维护和跟踪它（如果事情发生变化 当事情发生变化时）。
估算WBS中的任务的小时数并不重要。
答案 2 :(得分：0)
任务是什么样的？
写一份文件？写一个文件章节？在文档中写一个句子？
写一个程序？写一堂课？写一个方法？
我认为以下情况必须如此：
1）。任务足够大，以便您知道自己已完成任务。单个句子或方法并不孤立。你通常无法提供单独的小东西，接收器无法“测试”它。
因此，例如，您可以将一些代码单元测试，记录并检查到SCM中，这是一项任务。
我无法想象小于一小时的任务，通常对我来说它们是半天。
2）。任务足够小，您可以确信您可以在预计的时间内完成任务。你已经很好地分析了这个问题，无法理解这些问题。
答案 3 :(得分：0)
人不是机器。
话虽如此，我看到它的方式有两种主要的开发模式：
对于第二个，您可以获得有关任务应该花费多长时间的经验 - 开发人员知道代码，并且大多数时候他可以很好地预测出错是什么以及应该做些什么来使其工作（在这种情况下）严密的监控+缓冲以保持良好的合作是有序的，如果开发人员无法得到一个好的估计 - 这是一个非常大的问题的迹象）
对于第一个 - 它更复杂：
如果这是一项艰苦的工作 - 一个不需要大脑的工作，只需要将程序从a点到b点，而不是...你可以定义严格的时间表。
如果你需要开发人员发挥创造力，考虑良好的实施等等......你不能永远等待杰作，但你不会从只有生存想法的开发者那里得到很多：）
了解敏捷 - 团队领导者和开发人员共同设定目标 - 目标可能非常苛刻，但在开发期间，开发人员感觉像经理一样负责......可以管理他的时间。
因此，有时候，使用正确的管理系统 - 任务可以而且可能应该持续一周。
没有神奇的数字。了解您的编程类型并找到合适的管理系统。
祝你好运