软件开发 成功的秘密让我们先从了解史蒂夫·康奈尔麦

菏泽炫佑科技

软件开发 成功的秘密让我们先从了解史蒂夫·康奈尔麦

出品| CSDN（ID：）

以下为译文：

软件开发行业因项目延误和预算超支而臭名昭著。 许多项目甚至被完全取消，许多其他项目从未交付达到或接近我们向客户承诺的价值的可交付成果。 然而，有一部分软件开发组织能够始终如一地交付出色的成果。 这些软件开发组织自 20 世纪 70 年代以来就知道如何做到这一点。 在这篇文章中，我将与您分享他们成功的秘诀。

成功的秘诀

让我们首先看一下 Steve 的这张图表。 它描述了缺陷率（率）和开发时间之间的关系。

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

但这个图表正确吗？

Steve 在 1996 年题为“*快开发速度下的软件质量”的博客文章中发布了此图表。 这张图表（以及这篇博文）总结了他的优秀著作《快速发展》中的一些数据。 该书的部分内容基于 Jones 在 20 世纪 90 年代初的研究（我在这里提到日期是因为我想让你知道我们知道这一点有多久了）：

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

-Jones 一直在进行研究，2011 年他和 ( ) 出版了另一本书，名为《软件质量经济学》。 本书分析了1973年至2010年间660多个软件开发组织的13000多个软件项目，并收集了更多证据来证明以下观点：

…高质量水平始终与更短的开发周期和更低的开发成本密切相关。

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

问题

那么软件开发出了什么问题呢？

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

问题一：我们忽视研究

大多数项目的运行都好像在证明这个图是错误的。 几乎每天，我都会听到某个项目或某人的误判，毫不奇怪地，我被这条铁律击倒了。 由于这些愚蠢行为，每年损失数十亿美元。 自从我们开始编写计算机程序以来，情况就一直如此。 每个开发人员都亲身经历过这种情况，而且看不到尽头。

例如，由于内部压力（或屈服于外部压力）而试图通过偷工减料来加快项目速度，几乎肯定会增加缺陷率并减慢项目速度。 尽管如此，类似的事情还是不断出现！

但问题远不止于此。 管理者要对*严重的项目灾难负责。 然而，我们管理这些项目的人虽然是出于好意，但却不知道自己在做什么。 他们的许多项目从一开始就是灾难（请参阅下面的“经典”软件错误部分）。 当他们意识到他们的项目遇到麻烦时，通常开发人员几个月来都得出相同的结论，到那时采取任何补救措施往往为时已晚。

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

对于小型项目相对有效的开发实践通常无法扩展到大型实际项目。 小项目是大多数学生参与过的唯一项目。 因此，他们毕业时会产生一种错误的印象，认为他们知道如何开发软件。 然而，当我们试图雇用他们建造摩天大楼时，他们却一直在建造花园棚来种植花卉。 但摩天大楼和大花园棚之间没有可比性，它们是完全不同的东西。

而且，由于很少有组织能够做好软件开发，因此许多团队解决摩天大楼问题的方式与解决花园棚问题的方式相同。 因此，这些可怜的开发人员认为混乱、混乱、错误、相互冲突的需求、无休止的测试周期、错过*后期限、压力、大量返工和死亡行军类型的项目都是软件开发的正常部分。

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

为了在实际项目中实现低缺陷率，您需要的不仅仅是原始的技术技能。 相反，必须在组织、管理和技术层面有一套战略和战术来实现这一目标。 您几乎肯定需要为组织中的几乎每个人提供额外的培训，并且还要求您接受不同的开发实践。

我们需要什么才能实现 95% 的发布前缺陷消除率的目标？

对于大多数组织来说，实现 95% 的发布前缺陷消除率需要进行大量调整。 但好消息是，即使预发布缺陷去除率的微小改进也可以对项目的经济性产生积极影响。

改进建议

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

接受这样一个事实：构建高质量软件比低质量软件更快、更便宜

谨防史蒂夫·麦康奈尔的“经典”软件错误

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

开始改进您的开发实践

下面我们就以上几点进行讨论。

接受这样一个事实：构建高质量软件比低质量软件更快、更便宜

如果您需要更多的证据来证明这一点，请阅读《软件质量经济学》一书，它将帮助您和您的团队成员相信该图表是正确的。 本书作者对此毫不怀疑。 他在书中写道：

2011年的*佳可用质量结果非常出色，但它们并没有得到很好的理解，也没有被广泛采用，原因之一是人们错误地认为高质量等于高成本。 高质量的软件不一定很昂贵。 从初始开发成本到总拥有成本，高质量软件的构建和维护速度比低质量软件更快、更便宜。

此外，他还在书中指出：

如果在每个大型软件项目中都采用*先进的缺陷预防、预测试缺陷消除和正式测试的组合，那么交付缺陷将比 2011 年的平均水平降低 60%。

为什么会这样呢？

低质量项目比高质量项目花费更多的时间来测试、调试、修复和返工。 事实上，低质量的项目包含如此多的缺陷，以至于测试通常比编码花费更长的时间。 低质量的项目通常会在发现缺陷之前停止测试。 。

在瀑布式开发项目中，项目团队要么不管缺陷而发布项目，要么取消项目，因为否则测试和修复将永远不会结束。 在敏捷项目中，增加的工作量一开始可以很快完成，但随着代码中发现越来越多的问题，额外的工作量就会暴涨，完成进度也会发生变化。 它变得越来越慢。 *终，低质量的敏捷项目面临与瀑布项目相同的命运：发布时存在缺陷或被取消。

高质量的项目会在缺陷预防和测试前缺陷消除方面投入更多，以便在测试时发现和修复的缺陷更少。 高质量项目比低质量项目发布得更快、成本更低，因为它们的测试周期更短，需要的返工更少。 高质量的项目需要解决的启动后问题也较少。 因此，当他们确实需要进行更改时，高质量项目中的代码修改起来会更容易且成本更低。

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

从1973年到2010年，软件项目的整体质量水平没有太大变化。IDE、新的开发语言、解释性语言、自动化测试工具、静态分析工具、更好的库、框架、持续集成、数千本书、Agile、Scrum、XP 、OOP、TDD 和整个该死的网络。 不用找了！ 太令人沮丧了。 （我知道有些人会认为这不可能是真的。那么请随意查看《软件质量经济学》的第 538 和 539 页）。

在低质量的软件项目中，近50%的精力花费在查找和修复缺陷以及返工上。

缺陷率的上升速度快于项目规模的增长速度。 这意味着，在具有 5,000 行代码的项目上确保 95% 的预发布缺陷消除率所需执行的操作与在具有 500,000 行代码的项目上需要执行的操作不同。 较大的项目不仅需要更多的 QA 活动，而且需要不同的 QA 活动。 请记住，建造摩天大楼与建造大型花园棚有很大不同。

自软件行业诞生以来，测试一直是消除缺陷的主要方法，并且对于许多项目来说，测试是唯一可用的方法。 这很遗憾，因为测试并不那么有效。 即使结合 6 到 8 种测试方法，也无法指望消除大型系统中超过 80% 的缺陷。

缺陷预防方法包括重用、形式检查、原型设计、PSP/TSP、静态分析、根本原因分析、TDD 等。 影响缺陷预防的主要因素是需求变化过大、进度压力过大以及缺乏缺陷或质量措施。

*有效的测试前缺陷消除方法是形式检查和静态分析。 但作者还讨论了其他 23 种预测试缺陷消除方法、它们的预期结果范围以及何时可能需要使用它们。

Form 测试前缺陷消除的投资回报率：每投资 1 美元软件开发，收益 10 美元。

本书讨论了 40 种不同的测试风格、它们的有效性范围以及何时需要使用它们。

我认为这本书的真正价值在于它提供的证据可以帮助您反驳对您的项目成本和进度产生非常负面影响的想法和实践。 例如，当你读完这本书后，你将不再说你没有时间做代码审查。

谨防史蒂夫·麦康奈尔的“经典”软件错误

在《快速开发》一书的第三章中，Steve 列出了 36 个“经典”软件错误。

即使只有其中一个错误也会减慢您的项目速度并迅速增加开发成本。 如果你想提高效率，你需要避免所有这些错误。

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

动力不足，热情受挫

人员无能

失去对问题员工的控制

个人英雄主义

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

办公环境拥挤嘈杂

开发商与客户之间产生摩擦

不切实际的期望

项目缺乏有效的高层支持

利益相关者没有充分参与

缺乏用户干预

玩弄政治

妄想

过于乐观的时间表

风险管理不足

外包承包商违约

项目规划不充分

迫于压力放弃项目规划

项目前期浪费时间

上游任务别名

软件设计不足

变形品质保证

管理控制不到位

过早或过于频繁地执行项目收尾任务

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

努力追赶落后的人

地狱式编程（自由、宽松软件开发 成功的秘密让我们先从了解史蒂夫·康奈尔麦，“代码写到哪里就写到哪里”式编程模型），

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

功能蠕变（项目期间需求频繁变化）

开发者镀金（开发者为项目添加用户不需要的功能，以便学习新技术）

在批准项目延期的同时，对项目增加了新的要求

以研究为导向，把研究工作当成一个项目

银弹综合症（对所谓的新技术解决项目问题寄予太多希望）

高估新技术或方法的好处

项目期间更改开发工具

缺乏自动化源代码控制

《快速发展》一书已经出版25年多了。 然而，其中 35 个经典错误在今天仍然很常见，而第 36 个错误（缺乏自动化源代码控制）已被 GIT 很大程度上解决。

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

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

很明显，在这一点上，人类根本不可能用 C 和 C++ 等非内存安全语言编写大型系统，而不犯大量错误或花费令人尴尬的金钱。 查找并修复这些错误。

如果 无法消除其软件中的这些错误，那么相信您可以做得更好是没有道理的。 因此，如果您开始一个新项目，请选择内存安全的语言。 即使是*苛刻的领域也有内存安全的语言，因此不要让对性能影响或兼容性问题的担忧阻止您查看它们是否可用。

开始改进您的开发实践

好吧，现在您应该确信该图表是正确的，并且您还确信您的组织位于*佳组织的左侧。 所以我们现在怎么办？ 当然，要努力让您的组织沿着曲线走向图表上的*佳点。

您的**步是接受低质量是您的项目存在问题的事实。 由于大多数项目都存在质量问题，因此您应该不难找到证据来支持您的观点。 《软件质量经济学》的第 2 章将帮助您构建一个缺陷跟踪系统，该系统可以跟踪正确的事物并避免常见的测量陷阱。 拥有有关低质量项目成本的硬数据将帮助您实现这一目标。

你的下一步是说服你自己和你的团队不要走捷径，因为它们往往会适得其反。 如果需要，请打印此图表并将其挂在墙上。

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

并非所有想法都同样有帮助，因此让我们从*大开发速度下的软件质量一文中的建议开始。 这篇博文中提出的三点引人注目。 其中包括消除设计捷径、替换容易出错的模块以及采用某种代码检查机制。 欢迎您使用我的代码清单作为开始。

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

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

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

可悲的是，这会发生在你们很多人身上。 高品质等于高成本的神话很难动摇。 说服人们改变工作方式更加困难。 除非你在团队中拥有很高的权威，否则你可能没有影响力来领导这种变革。

所以你有三个选择：

随波逐流，忘记提高项目质量。

不断倡导提高项目质量，希望大家*终都能认同你的观点。

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

你只能自己做出这个决定。 但我想说的是，开发人员的职位很多，但合格的开发人员却不够。 而且现在很多雇主确实关心项目质量，并积极招募具有不同经验水平的开发人员来帮助其他人提高质量。

结论

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

我知道软件项目的质量问题不是一朝一夕就能解决的。 但如果你也有同样的感觉，请尽你所能去倡导、分享这篇文章，提高自己的项目成果，帮助提高整个软件行业的整体项目水平。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等