0

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

4

4 回答 4

1

当我为一项任务编写自己的时间分解时，我发现最有用的数字可以作为单个任务的最大目标，大约为 4 小时。然后，如果结果真的很困难并且比我预期的要花更长的时间，那就没那么糟糕了。

我认为实际持有这些项目中的任何一个都没有用，除非： 1.）执行任务的人创建了投影。2.) 创建投影的人对作品足够熟悉。

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

我认为这是一件非常个人化的事情。如果你习惯于在极其详细的层面上思考事情，那么有很多小任务会更有意义。如果你喜欢用更笼统的术语来思考事情，那么做一些大任务是有意义的。我相信，如果您和您的老板尝试将这种个人偏好强制执行到任务预测中，您会发现您的预测充其量是毫无意义的，最坏的情况是制造敌意。

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

-Brian J. Stinar-

于 2010-09-14T17:41:19.400 回答
1

使分解结构足够详细，以便您做出正确的估计，但不要太详细，这样您以后在事情发生变化时（不是事情发生变化，而是事情发生变化时）维护和跟踪它会有困难。

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

于 2010-09-15T19:01:37.520 回答
0

任务是什么样的？

写文件？写一章文件？在文档中写一句话？

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

我认为以下内容必须为真：

1）。一项任务足够大，以至于你知道你已经完成了它。单个句子或方法并不独立。您通常无法单独交付那么小的东西，接收者无法“测试”它。

因此，例如，您可以对一些代码进行单元测试、记录和检查到作为任务的 SCM 中。

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

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

于 2010-09-14T17:33:55.403 回答
0

人不是机器。

话虽如此，我认为有两种主要的开发模式：

  1. 开发
  2. 维护/修复

对于第二个，您可以获得关于任务应该花费多长时间的经验 - 开发人员知道代码，并且大多数时候他可以很好地预测什么是错误的以及应该做些什么来使它工作（在这种情况下，严密的监控 +保持良好合作的缓冲是有序的，如果开发人员无法获得良好的估计 - 这表明存在非常大的问题）

对于第一个 - 它更复杂：

如果这是一项艰苦的工作——不需要大脑，只需将程序从 a 点带到 b 点，而不是……您可以定义紧凑的时间表。

如果您需要开发人员发挥创造力，考虑良好的实施等......您不能永远等待杰作，但您不会从只有生存思想的开发人员那里得到太多:)

了解敏捷 - 团队领导和开发人员一起设定目标 - 目标可能非常苛刻，但在开发期间，感觉与经理一样负责的开发人员......可以管理他的时间。

因此，有时，使用正确的管理系统 - 任务可以而且可能应该持续一周。

没有神奇的数字。了解您的编程类型并找到合适的管理管理系统。

祝你好运

于 2010-09-19T13:56:17.590 回答