分配给单个开发任务的可接受上限时间是多少？

Question

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

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

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

估计21个小时的问题是，如果没有管理层知道这个问题，你可能会失去很多时间，直到为时已晚。此外，大估计可以表明任务定义不明确。当然，这不是一个非常严格的规则，因为很容易设想它的例外。

所以我的问题是：

1. 您的任务估算有上限吗？如果是，您的限制在哪里？
2. 您认为某项任务的可接受详细程度如何？

Answer 1

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

Answer 2

在规划项目时，我不喜欢任何短于2天的任务。在不到一天的时间内限制它似乎相当严格，因为这不会解释具有重要发现组件的任何任务。

我们预订了6个小时的日子，假设其他2个小时将接受会议和其他杂项任务。

Answer 3

如果您跟踪估计/实际历史记录，您可以准确地计算小时数，并确切地确定适合您团队的数字。

Answer 4

在我工作的地方，个人卡可以获得最多24小时的限制。如果不止于此，则应将其分解为足够小的块，以便在每日站立之后可以看到移动，否则就会有几个小时卡住，可能需要额外的资源才能解锁。我个人的偏好是尝试不超过16小时，一些卡片可能会在估计所需的小时内出现气球，因为发现了新的问题导致卡片在吞下大量时间方面成为一种黑洞冲刺。

Answer 5

正如您已经指出的那样，花费超过X的任务可能会被分解为更小的任务，越小越好，因为大多数开发人员的估计非常糟糕，并且说我提供了最多3天的准确估计工作（24小时），但你的团队里程可能会有所不同，所以绝对可以选择最小的

Answer 6

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

从开发人员的角度来看

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

通常情况下，规则是如果任务过于复杂而无法估算，或者在项目经理/客户/难以证明估算的情况下，则将任务分解为较小的任务。其他利益相关者没有提供其他细节（作为项目经理，我总是询问有关估算的细节）。

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

从项目经理的角度来看

我更喜欢在几个星期的持续时间内管理任务。进行详细的子任务任务是一个微观管理的问题（通常是团队/技术领导者在那里控制）并且在一个大混乱中转换进度跟踪，并且存在潜在的错误数据。