九十九规则在实践中

代码的前90％占开发时间的前90％。其余10％的代码占了开发时间的90％。

—贝尔实验室的汤姆·卡吉尔

实际上这是什么意思？程序员需要做大量工作，他们付出了180％的努力吗？

可以这样想象：开始使用软件时，您可以在相对较短的时间内编写大量代码。此新代码可以添加大量新功能。问题在于，通常功能远非“完成”，可能存在错误，小的更改（业务规模较小）等。因此，由于该软件支持大多数用例，因此该软件可能感觉已完成（90％完成）。但是该软件仍然需要工作。该规则的重点是，尽管感觉软件即将完成，但使软件进入正常工作状态的工作量与达到“即将完成”状态的工作量一样大。这是因为错误修复通常很耗时，但不会产生很多代码。

问题在于大多数开发人员都估计使软件进入“几乎完成”状态，因为与实际估计软件将花费的总精力相比，这相对简单。

它是对一种常见情况的引用，可悲的是今天仍然存在：

1. 要求团队估算（即猜测）编写所有代码所需的工作量，
2. 该项目面临着许多内部和外部压力，要求“按时预算”，
3. 因此，对于很大一部分项目，都会报告“达到目标”。通常，首先选择简单的任务以确保取得良好的进展，这往往会使情况更加复杂。
4. 然后在某个阶段达到了必须接受现实的临界点：项目将无法按时完成，发布日期被推迟（通常是很多次）。

“ 90％”是一个任意数字，但它很好地说明了这一点：估计是猜测，很可能是错误的（通常是非常错误的），而人的本性确保我们几乎总是被估计，因此事情变得过分了。

我听说过这样的不同版本（也称为“ 90-90规则”）：

在实现了90％的功能之后，我仍然必须实现其他90％的功能。

这两个版本都涉及正确估计开发软件产品的工作量的难度以及人们容易陷入的常见陷阱：

• 在需要估算并进行猜测时将统计信息扔出去（“我完成了80％”）
• 着重于要编写的代码的算法复杂性，而这会减少工作量（低估了常见任务的工作量）
• 缺少的步骤（“看不见，心不在“”）
• 低估了维护和更改现有代码的工作量
• 低估了样板代码/“胶水”代码所需的工作量

此规则是80-20规则的补充。现在，对80-20规则有许多不同的解释，但我最喜欢的两种是：

1. 前80％的产品开发需要20％的精力。
2. 80％的错误包含在20％的代码中。

实际上，这意味着以下内容：开发将开始并继续进行，直到注意到第一个延迟的某个特定点。延迟可能具有多种性质：

• 质量控制不良，导致错误
• 客户在此过程中提出的其他要求（原因可能也很多种）
• 从一开始就不清楚需求，这会导致放弃先前开发的某些部分（这也可能导致回归错误）
• 由于范围不明确，人为错误或无法预测的情况而导致的初始低估。这些无法预料的情况可能是生病的叶子，辞职，硬件故障，或者在极端情况下可能是火山喷发（一旦我们不得不推迟项目，因为由于冰岛的火山喷发而无法在现场飞行）。

最重要的是，接近目标要比实际达到目标容易得多。

我发现Wikipedia的解释很有启发性：

最多可得出180％的结果，这是对软件开发项目臭名昭著的怀疑，它大大超出了其进度（请参阅软件开发工作量估算）。它表示了对编程项目的容易部分和困难部分的时间粗略分配，也表示了许多项目迟到的原因是无法预测困难部分。换句话说，与完成项目工作相比，它花费了更多的时间和更多的编码。

实际上这是什么意思？程序员在做大量工作，他们付出了180％的努力吗？

不，程序员总是每单位时间做相同数量的工作。报价是关于低估成本和超支。180％是项目最终花费的时间和金钱。

它大致意味着“这将花费您两倍于您的思考时间”和“您会觉得自己做得很好，直到为时已晚（截止日期已近）”。

实际上，这意味着人们在自欺欺人。

如果程序员说“我们90％完成了”，则意味着90％的构建功能已经花费了。

如果项目经理说“我们完成了90％，我只需要一个人来完成它”，这意味着他们在预算中占90％（可能是50％完成）。这是一个没有钱，寄予厚望和态度恶劣的客户。

区别在于，完成项目要比编码功能花费更多的精力：质量检查，错误修复，复制编辑，部署。

这些事情需要在项目中进行管理，并且是项目经理的责任。这常常使新PM感到惊讶，他们惯于“完成了90％的功能”，却意识到他们只是“完成项目”的一半。