敏捷开发如何保证质量:质量内建

2022-04-20 13:49:39
亮哥圆桌派
转贴:
微信公众号
61

我们都知道高质量,几乎是所有研发团队和研发人员不懈的追求。但是,如何在敏捷环境中保证质量呢,今天来跟大家来分享第一部分:


一、什么是质量内建
1、关于质量
在软件开发中,质量是一个永恒的话题。如下图所示,这是传统的项目管理三角形:我们可以看到,三角形的成本、时间和范围三个方面都围绕着质量,即质量被视为选择的中心和不可妥协的属性。
在敏捷项目管理中,这个三角关系已经演变,其结果如下图所示。

我们可以看到,演化的敏捷三角不仅改变了范围,更加聚焦于客户价值,还加强了质量的权重,以改善最终用户体验。因此,我们需求强调质量。


那么,我们如何才能更好地实现我们所关注的质量呢?质量保证已经成为一个更加突出的问题,尤其是为了适应需求的变化,更灵活地应对不确定的市场。我们都知道,对于敏捷开发来说,“快”并不意味着“粗糙”,MVP是“简单”,但它并不意味着“简陋”。对质量的承诺从未受到妥协或打折。我们相信质量不是后来才加上去的,质量不是经过测试出来的,质量是内建的!

2、什么是质量内建
开发过程中的质量内建,要求软件生命周期中涉及的所有角色对软件的实时质量负责。在继续下一步之前,确保软件具有基本的质量保证。其主要目的是减少因质量问题而造成的返工,避免浪费大量劳动力成本。

3、精益敏捷中的质量内建
质量内建是精益的基本原则之一。它有助于我们减少浪费,避免与需求召回、返工和缺陷修复相关的延迟成本。如下图所示,我们知道大约85%的错误发生在编码阶段,这时它们的成本是最低的。也就是说,如果我们能在编码阶段避免这些错误,我们产品中85%的错误将被减少,从而避免后续解决故障而引起成本的指数级上升。 也就是说,“发现问题越早,维护成本就越低”。
质量内建也是敏捷开发的原则之一。敏捷宣言的12项原则之一是明确地把重点放在质量上:“坚持不懈的追求技术的卓越和良好的设计,增强了敏捷能力”。在Scrum 指南中对“Scrum 事件”的“Sprint”的描述中,明确指出了“Sprint期间不可降低质量的目标”。

4、SAFe里的内建质量
内建质量是SAFe的四个核心价值观之一。
内建质量保证了了机制当中的每一个元素和每一个增量都符合质量标准,并且质量不会在以后增加,内建质量是精益开发过程的前提。在缺乏质量的情况下,组织的运行可能会伴随着大量未经测试和验证的工作,这可能导致过度返工和交付延迟。毫无疑问,内建质量对大型系统至关重要(事实上,内建质量对任何系统都至关重要),质量一定是强制性的。

二、没有质量内建的问题
如果没有质量内建,那么我们遇到的将会是:
  • 不断增长的技术债,直到无力偿还;
  • 开发新feature与修改旧bug的摩擦;
  • 无法预期的交付,对于客户响应变慢;
  • 团队对于质量丧失了信心。
1、技术债
技术债务是我们在代码中留下的恶臭。例如,架构设计不当、一个类的代码行太多、编码格式不符合编码规范、代码重复、硬代码、替代方案、缺陷、测试覆盖率不足、手动测试太多、集成和版本管理不当、缺乏相应的经验等。值得注意的是,技术债并不总是不好的,或者说我们对技术债不是零容忍。例如,在我们产品设计的早期,我们可能仍处于业务验证阶段,因此我们需要快速发布MVP并得到客户的验证。在这一点上,为了快速试错,我们不可避免地会引入技术债。

但是,需要注意的是,一旦收到反馈并决定继续,就必须在下一次迭代中及时偿还技术债,以避免技术债的累积和扩散。技术债是有利息的,当程序员编写代码时,如果发现原来的代码非常糟糕,他们心里会一边骂着,一边不由自主的去复制和粘贴,并写出同样风格的错误代码。所以,当我们检查代码并重新检查缺陷时,我们听到的大多数借口是:“原来就是这样的”,垃圾代码增加了技术债务。我们应该从被动变为主动,只有内建质量才能进入良性循环。


技术债是不可避免的。现在不去偿还只会让我们今后付出更大的代价。为什么我们必须首先修复软件缺陷?就是因为我们不能去重复垃圾代码以避免技术债。


2、新特性和旧缺陷的摩擦
在敏捷开发中,我们致力于在每个迭代或者看板中完成一些用户故事,如下图所示,我们希望价值流动起来。
试着想一下,如果我们在测试过程中做了C或D,A和B的用户故事,并且有很多错误。我们将陷入不断开发新功能和修改旧缺陷之间的摩擦,bug越多,摩擦就越大。如果我们不能及时解决A或B中的错误,价值就不会流动,这可能会阻碍后续的一系列行为,比如测试和发布等。但是,如果我们及时解决发现的缺陷,就意味着新特性的开发过程将不得不频繁被中断,从而扰乱我们的开发速度,并导致效率低下。当你做C和D的时候,你不会觉得很爽,你只会感觉到死亡行军的痛苦,更糟糕的是,虽然我们已经在开发G和H,但是仍然存在A和B(发布阶段)以及C和D(接受阶段)的bug。同时,我们可能需要解决G和H的问题。我们可以想象这样是有多痛苦。

所以,只有质量内建,减少每部分的缺陷,价值流动才会变得更加顺畅。      价值就像水一样向前流动,我们不能让水逆流(频繁回头修复之前的问题),也要尽最大可能不要让流动停下来。

3、无法预期的交付
迭代开发能使我们能够更早地识别和解决问题,以便在迭代结束时尽快实现客户价值的增长。在进入迭代之前,我们将使用各种方法来估计要开发的新特性的工作负载,以便选择合适的用户故事作为迭代承诺。这样我们就有了预期,即使我们真的不能在迭代结束时完成所有的承诺,我们也可以非常清楚地预测剩余的用户故事将延迟多长时间。但质量差会损害我们的期望和估计,你无法预测在接下来的两周里你能填补多少坑。坐在电脑前的你就像在雾中行走,你不知道尽头在哪里,也不知道你在哪里,你必须把头埋在坑里,等到天亮,才能看到路尽头的旗帜。

低质量的代码使得团队成员很难相互支持,特别是对于新人,他们甚至不得不开始重构。这就是为什么没有人愿意去动祖传代码,因为代码质量太差,无法理解和扩展,架构不清晰,逻辑混乱,这几乎摧毁了代码共有。一旦其他人涉及他们不熟悉的部分,就会遇到上面所示的各种大坑,自然就没有办法按照预期的时间完成承诺。

所以,软件开发过程往往是复杂多变的,批量修复不可避免地会带来新的缺陷。

4、团队对质量失去信心
Bug也是会累积的,你的Bug越多,就越难消除每个Bug。这在一定程度上是因为错误是相互作用的,失败可能是许多错误的共同结果,这使得查找每个错误变得困难, 这也是心理上的效应,当出现大量Bug时,人们自然会缺乏发现和解决错误的热情——这在《Pragmatic Programmer》一书中被称为“破窗效应”。

破窗效应(Broken windows theory)是由詹姆士·威尔逊(James Q. Wilson)及乔治·凯林(George L. Kelling)提出的犯罪学理论。根据这一理论,如果允许环境中的不良现象存在,就会诱使人们去模仿,甚至还会变本加厉。比如一栋楼有多扇窗户,少数几块玻璃破了没有去修理,那么就会有更多的窗户可能会被破坏者故意毁坏。

破窗理论很好地解释了为什么会违反代码整洁之道,而且忽视质量问题背后的原因:这是因为它们本来就是垃圾。如果有人在没有惩罚或胁迫的情况下做了坏事,那么我也会做同样的事情,以同样的方式行事,这是很正常的,大家都一样,但是所谓的错误或不相干的缺陷被掩盖和积累,当雪崩发生时,没有一片雪花是无辜的,最后,整个团队都在为质量付出代价。

那么,我们如何避免破窗效应?让我们的质量保持健康呢?

答案就是:每次提交代码时,我们都应该让代码比以上一个版本更干净,哪怕是减少重复的代码,或者是优化一个格式问题。只有这样做,我们才能够避免代码中的坏气味,保持代码和架构的整洁。

联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105