每个开发人员都必须了解的一张图表

我们的行业以项目交付延迟和预算超支而闻名。许多项目被直接取消，还有很多项目交付的价值从未达到我们向客户承诺的水平。然而，有一小部分软件开发机构始终如一地交付卓越的成果。而且他们自 20 世纪 70 年代以来就知道如何做到这一点。在这篇文章中，我将向你揭示他们的秘诀。

一切都始于理解史蒂夫·麦康奈尔的这张图表。它描述了缺陷率和开发时间之间的关系。

该图表表明，如果大多数团队将更多的精力集中在缺陷预防、早期缺陷消除和其他质量问题上，他们就可以更快地交付软件项目。

但这个图表是真的吗？

1996 年，史蒂夫·麦康奈尔 (Steve McConnell) 在一篇名为《极速软件质量》的博客文章中发布了这张图表。该图表（以及那篇博客文章）总结了他那本优秀著作《快速开发》中的部分数据。这本书部分基于卡珀斯·琼斯 (Capers Jones) 截至 20 世纪 90 年代初的研究。我之所以列出所有这些日期，是想让你们知道，我们究竟已经知道这个事实多久了：

在软件中，更高的质量（以更低的缺陷率形式）和更短的开发时间是相辅相成的。

无论如何，Capers Jones 坚持进行研究，并于 2011 年与合著者 Olivier Bonsignour 共同出版了另一本书，名为《软件质量经济学》。他们分析了 1973 年至 2010 年间来自 660 多个组织的 13,000 多个软件项目，并收集了更多证据证明：

...高质量水平总是与比平均水平更短的开发时间表和低于平均水平的开发成本相关。

换句话说，史蒂夫麦康奈尔的图表是真实的。

那么问题是什么呢？

有三个问题。

问题 1：我们忽视了研究

大多数项目的运行都仿佛这张图表是假的。几乎每天都会听到一些项目或某个人因为判断失误而遭受惨痛打击。每年都有数十亿美元因这种愚蠢行为而损失。自从我们开始编程以来，这种情况就一直存在。每个开发人员都经历过。而且这种情况似乎没有尽头。

例如，为了加快进度而给自己施加压力（或屈服于外部压力），几乎肯定会增加缺陷率，拖慢项目进度。然而，这种情况却屡见不鲜！

但问题远不止于此。项目经理要为最严重的项目灾难负责。我们有一些负责这些项目的人，虽然初衷是好的，但却对自己的工作一无所知。他们的许多项目从一开始就注定要走向灾难（参见下文提到的“经典”软件错误）。等到他们意识到项目陷入困境时——通常是在开发人员得出相同结论的几个月后——往往已经为时已晚，无力挽回。

问题 2：小型项目开发实践无法很好地扩展

那些在小型项目中相对有效的开发实践，无法扩展到大型的现实世界项目。大多数学生只参与小型项目。所以他们毕业时误以为自己知道如何开发软件。但当我们试图雇佣他们建造摩天大楼时，他们却一直在建造相当于花园棚屋的东西。摩天大楼可不是那种真正的大型花园棚屋——它们是完全不同的东西。

由于软件开发做得好的组织寥寥无几，许多团队只能用花园棚里那种老掉牙的方法来应对摩天大楼里的问题。结果，这些可怜的开发人员认为，混乱、困惑、bug、需求冲突、无休止的测试周期、错过截止日期、压力、成堆的返工和“死亡行军”都是软件开发的正常现象。

问题 3：许多团队不具备所需的技能

在实际项目中，要实现低缺陷率，你需要的不仅仅是纯粹的技术技能。你需要一整套组织、管理和技术层面的战略和策略来实现这一目标。你几乎肯定需要为组织中的每个人提供额外的培训，这还需要你接受不同的开发实践。

要达到 95% 的发布前缺陷消除率需要什么？

对于大多数组织而言，要实现 95% 的发布前缺陷消除率，需要进行相当大的调整。但好消息是，即使发布前缺陷率只是略有改善，也会对项目的经济效益产生积极影响。

考虑到这一点，我建议采取以下步骤：

1. 接受一个事实：高质量软件比低质量软件开发速度更快、成本更低
2. 注意史蒂夫·麦康奈尔的“经典”软件错误
3. 尽可能使用内存安全的语言
4. 开始改进您的开发实践

让我们开始吧。

接受一个事实：高质量软件比低质量软件开发速度更快、成本更低

如果你需要更多证据，请阅读《软件质量经济学》，它能让你和你的队友真正相信这张图表所言非虚。本书作者毫不怀疑：

2011年现有的最佳质量成果非常出色，但这些成果尚未得到充分理解，也未得到广泛应用，原因之一是人们错误地认为高质量软件成本高昂。其实，高质量软件并不昂贵。与低质量软件相比，高质量软件的构建和维护速度更快、成本更低，从最初的开发到总拥有成本，都体现了这一点。

此外：

如果在每个主要软件项目中都采用最先进的缺陷预防、预测试缺陷消除和正式测试的组合，那么与 2011 年的平均值相比，交付的缺陷数量可能会下降 60%。

这是为什么？

低质量项目在测试、调试、修复和返工上花费的时间比高质量项目多得多。事实上，低质量项目包含的缺陷数量之多，导致测试时间往往比构建时间还要长。而且，低质量项目经常在发现所有缺陷之前就停止测试。

在瀑布项目中，他们要么按原样发布软件，要么取消项目，因为否则测试和修复将永无止境。在敏捷项目中，增量工作一开始完成得很快，但随着现有代码中发现越来越多的问题，进度会变得缓慢。最终，低质量的敏捷项目会面临与瀑布项目相同的选择：按原样发布或取消项目。

高质量项目在缺陷预防和测试前缺陷移除方面投入了大量精力，以便在测试阶段发现并修复的缺陷数量大幅减少。高质量项目比低质量项目发布更快，成本更低，因为它们的测试阶段更短，返工更少。此外，高质量项目发布后需要修复的问题也更少。因此，当需要进行更改时，高质量项目的代码修改起来更容易，成本也更低。

让我们看一下《软件质量经济学》中的一些关键点：

• 1973年到2010年，整体质量水平并没有太大变化。IDE、新语言、解释型语言、自动化测试工具、静态分析工具、更优秀的库、框架、持续集成、成千上万的书籍、敏捷开发、Scrum、极限编程、面向对象编程、测试驱动开发以及整个网络，都没能带来什么改变！真是令人沮丧。（我知道有人会反驳这种说法。你可以去《软件质量经济学》 538和539页看看。）
• 在低质量的软件项目中，近 50% 的精力用于查找和修复缺陷和返工。
• 缺陷率的增长速度比项目规模更快。这意味着，在 5 KLOC 的项目中，为了确保 95% 的发布前缺陷消除率，你需要做的事情与在 500 KLOC 的项目中完全不同。更大的项目不仅需要更多的 QA 活动，而且还需要不同的 QA 活动。记住，摩天大楼不仅仅是一个超大的花园棚屋。
• 自软件行业诞生以来，测试一直是消除缺陷的主要方式，并且在许多项目中，它是唯一使用的方式。这很遗憾，因为测试的效率并不高。即使结合6到8种测试方式，你也无法指望在大型系统中消除80%以上的缺陷。
• 缺陷预防方法包括重用、正式检查、原型设计、PSP/TSP、静态分析、根本原因分析、测试驱动开发 (TDD) 等。对缺陷预防影响最大的因素是需求变更过多、进度压力过大以及缺乏缺陷或质量衡量标准。
• 最有效的预测试缺陷消除形式是正式检查和静态分析。但作者还讨论了其他23种预测试缺陷消除方法、它们的预期结果范围以及何时可能需要使用它们。
• 对于更好的表格预测试缺陷消除而言，每花费 1 美元，其投资回报率将超过 10 美元。
• 本书讨论了 40 种测试、它们的有效性范围以及何时可能需要使用它们。

我认为这本书的真正价值在于它提供的证据，可以帮助你反驳那些对项目成本和进度产生特别负面影响的想法和做法。例如，读完这本书后，你很难再说自己没有时间进行代码审查了。

注意史蒂夫·麦康奈尔的经典软件错误

在《快速开发》第 3 章中，史蒂夫·麦康奈尔列出了 36 个“经典”软件错误。

即使犯其中一个错误，也可能导致项目开发进度缓慢且成本高昂。如果你想提高效率，就需要避免所有这些错误。

它们是：

1. 动力被削弱
2. 人员薄弱
3. 不受控制的问题员工
4. 英雄事迹
5. 为延期项目添加人员
6. 嘈杂、拥挤的办公室
7. 开发人员和客户之间的摩擦
8. 不切实际的期望
9. 缺乏有效的项目赞助
10. 缺乏利益相关者的支持
11. 缺乏用户输入
12. 政治高于实质
13. 妄想
14. 过于乐观的时间表
15. 风险管理不足
16. 承包商失败
17. 规划不足
18. 迫于压力放弃规划
19. 模糊前端的浪费时间
20. 上游活动不足
21. 设计不足
22. 质量保证不足
23. 管理控制不足
24. 过早或过于频繁的收敛
25. 从估算中省略必要的任务
26. 计划稍后再追赶
27. 地狱式编程
28. 镀金要求
29. 功能蔓延
30. 显影镀金
31. 推拉式谈判
32. 研究导向型发展
33. 银弹综合症
34. 高估了新工具或新方法带来的节省
35. 在项目进行过程中切换工具
36. 缺乏自动化源代码控制

快速开发 (Rapid Development)于 25 年前发布。然而，其中 35 个经典错误至今仍屡见不鲜（Subversion 和 GIT 在很大程度上解决了第 36 个错误“缺乏自动化源代码控制”）。

查看史蒂夫·麦康奈尔 (Steve McConnell) 更新和改进的“经典软件错误”列表。

尽可能使用内存安全的语言

这个建议没有出现在这两本书中，但我认为这是 2019 年的一个重要观点。每年通过安全更新解决的微软产品中大约 70% 的漏洞都是内存安全问题。

至此，很明显，人类无法使用 C 和 C++ 等内存不安全的语言来编写大型系统，否则就会犯下大量错误，或者花费巨额金钱来查找和消除这些错误。

如果微软连他们的软件都无法避免这些错误，那么想着你能做得更好就太不合理了。所以，如果你要开始一个新项目，请选择一门内存安全的语言。即使是最苛刻的领域，也有一些内存安全的语言，所以不要因为担心性能影响或兼容性问题而放弃尝试。

开始改进您的开发实践

好的。所以，你现在相信图表是正确的，并且你进一步相信自己位于最佳点的左侧。接下来做什么？当然是尝试让你的组织沿着曲线向下移动，朝着图表上的最佳点前进。

你的第一步是让大家接受低质量是你项目的一个问题。既然质量是大多数项目的问题，那么找到证据来支持你的观点应该不难。《软件质量经济学》第二章将帮助你建立一个缺陷跟踪系统，以追踪正确的问题并避免常见的测量陷阱。掌握关于低质量成本的可靠数据将有助于你证明你的观点。

下一步是说服自己和团队不要走捷径，因为捷径几乎总是适得其反。把图表打印出来，必要时贴在墙上。

接下来，我建议您在整个团队中实施一个小的改变，尝试一段时间，评估结果，保留或放弃改变，然后选择其他东西来改进并重复这个循环。

并非所有想法都同样有用，所以我建议先从《极速软件质量》中的建议开始。那篇博文中的三个想法非常正确。首先是消除捷径，替换容易出错的模块，并采用某种代码审查流程。欢迎使用我的代码审查清单作为起点。

然后我会继续学习《快速开发》。这本书主要讲解如何掌控你的项目，并更快地交付可用的软件。书中提到的36个典型错误非常重要。接下来学习《快速开发》，然后再探讨本书剩余部分的主题。

《软件质量经济学》并非一本真正的指南，但作为参考书会很有用。它将帮助您确定特定项目的最佳质量目标。它还提供了一系列选项，帮助您选择正确的实践组合来实现目标。

如果没有人对提高质量感兴趣怎么办？

可悲的是，你们中的许多人都会遭遇这种情况。质量昂贵的迷思很难被打破。说服人们改变工作方式更是难上加难。除非你是团队中的佼佼者，否则你可能缺乏引领这种变革所需的影响力。

因此您有三个选择：

1. 忘记在项目层面提高质量并遵守团队的规范。
2. 继续倡导质量改进，并希望人们最终会同意你的观点。
3. 寻找一个已经关注质量的新工作场所。

我无法替你做决定，但我只想说，开发人员的职位空缺比合格的开发人员数量要多得多。许多雇主确实关心质量，并积极招聘各种经验水平的人才来帮助他们提高质量。

总结

你们中的许多人和我一样，对普通软件项目的质量感到担忧和苦恼。我们知道如何做得更好，但我们只需要让更多的软件开发团队也参与进来。我认为第一步就是向人们展示这张图表及其背后的证据。

我知道这个问题不会一夜之间消失。但如果您和我有同样的感受，请尽您所能传播信息，分享这篇文章，提升您自己项目的成果，并帮助提升我们行业的总体成果。

同意还是不同意？有什么故事想分享吗？请在评论区留言。

喜欢这篇文章吗？请在下方点赞。