4

当被要求估计和/或在阅读我的同事估计时，他们经常读到这样的内容：

  1. 使用功能 ############## 制作新的 ############# 页面 - 8 小时
  2. 创建新的 ########## 控件 - 21 小时
  3. 解决 ######## 模块中的错误 - 15 小时

我认为当单个任务的估计时间超过 5 小时时，您应该强烈考虑将任务划分为更小的子任务。

像 21 小时这样的估计的问题在于，您可能会在管理层不知道的情况下损失大量时间，直到为时已晚。此外，较大的估计值可能表明任务定义不明确。当然，这不可能是一个非常严格的规则，因为很容易想到例外。

所以我的问题是：

  1. 你的任务估计有上限吗？如果有，你的上限在哪里？
  2. 在您看来，任务的可接受的详细程度是多少？
4

6 回答 6

9

当我们进行计划时，我们将事情分解为 4 小时的任务（最长）。而且，我们每周只计划 4 个工作日。（我们认为其余时间都用于会议等）

于 2009-08-18T21:13:20.447 回答
3

在计划项目时，我不喜欢任何短于 2 天的任务。将其限制在不到一天的时间似乎非常有限制，因为这不会解释任何具有重要发现组件的任务。

我们每天预定 6 小时，假设另外 2 小时将用于会议和其他杂项任务。

于 2009-08-18T21:33:30.313 回答
2

如果您跟踪您的估计/实际历史记录，您可能可以按准确度绘制小时数，并准确找出适合您团队的数字。

于 2009-08-18T21:28:51.163 回答
1

在我工作的地方，我们有 24 小时的限制，这是个人卡可以获得的最多时间。如果不止于此，则应将其分解为足够小的块，以便人们可以在每日站立后看到运动，否则就有点卡在小时数上，可能需要额外的资源来解除阻塞。我个人的偏好是尝试不超过 16 小时，因为发现新问题导致卡在吞噬大量时间方面成为一种黑洞，因此​​估计所需的时间可能会激增。冲刺。

于 2009-08-18T21:15:04.670 回答
1

正如您已经指出的那样，花费比 X 更长的任务可能应该分解成更小的任务，越小越好，因为大多数开发人员真的不擅长估计，我已经说过我提供了长达 3 天工作的准确估计（24小时），但您的团队里程可能会有所不同，所以一定要尽可能少

于 2009-08-18T21:23:30.207 回答
1

我看到两个观点：开发人员的估计和项目经理的控制。

从开发者的角度

我认为没有设置任务估计上限的规则。至少我不能设置一个适用于我工作过的所有项目。

通常，如果任务过于复杂而无法按原样进行估计，或者在项目经理/客户/其他利益相关者没有理由的情况下很难证明估计的合理性时，规则是将要估计的任务分成更小的部分。提供其他详细信息（作为项目经理，我总是询问有关估算的详细信息）。

考虑到这些，我们有 4 小时持续时间（但绝不少于 4 小时）的任务，还有 1 周持续时间的任务（有时是 2 周，但估计是基于历史数据）。

从项目经理的角度

I prefer to manage the tasks at weeks level of duration. Going to detailed subtasks tasks is a matter of micromanagement (usually the team/tech leader has control there) and transforms progress tracking in a big mess, with potential false data.

于 2009-08-19T08:47:37.833 回答