软件开发这个行业向来以项目延迟交付和和预算超支而闻名。
作者 | Blaine Osepchuknin
译者 | 苏本如，责编 | 刘静
出品 | CSDN（ID：CSDNnews）
软件开发这个行业向来以项目延迟交付和和预算超支而闻名。很多项目甚至被完全取消，还有很多其它项目的交付物从未达到或接近我们向客户承诺的价值。然而，也有一部分软件开发组织，他们能够始终如一地交付优秀的结果。从上世纪70年代开始这些软件开发组织就知道如何做到这一点。在这篇文章里我会和你们分享他们成功的秘密。让我们先从了解史蒂夫·麦康奈尔（Steve McConnell）的这张图表开始。它描述了缺陷率（defect rate）和开发时间之间的关系。
这张图表显示，如果大多数团队将更多的精力放在缺陷预防、早期缺陷移除和其它质量问题上，那么他们就可以更快地交付他们的软件项目。
史蒂夫·麦康奈尔在1996年发表的一篇名为最快开发速度下的软件质量的博客文章中公布了这张图表。这张图表（和这篇博客文章）总结了他的优秀著作《快速开发》一书中的一些数据。那本书的部分内容是基于卡珀斯·琼斯（Capers Jones）在上世纪90年代早期的研究结果（我在这里提到这些日期是因为我想让你们知道我们知道这一点已经有多久了）：在软件开发中，更高的质量（以更低的缺陷率的形式）和更短的开发时间是可以齐头并进的。卡珀斯·琼斯一直在做他的研究，并且在2011年，他和奥利维尔•邦斯格诺（Olivier Bonsignour）合作出版了另一本名为《软件质量经济学》的书。书中分析了从1973年至2010年间660多个软件开发组织的13000多个软件项目，并且收集了更多的证据证明了下面的观点：…高质量水平总是与较短的开发周期和较低的开发成本密切相关。
存在的问题
大多数项目的运行都好像证明这个图表不正确。几乎每一天，我都会听到某个项目或某个人的错误判断，然后不出所料地被这个铁律击倒。因为这些愚蠢的行为，每年都有几十亿美元的损失。这种情况自从我们开始编写计算机程序以来就一直这样。每个开发人员都亲身经历过，并且看不到尽头。比如，因为自身的压力（或屈服于外部压力），想通过偷工减料来加快项目进度，结果几乎可以肯定会增加缺陷率并减缓项目进度。尽管如此，这样的事情总是层出不穷！但问题远不止于此。管理者应该对最严重的项目灾难负责。然而我们有人在管理这些项目时，他们虽然用心良苦，但却对自己在做什么一无所知。他们的许多项目从一开始就走向了灾难（详见下文的“经典”软件错误部分）。当他们意识到他们的项目陷入困境时，通常开发人员得出相同的结论已经几个月了，这时候往往为时已晚，来不及采取任何补救措施了。对于小项目来说相对有效的开发实践，往往无法扩展到大型的实际项目。小项目是大多数学生唯一从事过的项目。所以他们毕业时后给人一个错误的印象是他们知道如何开发软件。然而，当我们试图雇用他们来建造摩天大楼的时候，他们却一直在建造用来养花的花园棚屋。但是摩天大楼和一个大的花园棚屋没有可比性，它们是完全不同的东西。
而且，由于很少有组织能够很好地进行软件开发，许多团队就用解决花园棚屋问题的方法来解决摩天大楼的问题。所以这些可怜的开发人员就认为混乱、困惑、错误、冲突的需求、无休止的测试周期、错过的最后期限、压力、成堆的返工和死亡行军类的项目都是软件开发的正常部分。要在实际项目中实现低缺陷率，你需要的不仅仅是原始的技术技能。而是要有一整套的组织、管理和技术层面的战略和策略来实现这一目标。几乎可以肯定，你将需要为组织中的几乎所有人提供额外的培训，而且还需要你接受不同的开发实践。为了实现95%的预发布缺陷移除率的目标，我们需要需要什么？对于大多数组织来说，要达到95%的预发布缺陷移除率需要相当大的调整。但好消息是，即使是在预发布缺陷移除率上的一点点改进，也会对项目的经济性产生积极影响。接受这样一个事实：构建一个高质量的软件要比一个低质量的软件更快、更便宜接受这样一个事实：构建一个高质量的软件要比一个低质量的软件更快、更便宜如果你需要比你所知的更多的证据来证明这一点，请阅读《软件质量经济学》这本书，它会帮助说服你自己和你的队友真正地相信这张图表是正确的。该书的作者对此深信不疑问，他在书中这样写道：2011年最佳可用质量结果是非常好的，但是他们并没有被很好的理解，也没有被广泛的采用，原因之一是错误地认为高质量等同于成本高昂。高质量的软件并不昂贵。从最初的开发成本到总体拥有成本，高质量软件与低质量软件相比，它的构建和维护速度更快、成本更低。如果在每一个大型软件项目中使用最先进的缺陷预防、测试前缺陷移除和正式测试的组合，那么交付缺陷将比2011年的平均值减少60%。与高质量项目相比，低质量项目花在测试、调试、修复和返工上的时间要多得多。事实上，低质量的项目包含太多的缺陷，以至于测试往往比代码编写需要更长的时间。而且低质量的项目常常在缺陷没有找到之前就停止了测试。。在采用瀑布式开发的项目中，项目团队要么不管那些存在的缺陷直接将项目发布，要么取消项目，因为不这样做的话，测试和修复将永远不会结束。在一个敏捷项目中，一开始，增加的工作量很快就可以完成，但是随着在代码中发现越来越多的问题，随之带来的额外工作量就会暴涨，完成进度就会变得越来越缓慢。最终，低质量的敏捷项目只能面临和瀑布式项目相同的命运：带着缺陷发布或取消项目。高质量项目更多地投入在缺陷预防和预测试缺陷移除上，这样当他们进行测试时，需要发现和修复的缺陷就会更少了。与低质量项目相比，高质量项目发布得更快，成本更低，因为它们的测试周期更短，而且返工更少。同时高质量项目也有更少的发布后问题需要解决。因此，当他们确实需要进行更改时，高质量项目中的代码更容易修改，修改的成本也更便宜。让我们看看《软件质量经济学》一书中的一些关键论点：软件项目的总体质量水平在1973年至2010年间没有太大变化。IDE、新的开发语言、解释性语言、自动化测试工具、静态分析工具、更好的库、框架、持续集成、数千本书、Agile、Scrum、XP、OOP、TDD和整个他妈的Web都没有改变！那太令人沮丧了。（我知道有人会争辩说这一点不可能是真的。那么请随意查阅《软件质量经济学》的第538页和第539页）。在低质量软件项目中，接近50%的精力用于发现和修复缺陷，以及返工。缺陷率上升速度高于项目规模的增大。这意味着你为了确保95%的预发布缺陷移除率，在一个5千行代码的项目上需要做的事情，和在一个500千行代码的项目上需要做的事情完成不同。大型项目不仅需要更多的QA活动，而且还需要不同的QA活动。记住，构建一个摩天大楼和构建一个大的花园棚屋是完全不同的。软件行业自开始以来，测试一直是消除缺陷的主要方法，对于许多项目来说，测试是唯一可用的方法。这很可惜，因为测试并没有那么有效。即使你将6到8种测试方法结合起来，你也不能期望在一个大型系统中消除超过80%的缺陷。缺陷预防方法包括重用、正式检查、原型制作、PSP/TSP、静态分析、根原因分析、TDD和许多其它方法。影响缺陷预防的主要因素是需求变化过大、进度压力过大、缺乏缺陷或质量衡量措施。最有效的测试前缺陷移除方法是正式检查和静态分析。但作者也讨论了23种其他的预测试缺陷移除方法，它们的预期结果范围，以及何时可能需要使用它们。Better Form的预测试缺陷移除的投资回报率：每投入1美元，就会有10美元的收益。这本书讨论了40种不同的测试方式，它们的有效性范围，以及何时可能需要使用它们。我认为这本书的真正价值在于它提供的那些证据，可以帮助你反驳那些对你的项目成本和进度有非常大的负面影响的想法和做法。比如说，在你读完这本书之后，你就不会再说你没有时间来做代码审查。在《快速开发》一书的第3章，史蒂夫·麦康奈尔列出了36个“经典”软件错误。即使只是其中一个错误，也会让你的项目进展缓慢、开发成本快速上升。如果你想提高效率，你就需要避免所有这些错误。地狱式编程（自由散漫的，“代码写到哪算哪”式的编程模式），开发人员镀金（开发人员为学习新技术给项目加上用户不需要的功能）银弹综合征（把解决项目问题的希望过多地寄托在所谓的新技术中）《快速开发》这本书的出版已经超过25年了。然而，其中的35个经典错误现在仍然非常常见，而第36号错误 - 缺乏自动化源代码控制 - 已经在很大程度上被Subversion and GIT解决了。这一建议在前面提到的两本书中都没有提到，但我认为这是2019年的一个重要观点。每年通过安全更新解决的微软产品的漏洞中，大约70%都是内存安全问题。很明显，在这一点上，人类根本无法用像C语言和C++语言这样的非内存安全的语言编写大型系统，而不会犯令人吃惊数量的错误，或花费令人难堪的大量的金钱去发现和修复这些错误。如果微软公司都不能将这些错误从他们的软件当中移除，那么相信你可以做得更好是没有道理的。所以，如果你开始一个新的项目，那就选择一种内存安全的语言。即使是最苛刻的领域也有内存安全的语言，所以不要因为你对性能影响或兼容性问题的担心，而阻止你去看看它们是否可用。好了，现在你应该现在相信那张图表是正确的，并且你还确信你的组织处在最佳状态的左边。那么现在我们该做什么呢？当然是努力让你的组织沿着曲线走向图表上的最佳点。你的第一步是接受这样的事实：低质量是你的项目的一个问题。因为大多数项目都有质量问题，所以你不难找到证据来支持你的观点。《软件质量经济学》的第2章将帮助你建立一个缺陷跟踪系统来跟踪正确的事情，并避免常见的度量陷阱。拥有低质量项目成本的硬性数据将有助于你达成这一点。你的下一步是说服你自己和你的团队不要走捷径，因为它们往往总是适得其反。如果必须的话，把这张图表打印出来挂在墙上。接下来，我建议你在整个团队中实施一个小的改变，尝试一段时间，评估你的结果，保留或放弃你的改变，然后选择其它改变来改进和重复这个尝试。并非所有的想法都有同样的帮助，所以让我们从最快开发速度下的软件质量一文中的建议开始。这篇博文中的三个观点是很有说服力的。包括消除设计捷径，替换容易出错的模块，和采用某种代码检查机制。欢迎你们使用我的代码检查清单作为开始。接下来，让我们继续看看《快速开发》这本书。该书主要是关于项目控制和如何快速软件交付的。书中提到要避免的36个经典错误非常重要。然后，我们讨论了这本书其余部分的主题。《软件质量经济学》并不是一本真正的入门书，但它可以作为一个参考而派上用场。它将帮助你确定特定项目的最佳质量目标。它还为你提供了一个选项菜单，帮助你选择正确的实践组合来实现它。
如果没人对提高质量感兴趣怎么办？
可悲的是，这会发生在你们很多人身上。高质量等同于成本高昂的神话难以撼动。而说服人们改变工作方式的难度更大。除非你在你的团队中有很高的威信，否则你可能没有领导这种变革所需要的影响力。你只能自己做这个决定。但我想说，开发人员的职位很多，而合格的开发人员远远不足。而且现在许多雇主确实关心项目质量，并且积极招聘拥有各种级别经验的开发人员，帮助其他人提高质量。你们中的许多人和我一样对软件项目的平均质量之低，感到震惊和苦恼。我们知道如何做得更好，但是我们需要让更多的软件开发团队动作起来。我相信第一步是向人们展示这张图表及其背后的事实。我知道软件项目质量问题的解决不会一蹴而就。但如果你也感同身受，请尽你所能来大力倡导，分享这个帖子，改进你自己的项目结果，帮助提高整个软件行业的整体项目水平。你同意我的观点吗？你有故事要分享吗？请把它写在评论里。原文链接: https://dev.to/bosepchuk/the-one-chart-every-developer-must-understand-2db9【END】
热 文 推 荐
点击阅读原文，即刻阅读《程序员大本营》最新期刊。