Scrum: 在软件开发中应用80:20规则-CFANZ编程社区

在软件开发中应用80:20规则

我们喜欢简单的经验法则，越简单越好。最有用的经验法则之一是80:20规则：

80％的影响来自20％的原因，80％的影响来自20％的努力。

这意味着：通过更聪明，更努力地工作，你可以从做得更少中获得更多收益。

您可以看到80:20规则适用于软件开发而不太费劲的明显情况。例如，通过优化20％的代码可以找到80％的性能改进 - 尽管在性能优化方面，实际比率可能更接近90:10甚至99：1。但无论是80:20还是90:10或70:30，规则的工作方式基本相同。

80:20规则 - 谁使用了什么，你真正需要做什么

软件中另一个众所周知的80:20规则是80％的用户只使用20％的功能。这是2002年Standish集团的研究成果，他们发现：

Scrum: 在软件开发中应用80:20规则_开发人员

45％的功能从未使用过;
19％很少使用;
有时是16％;
只有20％经常使用或总是使用。

就像变化成本曲线一样，这是软件开发中广泛持有的“真理”的另一个例子，它基于有限的证据 - 看到更多支持这种说法的研究会很好。

这一发现极大地影响了敏捷和精益开发，鼓励人们专注于提供最小的可销售功能或定义最低可行产品，即使在大型企业项目中也是如此。不要试图设计和规划系统可能需要的所有功能，而是提出人们认为重要且有用的最小，最严格的定义，优先考虑功能并尽快分步。

Standish Group的最新研究表明，思考更小，交付更少是提高软件项目成功的关键：虽然超过70％的小项目成功交付，但大型项目“几乎没有成功的机会：......机会超过两倍迟到，超出预算，缺少关键功能“。

“总之，毫无疑问，专注于为您提供80％价值的20％功能将最大化软件开发投资并提高整体用户满意度。毕竟，没有足够的时间或金钱去做所有事情。对于管理人员和利益相关者来说，自然的期望是想要一切并且现在都想要它。因此，缩小范围而不是完成100％的特性和功能不仅是一种有效的策略，而且是一种谨慎的策略。“

但是思考规模小，交付速度越来越快也会产生不利影响：“当价值和创新减少”时，人们过于安全并且设置的标准太低。提供20％或50％的系统并不总是足以取得成功，甚至假设你可以弄清楚正确的20-50％是什么 - 其中一些“额外功能” 对于某人来说仍然是重要和必要的，即使它们用得不多。您需要的不仅仅是最不可行的产品，以重新定义市场或人们的工作或娱乐方式，让世界炙手可热。

80:20规则 - 错误和测试

代码质量，错误和测试是80:20规则特别有用的另一个领域：

在20％的代码中发现80％的错误
90％的停机时间来自10％（或更少）的缺陷

错误集群在代码的某些部分，尤其是严重的错误。大多数最严重的问题都来自少量的错误。

“Windows和Office中80％的错误和崩溃是由检测到的整个错误池中的20％引起的。”
微软首席执行官：80-20规则适用于错误，而不仅仅是功能2002年10月

了解大多数最严重的错误是什么以及为什么他们到达那里以及您需要做些什么来防止更多错误是您应该花费大量时间的地方。

一些研究发现，一半的代码可能根本没有任何错误，而大多数错误只能在代码的10-20％中找到 - 通常是最常更改的代码的10-20％（参见“ 80:20哪些代码被更改，以及“下面”的频率。

每当您在此代码中发现错误时，可能意味着还有更多错误需要查找和修复。你找到的bug越多，就越有机会发现还有更多的bug，这是一个下降的螺旋。

Capers Jones表示，必须处理 - 或解决 - 高风险容易出错的代码是系统生命周期内开发人员工作效率的最大拖累，并且没有弄清楚哪些代码导致您最麻烦并且做某事关于它是开发团队可以做出的最昂贵的错误之一。

每当你触摸这段代码时，即使你正在尝试修复它，你很可能会让它变得更糟，而不是更好：开发人员尝试修复bug的可能性超过20％。容易出错的代码会不小心引入新的bug作为副作用。尝试理解这些代码并修复它并理解并反复修复它的大部分努力都被浪费了：

“大多数易出错的模块都非常复杂，难以理解，一旦创建它们就无法修复”。

当代码变得糟糕时，它需要广泛和“ 残酷的重构 ”以使其易于理解和使用，或者需要通过从头开始由知道他们正在做什么的人编写的新代码“ 手术移除和替换 ”。

如果你有相同的人在一段时间内处理相同的代码，那么识别代码的哪些部分是不好的并不难 - 问问团队中的任何人他们会知道那个讨厌的臭味来自哪里。在具有大量营业额的大型系统和大型组织中，您可能需要随时跟踪错误并挖掘错误集群的缺陷数据，而不仅仅是修复错误并继续前进。

修复错误花费的时间占错误的20％

有些bug比其他bug更难修复。有时因为代码太差了（参见上面的规则）。有时因为问题很难重现和调试。有时因为它们比它们看起来要深得多 - 设计中的基本错误，你无法编写出来的错误。做好准备，即使你最好的开发人员也无法告诉你何时 - 或者甚至 - 某些错误将被修复。

80:20规则 - 哪些代码会发生变化以及频率变化

通过查看代码库随时间的变化（“ 从版本控制系统中发现令人吃惊的事物 ”）， Michael Feathers发现了更多80:20的幂律分布：

80％的更改是在20％的代码中进行的

许多代码只编写一次，并且从未改变过：静态和标准化接口，基本布线和配置，后台功能。然后还有其他代码一直在变化：20％的功能在80％的时间内被使用，需要进行调整和调整，并随着需求的变化偶尔进行大修; 需要优化的核心代码; 和其他代码需要修复很多，因为它包含太多的错误（再次回到上面的80:20错误集群规则）。

Feathers发现随着时间的推移，随着时间的推移，变化很大的代码也会变得更大，因为简单的内置偏见：

将代码添加到现有方法比添加新方法更容易，并且更容易向现有类添加另一个方法，而不是添加新类。

因此，许多系统最终会得到一些非常大的类，这些类包含一些非常大的方法，并且随着代码的变化而不断变大和变大。

通过查看具有高流失率的区域的签入历史记录以及通过对代码库的简单静态分析，可以轻松找到代码中的热点。这是您从重构中获得最大价值的地方，您可以在这里尽最大努力使代码不会丢失结构并变得危险地无法维护 - 而且它也是自然应该作为更改的一部分进行重构的代码（已更改）如果你正确地进行重构，通常会更频繁地重构。

80:20规则 - 编程时间

前80％的代码在20％的时间内完成 ...其余20％的代码占用了其他80％的时间

通常不需要很长时间就可以获得几乎正常工作的东西，或者看起来像是有效的东西，特别是如果你以迭代和渐进的方式工作，经常快速地提供。

但是还有很多工作需要“在幕后”完成，抓住边缘案例并处理错误，确保系统执行和扩展，找到并修复所有的小错误，得到代码在部署之前就变成了形状。产品所有者/客户（和经理）通常不理解为什么花费这么长时间才能完成工作的“最后20％”。程序员经常会忘记这需要多长时间，并且不会在预算中包含这项工作。这就是为什么开发人员的估计经常是错误的。为什么原型设计在设定不切实际的期望时会如此危险。