软件是怎样开发的-成功的秘密让我们先从了解史蒂夫·麦

出品 | CSDN（ID：CSDNnews）

以下为译文：

软件开发这个行业向来以项目延迟交付和和预算超支而闻名。很多项目甚至被完全取消，还有很多其它项目的交付物从未达到或接近我们向客户承诺的价值。然而，也有一部分软件开发组织，他们能够始终如一地交付优秀的结果。从上世纪70年代开始这些软件开发组织就知道如何做到这一点。在这篇文章里我会和你们分享他们成功的秘密。

成功的秘密

让我们先从了解史蒂夫·麦康奈尔（Steve McConnell）的这张图表开始。它描述了缺陷率（defect rate）和开发时间之间的关系。

这张图表显示，如果大多数团队将更多的精力放在缺陷预防、早期缺陷移除和其它质量问题上，那么他们就可以更快地交付他们的软件项目。

但是这张图表是正确的吗？

史蒂夫·麦康奈尔在1996年发表的一篇名为最快开发速度下的软件质量的博客文章中公布了这张图表。这张图表（和这篇博客文章）总结了他的优秀著作《快速开发》一书中的一些数据。那本书的部分内容是基于卡珀斯·琼斯（Capers Jones）在上世纪90年代早期的研究结果（我在这里提到这些日期是因为我想让你们知道我们知道这一点已经有多久了）：

在软件开发中，更高的质量（以更低的缺陷率的形式）和更短的开发时间是可以齐头并进的。

卡珀斯·琼斯一直在做他的研究，并且在2011年，他和奥利维尔•邦斯格诺（Olivier Bonsignour）合作出版了另一本名为《软件质量经济学》的书。书中分析了从1973年至2010年间660多个软件开发组织的13000多个软件项目，并且收集了更多的证据证明了下面的观点：

…高质量水平总是与较短的开发周期和较低的开发成本密切相关。

换句话说，史蒂夫·麦康奈尔的图表是正确的。

存在的问题

那么软件开发到底存在什么问题呢？

我认为我们存在如下以下三个问题：

问题1：我们忽略了研究

大多数项目的运行都好像证明这个图表不正确。几乎每一天，我都会听到某个项目或某个人的错误判断，然后不出所料地被这个铁律击倒。因为这些愚蠢的行为，每年都有几十亿美元的损失。这种情况自从我们开始编写计算机程序以来就一直这样。每个开发人员都亲身经历过，并且看不到尽头。

比如，因为自身的压力（或屈服于外部压力），想通过偷工减料来加快项目进度，结果几乎可以肯定会增加缺陷率并减缓项目进度。尽管如此，这样的事情总是层出不穷！

但问题远不止于此。管理者应该对最严重的项目灾难负责。然而我们有人在管理这些项目时，他们虽然用心良苦，但却对自己在做什么一无所知。他们的许多项目从一开始就走向了灾难（详见下文的“经典”软件错误部分）。当他们意识到他们的项目陷入困境时，通常开发人员得出相同的结论已经几个月了，这时候往往为时已晚，来不及采取任何补救措施了。

问题2：小项目的开发实践不适合大项目

对于小项目来说相对有效的开发实践，往往无法扩展到大型的实际项目。小项目是大多数学生唯一从事过的项目。所以他们毕业时后给人一个错误的印象是他们知道如何开发软件。然而，当我们试图雇用他们来建造摩天大楼的时候，他们却一直在建造用来养花的花园棚屋。但是摩天大楼和一个大的花园棚屋没有可比性，它们是完全不同的东西。

而且，由于很少有组织能够很好地进行软件开发，许多团队就用解决花园棚屋问题的方法来解决摩天大楼的问题。所以这些可怜的开发人员就认为混乱、困惑、错误、冲突的需求、无休止的测试周期、错过的最后期限、压力、成堆的返工和死亡行军类的项目都是软件开发的正常部分。

问题3：许多团队没有所需的技能

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

为了实现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个“经典”软件错误。

即使只是其中一个错误，也会让你的项目进展缓慢、开发成本快速上升。如果你想提高效率，你就需要避免所有这些错误。

这36个“经典”软件错误是：

激励不足，挫伤积极性

人员不能胜任

对问题员工失去控制

个人英雄主义

向已经落后的项目增加人员

办公环境拥挤嘈杂

开发人员与客户之间产生摩擦

不切实际的预期

缺乏高层对项目的有效支持

利益相关者没有全身心投入

缺乏用户介入

玩弄政治

一厢情愿

过于乐观的进度安排

风险管理不到足

外包承包商违约

项目规划不到位

因为压力而放弃项目规划

项目前期浪费时间

走样的上游任务

软件设计不足

走样的质量保证

管理控制不到位

过早或过于频繁地开展项目收尾工作

项目估算中遗漏必要的任务

试图赶上落后的进度

地狱式编程（自由散漫的，“代码写到哪算哪”式的编程模式），

需求镀金（加入用户不需要的需求）

功能蔓延（项目进行过程中频繁出现需求变更）

开发人员镀金（开发人员为学习新技术给项目加上用户不需要的功能）

批准项目延期的同时，向项目中加入新需求

以研究为导向的开发，把研究工作当作项目来做

银弹综合征（把解决项目问题的希望过多地寄托在所谓的新技术中）

高估新技术或新方法带来的收益

在项目期间更换开发工具

缺乏自动化源代码控制

《快速开发》这本书的出版已经超过25年了。然而，其中的35个经典错误现在仍然非常常见，而第36号错误 - 缺乏自动化源代码控制 - 已经在很大程度上被Subversion and GIT解决了。

尽可能使用内存安全语言

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

很明显，在这一点上，人类根本无法用像C语言和C++语言这样的非内存安全的语言编写大型系统，而不会犯令人吃惊数量的错误，或花费令人难堪的大量的金钱去发现和修复这些错误。

如果微软公司都不能将这些错误从他们的软件当中移除，那么相信你可以做得更好是没有道理的。所以，如果你开始一个新的项目，那就选择一种内存安全的语言。即使是最苛刻的领域也有内存安全的语言，所以不要因为你对性能影响或兼容性问题的担心，而阻止你去看看它们是否可用。

开始改进你的开发实践

好了，现在你应该现在相信那张图表是正确的，并且你还确信你的组织处在最佳状态的左边。那么现在我们该做什么呢？当然是努力让你的组织沿着曲线走向图表上的最佳点。

你的第一步是接受这样的事实：低质量是你的项目的一个问题。因为大多数项目都有质量问题，所以你不难找到证据来支持你的观点。《软件质量经济学》的第2章将帮助你建立一个缺陷跟踪系统来跟踪正确的事情，并避免常见的度量陷阱。拥有低质量项目成本的硬性数据将有助于你达成这一点。

你的下一步是说服你自己和你的团队不要走捷径，因为它们往往总是适得其反。如果必须的话，把这张图表打印出来挂在墙上。

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

并非所有的想法都有同样的帮助，所以让我们从最快开发速度下的软件质量一文中的建议开始。这篇博文中的三个观点是很有说服力的。包括消除设计捷径，替换容易出错的模块，和采用某种代码检查机制。欢迎你们使用我的代码检查清单作为开始。

接下来，让我们继续看看《快速开发》这本书。该书主要是关于项目控制和如何快速软件交付的。书中提到要避免的36个经典错误非常重要。然后，我们讨论了这本书其余部分的主题。

《软件质量经济学》并不是一本真正的入门书软件是怎样开发的，但它可以作为一个参考而派上用场。它将帮助你确定特定项目的最佳质量目标。它还为你提供了一个选项菜单，帮助你选择正确的实践组合来实现它。

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

可悲的是，这会发生在你们很多人身上。高质量等同于成本高昂的神话难以撼动。而说服人们改变工作方式的难度更大。除非你在你的团队中有很高的威信，否则你可能没有领导这种变革所需要的影响力。

所以你有三个选择：

在你的团队中随大流，忘掉提高项目质量这回事。

坚持提倡提高项目质量，希望大家最终同意你的观点。

换一个重视项目质量的新工作场所。

你只能自己做这个决定。但我想说，开发人员的职位很多，而合格的开发人员远远不足。而且现在许多雇主确实关心项目质量，并且积极招聘拥有各种级别经验的开发人员，帮助其他人提高质量。

结束语

你们中的许多人和我一样对软件项目的平均质量之低，感到震惊和苦恼。我们知道如何做得更好，但是我们需要让更多的软件开发团队动作起来。我相信第一步是向人们展示这张图表及其背后的事实。

我知道软件项目质量问题的解决不会一蹴而就。但如果你也感同身受，请尽你所能来大力倡导，分享这个帖子，改进你自己的项目结果，帮助提高整个软件行业的整体项目水平。