估计编程任务需要花费多长时间？

例如，如果我将一个项目分解为n个离散的工作产品（例如类，功能或组件），是否有时间t使得n * t是用于估算的合适时间？

如果您有足够的信息将其分解到该级别，则每个信息的花费都不应超过一分钟。无论如何，你都不会正确，但是一分钟后和一小时后一样，你会变得正确。

另一方面，如果您是在谈论用户故事，我建议您将利益相关者放在一个房间里，并花五分钟询问一下问题，然后再进行估算。

无论如何，不​​要浪费太多时间进行估算。它们没有用或不够准确，不值得付出努力。

以我的经验，敏捷方法的核心“是的，确实有效”的部分是“任务应该用不到一天的时间”指导原则。如果您估计需要花费超过一天的时间，那么您将相去甚远。

将它们分解成可以完成的工作就足够了；不管这些东西到底是什么。

在敏捷的Scrum方法中，Planning Poker被视为一种有效的方法，可以利用整个团队快速估算sprint中用户故事所需的工作量（假设这就是您所要讨论的）。否则，我不会花费几分钟多的时间来估计用户故事中的一项任务。

如果您要为一组开发人员进行估算，我强烈建议您使用这种基于共识的技术。

计划扑克意味着您可以在单个会话（不超过1-2小时）内为每个用户故事获得一些不错的估计。

对此进行一些阅读并尝试一下！

同样，作为一般规则，用户故事中的任何任务都不应超过7.5小时（一天的工作时间）。如果是这样，则需要将任务分解为较小的任务。

我认为这取决于您的需求。例如，如果项目的资源分配依赖于它（有时就是这里的情况），则最好谨慎地进行。换句话说，如果您正在执行的项目没有这种必要性，那么您可能不会做太多的细节工作。花太多时间不是一个好主意，因为很难进行准确的估算。

有一个名为著名的概念不确定性的锥和维基百科不确定性锥，说多少准确的估计，通常都可以。值得一读。

您从估计中得到什么？

取决于您所做的工作，准确的个人估算值可能是有意义的（客户在本周末向您付款，或者任务/故事对其他人不利，并且需要精确的ETA）或否（您积压了200个故事，如果故事转变了一周，没有人会死，而您指望估计出的错误可以使很多错误平均出来。

只需花费最短的时间即可获得足以满足您需求的估算值。没有公式。

就我个人而言，我认为超过一两分钟意味着您可能正在估计错误的事情（将其拆分或计划发现）。

实际上，您需要估算值来帮助其他利益相关者分配相对优先级-因此，基于广泛的估算值至少可以说task1大约是task2的3倍（即使就小时数而言，它最终并不是十分准确）。需要花费大量时间来了解这些任务是什么（用于实现某些目标），然后对其进行粗略估算。

一旦有了相对优先级，就可以专注于做事并在途中调整估算值。换句话说，花很少的时间进行前期估算，但是会随着时间的流逝而完善估算，以便项目计划在完成时给出一个好主意。

好的估计是基于事实而不是假设的一次。

因此，如果您已经有一个类似的项目并捕获了您之前的估算时间，则可以将其作为良好的估算基础。但是，根据您的项目范围，可能会有未知的工件，最好尽快与BA或产品负责人进行澄清。

也可以这样说：软件项目估算本质上是不准确的。但是，有些现实的估算方法可能会有所帮助：

• 从事这项工作的人应该参与项目评估
• 聘请专家：专家判断对于项目成功至关重要
• 估计大件物品的范围
• 使用Delphi技术： 如果在软件项目评估中存在冲突，此方法可帮助汇聚团队的意见。
• 记住成本
• 请记住分配的资源可用于执行工作