所有的估算都是错的，但并非都没有用处

Dr Milan Milanović 2023年8月10日

如果你在团队中使用 Scrum 框架，你会使用 story points 来估算故事、任务等的所需工作量。一些管理层也会考虑这一点，进行计划、衡量你的生产力，甚至在你完成某项工作时让你负责。然而，他们需要明白软件估算总是错误的。

主要原因是估算本质上是预测，是对未知未来的推断。我们都知道不可能预见到最终结果，但人们往往会忘记这一点，并根据估算做出承诺。

制定计划通常是好的，因为它们允许我们迭代地工作，不断为客户提供价值。然而，项目通常非常复杂，涉及许多团队以及团队之间的依赖关系。

为什么计划会失败？ 有很多原因，例如需求不明确、未考虑到知识水平、软件需求被低估、未考虑技术债务等等。

此外，还有一些其他因素导致 Estimation 失败：

1. **Hofstadter’s Law（侯世达定律）**指出，“它总是比你预期的要花费更长的时间，即使你考虑了侯世达定律”。它强调了估算的递归性质，即考虑到任务的复杂性和人类的乐观情绪通常会导致低估。
2. **Brook’s Law（布鲁克斯定律）**指出，“向延期的软件项目增加人手会使其更加延期”。这条定律强调了增加团队规模以加快项目速度的负面影响。新团队成员需要时间来上手，并且额外的沟通会增加，进一步延迟项目。
3. Planning Fallacy（计划谬误）：这种认知偏差会导致人们低估完成任务所需的时间和资源。在软件估算中，开发人员可能需要更多地关注潜在的障碍或对自己的能力过于乐观，从而导致不准确的估算。
4. Bikeshedding（脚踏车棚效应）：这条规律指出，人们倾向于关注琐碎的细节，而不是项目的关键方面。在软件估算中，这可能导致过度强调容易理解的任务，而低估更复杂的任务。
5. **Parkinson’s Law（帕金森定律）**指出，“工作会膨胀，直到用完完成它所用的时间”。这条定律表明，如果截止日期过于宽松，开发人员可能会在任务上花费比必要更多的时间，从而导致效率低下和延迟。
6. **Ninety-Ninety Rule（90-90规则）**指出，“最初90%的代码占用了最初90%的开发时间；剩余10%的代码占用了另外90%的开发时间。” 这条规则强调了准确估算修复错误、优化和润色所需时间的难度。

此外，我们还必须处理 The Cone Of Uncertainty（不确定性锥）（由 Steve McConnell 引入软件开发领域）。通常，在项目的早期阶段，我们仍然不了解所有需求，但我们需要做出许多决定。 在这里，不确定性很高。 随着项目的进行，我们掌握了更多信息，不确定性降低。

The Cone of Uncertainty

⚠️ 请注意，在“The Leprechauns of Software Engineering”一书中，作者声称“不确定性锥”从未基于可靠的数据。它最初是 Barry Boehm 的主观猜测，Steve McConnell 通过他的 1996 年著作“Rapid Development”将其推广开来。

对此有哪些补救措施？ 在他的著作“Software Estimation Without Guessing”中，George Dinwiddie 提供了宝贵的见解和技术，以提高软件估算的准确性和可靠性：

• 使用你的估算来跟踪进度，以创建反馈循环（例如，燃尽图）
• 估算错误是可以接受的。
• 估算，然后放入一些应急缓冲区。
• 为意外情况留出一些空间。
• 充分衡量已完成或未完成的内容（你可以在此处使用测试自动化）
• 使用诸如 COCOMO model 之类的模型：
  • 首先，从评估交付的代码行数中获得对开发工作的初步估算。
  • 从各种属性中确定一组 15 个乘法因子。
  • 通过将初始估算值与所有因子相乘来计算工作量估算值。
• 面对面的沟通技巧至关重要。

除此之外，我的经验是：

• 通过将大型复杂任务分解为更小、更易于管理的任务来分解任务。 例如，我们发现估计最多需要3个工作日的任务是准确的。
• 始终对估算保持保守，特别是如果存在任何未知数；它应该建立在复杂性之上。 众所周知，开发人员是乐观主义者。
• 我们之前做过类似的事情吗？ 如果没有，可能会增加更多复杂性。
• 估算应随着项目的进行定期更新和校准。 这有助于项目适应变化并确保其保持在正轨上。
• 如果代码是遗留代码，我们的团队中是否有人了解它，或者我们是否有文档？
• 我们是否知道与该故事相关的所有风险？ 如果没有，这将增加不确定性。
• 始终包含风险缓冲区和不确定性。
• 软件估算没有万能的方法。 不同的项目和环境需要不同的方法。
• 从你的字典中删除“**快速”、“简单”、“直接”、“容易”**以及每个类似的词。 永远不要使用它们。
• 为了安全起见，估计一下你认为完成任务需要多长时间。 将该数字乘以 3。 这将是你估算的较低范围。 将估算的较低范围加倍。 这将是上限范围。 例如，对于 1 天的工作，说 3 - 6 天才能完成。

估算 = 复杂性 + 不确定性

"Software Estimation Without Guessing" by George Dinwiddie

除了以上所有内容外，Vasco Duarte 在他的著作“NoEstimates: How to Measure Project Progress Without Estimating”中提出了一种替代方法。

他反对传统的估算方法，例如 story points。 Duarte 认为这些方法不够准确，造成了一种精确性的谬论，并导致沟通不畅和不适当的压力。 相反，他建议放弃 story points（实际上，每个用户故事都值一个 story point）并交付能够提供重大价值的少量工作，利用吞吐量或周期时间等经验数据来准确反映能力和生产力。

衡量标准应基于吞吐量（在设定的时间范围内完成的任务数）、周期时间以及从开始到完成一项工作所需的时间。 诸如 Kanban 之类的可视化系统可以帮助跟踪进度并识别瓶颈。 定期的回顾和反馈可以实现持续改进，从而增强迭代开发的重要性，以促进快速交付少量增量价值。

“NoEstimates: How To Measure Project Progress Without Estimating,” by Vasco Duarte