软件成本估算_隐藏的估算成本

软件成本估算

“当我可以做一个更精确的估算时，为什么还要一个粗略的估算呢？”

真的，如果我们可以做得更好，为什么还要半途而废呢？

有一个简单的答案，但是我将在详细的答案之后给出。

让我们从再次询问开始：

为什么要估算呢？

无论是否需要估算，都存在整个#NoEstimates讨论。 除非您的组织足够成熟以处理事实，否则有人会希望做出估计，认为自己可以做些事情：批准任务，延迟任务，为预算做预算，计划后续操作。 某人需要信息来做出决定，并以我们给出的数字为基础。

实际上，除非估计的预期结果之间存在数量级，否则没有关系。 如果我们的最后期限为6个月，并且估计为8个月，则该项目可能会获得批准，因为我们知道可以从中删除范围。 如果我们估计一个项目将花费一年，那么它与下一个项目之间将有3个月的缓冲时间，因为“我们知道它是如何工作的”。 无论我们如何估计，事情通常都会向前发展。

但是，如果我们估计所需的预算是我们认为所需的5倍，则可能导致项目取消。

总而言之，前期估算可用于决策。 实际上，如果您只是进行讨论，而忽略所有讨论，则可以做出相同的决定。

那么为什么我们需要数字呢？

数字是很好的代理。 它们简单，易于管理，我们可以用它们绘制精美的图形。 他们错了，或者在极少数情况下可能是对的，这实际上是无关紧要的，因为我们喜欢数字。

仍然，一个高高在上的人要他们，我们不应该给他们最好的答案吗？

确实，我们应该。 但是我们需要定义什么是“最佳答案”，以及如何获得它。

我们如何估算？

我们如何获得“需要3个月的时间”的答案？

我们依靠过去的经验。 我们希望将我们的经验或其他人的经验用于将过去的类似项目与我们估计的项目进行比较。 我们甚至可能已经收集了数据，因此我们的估计不是基于我们的不良记忆。

软件一直在变化，因此即使是过去的数字也应进行修改。 我们不知道该如何考虑我们不知道该怎么做的事情，或者会困扰我们的“未知未知数”，因此我们将其乘以一个因数，直到达成共识。 我们忘记了东西，我们假设了东西，但最终我们得到了可以接受的“ 3个月”答案。 有时。

我们知道的那部分怎么样？我们可以更精确地估计这一部分。 我们可以将其分解为设计，技术，风险，然后对其进行“更好地”评估。

我们可以。 但是有一个陷阱。

假设完成项目后，我们发现其中30％包含“未知未知数”。 我们本可以非常精确地估计其他70％，但整个估计仍将是不稳定的。

（我在这里非常保守，在估算时，“未知的未知数”是构成项目大部分的原因）。

简单的答案

这就是我们所知道的：

• 估计大部分是错误的
• 人们仍然想要他们
• 估计需要时间
• 精确估算会增加成本
• 由于未知数，精确估计和粗略估计具有相同的统计含义。

这意味着我们需要“足够好”的估计。 这些是成本更低的产品，为提出要求的人们提供了足够好的，可信赖的决策依据。

弗雷德金（Fredkin）的悖论谈到了我们需要选择的选项越接近，决定所需的时间就越长，而两者之间选择的影响差异却可以忽略不计。 有效的估算可以识别出悖论，并加以解决：由于估算中变化的影响，因此无需进一步研究。

如果您获得相同的答案质量，则应该选择更便宜的选择。 精确的估算是昂贵的，并且将其更精确也不会从中受益。 实际上，作为产品经理，我不会要求精确的估计，因为它们使我浪费了金钱和时间，没有花在实际交付上。

可以使用软件而不是综合文档，还记得吗？

翻译自: https://www.javacodegeeks.com/2014/09/the-hidden-cost-of-estimation.html

软件成本估算