估算项目工期时可接受的误差幅度是多少？

我工作的公司的目标是最大误差范围为10％，他们希望分析师不要将估计误差不超过10％。

我不知道该怎么想，因为我没有什么可比拟的。

如果我们或多或少估计太错误了，那么可以衡量一个好的基准吗？您认为可以错过多少（％）？

除非您估计与您和您的同事之前所做的事情非常相似，否则+/- 10％的结果非常乐观。您的管理人员没有太多的软件经验，或者他们没有意识到软件估算的大限制。该论文有一些附带的辅助材料，和很多专家的见解都可以找到。

让我们研究一个比典型软件项目简单得多的系统：Rubik's Cube。您最多可以解决20个动作中的任何位置。但是，由于您要进行估算，因此在给出解决方案之前，您只能查看给定的多维数据集几分钟。你能给个好估计吗？不可以，有时估计一个过程所花费的时间比完成该过程要长。

另一个简单的系统：木偶奇遇记。一个木制的自动机，当他撒谎时他的鼻梁会长大。当木偶奇遇记休息时，然后说“我的鼻子在长”，会发生什么？有些系统无法预测，无法确定。

这两个问题是大多数软件系统内置的。因此，您永远不会获得接近+/- 10％的估算值。

我的建议是给出一个很大的填充估算值，像一个奴隶一样工作，以尽可能快地完成项目，然后看起来很忙，直到您低于或超过10％。届时，宣布取得惊人的成功。

对于任何类型的“目标错误余量”，我都会非常犹豫，因为它确实取决于项目。如果您要估计安装，配置和自定义新CRM系统需要花费多长时间，而没人能完全确定需要哪种类型的自定义，以及需要哪种类型的业务流程更改，以及该公司没有类似大型项目的历史，您的错误率应该很大（例如，您可能会猜测，将需要18个月+/- 50％的时间，报价为9-27个月）。随着项目的进行，规格会变得更加清晰，有关业务流程的决策会变得更加清晰，开发人员也会变得更加自在，等等。这些错误的余地会越来越小。如果您想估算在您建立第101个基本电子商务网站之前需要花多长时间 从前100个方面获得了良好的历史，您希望能够提供更准确的估算。但是，大多数项目都将落在中间。

现在，如果您引用一个数字而不是范围，那么答案可能是开始引用范围，以便进行估算的人员可以指定他们期望的估算值有多准确。

一个好的基线应该是基于您收集的真实数据的基线。

这样做的第一步是记录所有估计。第二步是记录实际结果。老实说，不要试图“自我调整”实际情况。收集足够的这些信息，您便可以使用一些数据来统计您的估算值。请注意，这可能/将根据由谁进行估算和由谁进行工作而千差万别。只有这样做，才能合理地期望您提供“错误余量”，这是其他任何纯垃圾。

它也不止于此。分析导致估算不符的原因可以帮助提高未来估算的准确性。注意：它们仍然是估算值，因此仅是估算值。

第一次估算后，估算也不会结束。随着项目的进展，随着获得的更多知识，可以对此进行调整，从而减少了您继续进行时可能出现的误差。沟通越开放，讨论的惊喜就越早-从而使人们感到不那么惊讶，并留出更多时间来调整项目或客户期望。

其次，也许更好的处理误差容限的方法是“ 置信内部 ”，而不仅仅是误差容限的百分比。您而不是根据置信区间而不是单数的日期来估计交货日期。

PERT是处理基于统计推理的估计的框架的一个示例。例如：

“根据我现在所知道的，我们可以在8个月内实现90％的置信度。在10个月内实现95％的置信度，在2年内实现99％的置信度，等等。”

请在此处注意：他们对您的信心越强，估计值就会越大。根据复杂性（又称精度），可能相差80％和90％之间很小，也可能很大！

最后-祝您好运；）如果您解决了软件估算中的“最大错误余量”，从而可以指定“我们的所有估算为+/- 10％”之类的内容，请确保在余下的时间里放映一部票房电影我们在软件行业。我在想类似Office Space和Matrix：D之间的交叉

实际上，这很大程度上取决于项目的规模和复杂性。

如果您的项目估算为1周-10％是合理的。表示+/- 1/2天。
如果是1个月，那么10％会摇摇欲坠-根据我的经验，无法预测您在1个月后会发现什么。

超过一个月-所有投注均关闭:)。

这些是针对每个开发人员的-因此对于4个开发人员团队，1周== 1个月。

对于一个由4人组成的开发团队来说，拿出可以在1个月内完成的功能列表，并且在这些功能的10％之内，是一件好事。然后，重新估算下个月。

我在这里做了一些幼稚的假设

1. 所有开发人员都可以并行工作。
2. 没有考虑过测试人员-他们应该有一些时间进行测试
3. 所有开发人员都是平等的-前端，后端，设计师等...

您必须将这些因素考虑在内。但这是一般的想法。

有很多变量：

1. 该项目需要多长时间？

2. 项目将如何管理？瀑布？敏捷？SCRUM？

我想从瀑布问题开始。如果是这样的话，考虑到保证金的要求，您很有可能会失败一定比例。

如果答案是某种敏捷方法论，尤其是像SCRUM之类的方法。保证金百分比是多少并不重要。两周Sprint的50％的误差幅度为1周，而在1周Sprint上的误差率为2.5天，这两种情况都是最糟糕的情况。这是因为每个Sprint都会重新估计交付日期，随着时间的推移，交付日期将越来越准确，而不是越来越少。

使用Waterfall的50％的误差率并非没有，但是在12个月的项目（即6个月）中，它并没有真正被发现/承认直到12个月中的10个月都是如此。

以前，当我领导软件团队时，大约在白垩纪/第三纪界附近，我们实际上接近达到+/- 10％的估算值。如果我的记忆很狡猾，大约是+/- 15％。但这是因为我们正在估算已经完成的工作：相对简单的实时通信固件，该固件在我们设计的实时环境中使用我们熟悉的语言从A提取了字节并将其移至B。 ，与几个办公室以外的人在内部设计的硬件进行通讯。许多上述主题轻微变种，字面的年。

坦率地说，在正常的软件项目评估中期望达到这种错误率是可笑的。当您看到它明显实现时，是因为人们高估了并填充了（做额外的东西和宠物项目以消耗预算），或者人们低估了并在晚上和周末像狗一样工作以弥补时间。

您可能听说过300％的内容对吗？

我实际上使用它。完全基于我多年来的见识。当我听到一两天，这是一个星期或更要真正完成。并经过测试。在所有环境中。文档已更新。可用性测试。性能测试。负载测试。几个小时真的更像是一天。

我认为我们的确很不好估计，因为：

• 帮助别人
• 被打断
• 培训新人
• 其他东西来了
• 生病或不适
• 掩盖离开的人
• 需要休假或休息
• 被别人分心
• 被其他团体牵制
• 对现实过于乐观
• 没有为处理间歇性测试失败分配时间
• 轻松排除测试时间，尤其是编写自动化测试

因此，在最高水平上，对于需要超过300％的估计的业务人员，我们最终要做的是针对合理的估计，但要付出更高水平和更笼统的代价。即使版本1表示仅一组用户更改1个字段，“我们将具有用户编辑功能”。

关于“估算项目工期时可接受的误差幅度是多少？” 我发现，在许多敏捷环境中使用的这种方法有助于将问题更改为使Alpha或Beta版本生效并对其进行迭代的最低功能是什么。