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

当被要求估算和/或在阅读我的同事估算时，他们通常会阅读以下内容：

制作新的、有特色的页面，8小时

创建新的控制-21小时

解决模块中的错误-15小时

我认为当一个任务的估计超过5小时时，你应该强烈考虑把任务分成更小的子任务。

像21小时这样的估计值的问题是，你可能会损失很多时间，而管理层却不知道，直到一切都太迟了。此外，较大的估计值可能表明任务定义不明确。当然，这不是一个非常严格的规则，因为很容易设想例外情况

因此，我的问题是：

你的任务估计有上限吗？如果有，你的上限在哪里

您认为任务的可接受详细程度是多少

---

当我们做计划时，我们把事情分成4个小时的任务（最长）。而且，我们每周只计划4个工作日。（我们估计剩下的时间都被会议等占用了）

在我工作的地方，一张卡最多只能使用24小时。如果不止这些，它应该被分解成足够小的块，这样你可以在每天站起来后看到运动，否则你会在小时数上被卡住，可能需要额外的资源来解除阻塞。我个人的偏好是尽量不要超过16个小时，因为一些卡片可能会在估计所需的时间内膨胀，因为新问题被发现，导致卡片成为一种黑洞，在冲刺中吞噬了大量的时间。

正如你已经指出的，花费时间超过X的任务可能应该分为更小的任务，越小越好，因为大多数开发人员在估算方面非常糟糕，我已经说过，我已经提供了长达3天（24小时）的准确估算，但您的团队里程可能会有所不同，因此，一定要尽你所能做到最小。如果你跟踪你的估计/实际历史，你可能可以精确地绘制小时数，并准确地计算出适合你的团队的数字。

在规划项目时，我不喜欢任何任务短于2天。将其限制在任何少于一天的时间似乎都是相当严格的，因为这并不能解释任何具有重要发现组件的任务

---

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

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

从开发者的角度来看

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

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

考虑到这些因素，我们的任务持续时间为4小时（但不少于4小时），但也有持续时间为1周的任务（有时为2周，但评估基于历史数据）

从项目经理的角度来看

---

我更喜欢以周为单位管理任务。进入详细的子任务任务是一个微观管理的问题（通常由团队/技术负责人控制），并在一片混乱中转换进度跟踪，可能会产生虚假数据。

这很有趣，我想我们也同意这一点。我并不是想提出一个严格的估计上限，我只是认为一个高估计值回避了一个问题：“你会用这些时间做什么？”。如果你不能像那样细分一个高估计值，那么它可能会有一个高风险。但当然，你不应该仅仅发明子任务来达到某个任意的估计下限，它应该有明确的目的，比如使规范更加精确和/或易于管理。一天下来，很难在规格过高和规格过低之间取得平衡，我只是好奇其他人是如何做到的这是一个非常好的建议，我过去也尝试过这样做。虽然没有什么成功。1.不幸的是，我无法直接访问这些号码。。。既不是所有的估计时间，也不是登记的小时数。（我不是经理）2。任务规范和小时登记是完全独立的系统，因此它们通常会失去同步。因此，要将登记的小时数与原始估计值进行对应，即使不是不可能，也是很困难的。不幸的是，当我与经理讨论这些问题时，他们似乎对改进流程不太感兴趣。@JohannesH谢谢。如果你感兴趣，我只是尝试了一下，并将结果发布在我的博客上。我得说，它并不像我想象的那样。根据我的经验，80%的利用率也是一个不错的数字。我佩服你们团队将事情分解成4小时一组的纪律性。：）我投票结束这个问题，因为它与编程无关。