软件质量成本神话
软件质量:不仅是工作软件,还包括精心制作的软件
![软件质量成本神话](http://3ms.huawei.com/km/static/blog/images/gif/grey.gif)
短篇小说
就像其他神话一样,背后也有一个可怕的故事。 在这种情况下的故事是某个公司启动的该软件项目。 经过几个月的思考和计划,该项目的负责人终于获得了预算。 他们开始雇用人们,从这个使他们成为百万富翁的商业想法开始。
刚开始的时候只有几个人,就像每个开始一样,这是一个美好的阶段。 每个人都很高兴,而且非常上进。 团队的所有成员都在同一页面上,开发人员开始提供第一个功能,管理人员可以开始向所有人展示他们的小宝宝的第一步。
但是随着时间的流逝,项目中增加了更多的人,所有团队成员之间的交流有所减少。 老人们还是一样,但是新人们……你知道,那是不一样的感觉。 他们不完全了解产品,不了解代码,也不了解我们过去做出的某些决定。 但是不必担心,让我们给他们一些时间,他们很快就会结盟。
不久之后,团队的生产力开始下降,现在公司中的每个人都注意到了这一点。 也许是由于新员工的缘故,也可能是由于其他原因,但该业务无法达到本季度设定的目标。 开发团队没有发现任何重大问题,因此让我们给他们更多的时间,在下一个季度中,让我们在其中添加更多的资源。
下个季度的情况甚至更糟,我们将开发团队的资源增加了一倍,并且生产力降至最低。 开发团队目前几乎没有交付任何东西,他们交付的一些东西充满了错误,需要花费大量的额外时间来修复。 他们只是抱怨代码库,显然这是一场彻底的灾难。 人们不再高兴,他们对无聊的事情进行了无休止的讨论,有时甚至有激烈的争论。 但这还不是全部,最重要的是两个最有经验的开发人员(对产品了解更多的人)刚刚离开公司。 老实说,我认为其他人也在寻找公司以外的其他选择。
我们不知道发生了什么,我们没有做错任何事情。 我们一切都很好,我们都很高兴,但是突然之间一切都变得一团糟。 我们仍有业务要运行,但是软件不存在。 开发人员无法按时交付任何东西,而且每次发布任何东西到生产环境时,我们都会出汗,因为它有很多错误。 因此,我们的客户抱怨很多,其中许多已经在考虑其他选择。 我们完全失去了帮助我们成立这家公司的创新DNA,现在我们才刚刚开始。
如果您从事软件行业已有一段时间,那么很可能您已经看到或听到过类似的故事。 也许不是那么戏剧性的结局,但其余的听起来很熟悉。
案例公司或其他类似公司出了什么问题? 为什么有一天他们醒来,发现所有事情都是一团糟的可怕真相? 好吧,有很多因素。 开始是因为每个公司都不同,环境不同,而且所描述的问题在不同程度上受到影响……但是它们都有共同的原因:低质量的软件。
在此业务案例中,就像每个类似案例一样,开发团队专注于交付业务功能,增加业务价值,但他们完全忘记了所有技术实践。 他们逐渐增加了项目的技术负担,以便按时交付功能,就像流沙一样,开发的越多,它们的速度就越慢。 在这些情况下,向项目中添加更多的人就更糟了,因为有更多的人向堆中添加̶c̶r̶*̶p̶东西,从而使̶m̶u̶d̶雪球变得更快。
不要以为这只会在老式的瀑布项目中发生,在敏捷项目中也会发生,甚至更常见。 在瀑布式项目中,可能是错误的,但至少在项目开始时就已设计了一切。 在敏捷中,我们通常不会将大设计的前瞻性与根本不思考的混淆。 在上述情况下,也许他们正在使用诸如看板或Scrum之类的敏捷实施,也许他们甚至按照自己的意愿进行日常站立,冲刺计划,审查和回顾,但是技术准则却不存在。 敏捷不能解决问题,敏捷可以解决问题,因此您可以对它们做出反应。
劣质软件的一些症状包括:
· 没有测试或测试不足
· 没有可靠的测试
· 没有自动测试
· 没有文档(类图,体系结构图,顺序图等)
· 安装,编译或运行复杂的软件
· 需要花很多时间才能部署(全都是手动操作)
· 有错误或已知问题
· 代码难懂
· 维持或延长费用昂贵
· 软件脆弱,不稳定或不可用
· …
如果您在项目中发现任何这些症状,请开始担心,但不要惊慌。 尽快准备应变和恢复计划。 解决这些问题的时间越晚,成本就越高。 在软件项目中,业务的步伐由开发人员决定,而不是由业务决定,业务的发展速度只能与开发人员一样快。 软件质量很重要,这是项目中每个人都应该关心或启用的东西。
什么是软件质量?
嗯,就像其他任何产品一样,我们一方面具有功能质量(这是我们对有效产品的期望),另一方面具有结构质量(即产品的制造方式)。 与其他行业的区别在于,在软件中,您可以拥有第一个而没有第二个。
篮球球应该是球形的,具有一定的大小,橙色,并带有一些黑色条纹,但是如果将其弹跳15或20次后破裂,我们可以说质量很低。 软件也会发生同样的情况,我们可以拥有一个应用程序,该应用程序可以完成预期的工作,但在内部却一团糟。 只要我们永远不必更改它,就没有问题,但是在我们必须更改任何内容的那一刻,就会出现各种问题。 但是说实话,您知道有多少个项目开发人员从未接触过代码?
软件质量神话
质量总是被认为是昂贵的东西,我们经常说,不可能同时拥有速度和高质量。 但是在软件中并非如此,这是违反直觉的,因为唯一可以保证项目速度和灵活性的是软件的高质量。
当启动质量低下的项目时,我们可以立即交付业务价值。 最初,问题不多,因为我们只有很少的开发人员,并且代码仍然很小,功能也减少了。
但是过了一会儿,随着代码库的增长,尤其是当我们向项目中添加更多人员时,速度开始放慢。 该代码不容易理解,有不同的编码样式。 只有每段代码的作者才能对每个部分有效地工作,而其余部分则无法工作,因为他们不理解。 随着时间的流逝,团队变得越来越慢。
但是高质量的软件会发生什么? 最初,由于所有技术问题都已正确设置,因此交付的价值不高。 在这里,我们仅专注于技术方面,目前,业务价值是第二要务。 思考我们将如何构建软件以及如何交付软件。
设计的复杂性较高,但可以弥补代码的简单性。 它需要一段时间才能开始产生效果,但是正如您在图像中看到的那样,那时的速度比从未有过的速度快得多。 这条线的步伐将取决于我们的设计和架构的优良程度。 从图像中可以看出,在某个点上,有一个低质量交叉点和高质量交叉点。 不要以为这种情况是用几年或几个月的时间来衡量的,在大多数情况下,我们谈论的最可能是4到8周。
如果我们进一步延长时间线,我们会看到低质量的项目不仅没有改善,而且还在稳定减少。 另一方面,高质量的软件不仅能够保持交付价值的增长速度,而且甚至可以提高价值。 一个原因是因为如果我们有一个好的设计,我们可以在一段时间后开始重用代码段。 第二个是,我们可以在项目中增加更多的人,因为他们了解代码,因此他们的工作效率更高。 这意味着增加团队,按比例增加速度。 当质量低下时,新加入者不得不问几个月的问题,这不仅减慢了他们的速度,而且也减慢了其他帮助他们的人的速度。
良好的品质规范。
在编写代码时,有大量关于最佳实践的文献,但是如果您不知道从哪里开始,我建议您看一下极限编程(XP)的实践:
极限编程是肯特·贝克(Kent Beck)早在1996年就引入的一套行之有效的实践。它可能是结合一些敏捷过程(例如Scrum或看板)使用最多的框架。 它专注于提高软件产品的内部质量,并在短时间内不断为业务创造价值。 试试看。
总结起来,软件质量非常重要,可悲的是,它通常被忽略或直接遗忘。 与直觉相反,软件的高质量是拥有快速交付和灵活的软件产品的关键。 就像其他所有做法一样,好的做法也需要一定的学习时间。 就像学习如何骑自行车或汽车,甚至是乐器一样。 它需要一定的奉献精神和纪律才能胜任。 好的方面是,一旦获得,便永远拥有。 您可以将知识从一个项目带到另一个项目,就像更换自行车,汽车,吉他或钢琴一样。
(本文翻译自Josep Mir的文章《The Software Quality Cost Myth》,参考:https://medium.com/swlh/the-software-quality-cost-myth-6f4e182a98c)
本文来自博客园,作者:易先讯,转载请注明原文链接:https://www.cnblogs.com/gongxianjin/p/15625554.html