敏捷开发如何保证质量：质量内建
- 2022-04-20 13:49:39
- 亮哥圆桌派
- 转贴：
- 微信公众号
- 2689
我们都知道高质量，几乎是所有研发团队和研发人员不懈的追求。但是，如何在敏捷环境中保证质量呢，今天来跟大家来分享第一部分：
1、关于质量
在软件开发中，质量是一个永恒的话题。如下图所示，这是传统的项目管理三角形：我们可以看到，三角形的成本、时间和范围三个方面都围绕着质量，即质量被视为选择的中心和不可妥协的属性。
我们可以看到，演化的敏捷三角不仅改变了范围，更加聚焦于客户价值，还加强了质量的权重，以改善最终用户体验。因此，我们需求强调质量。
2、什么是质量内建
开发过程中的质量内建，要求软件生命周期中涉及的所有角色对软件的实时质量负责。在继续下一步之前，确保软件具有基本的质量保证。其主要目的是减少因质量问题而造成的返工，避免浪费大量劳动力成本。
3、精益敏捷中的质量内建
质量内建是精益的基本原则之一。它有助于我们减少浪费，避免与需求召回、返工和缺陷修复相关的延迟成本。如下图所示，我们知道大约85%的错误发生在编码阶段，这时它们的成本是最低的。也就是说，如果我们能在编码阶段避免这些错误，我们产品中85%的错误将被减少，从而避免后续解决故障而引起成本的指数级上升。 也就是说，“发现问题越早，维护成本就越低”。
4、SAFe里的内建质量
内建质量是SAFe的四个核心价值观之一。
二、没有质量内建的问题
如果没有质量内建，那么我们遇到的将会是：
- 不断增长的技术债，直到无力偿还；
- 开发新feature与修改旧bug的摩擦；
- 无法预期的交付，对于客户响应变慢；
- 团队对于质量丧失了信心。
技术债务是我们在代码中留下的恶臭。例如，架构设计不当、一个类的代码行太多、编码格式不符合编码规范、代码重复、硬代码、替代方案、缺陷、测试覆盖率不足、手动测试太多、集成和版本管理不当、缺乏相应的经验等。值得注意的是，技术债并不总是不好的，或者说我们对技术债不是零容忍。例如，在我们产品设计的早期，我们可能仍处于业务验证阶段，因此我们需要快速发布MVP并得到客户的验证。在这一点上，为了快速试错，我们不可避免地会引入技术债。
但是，需要注意的是，一旦收到反馈并决定继续，就必须在下一次迭代中及时偿还技术债，以避免技术债的累积和扩散。技术债是有利息的，当程序员编写代码时，如果发现原来的代码非常糟糕，他们心里会一边骂着，一边不由自主的去复制和粘贴，并写出同样风格的错误代码。所以，当我们检查代码并重新检查缺陷时，我们听到的大多数借口是：“原来就是这样的”，垃圾代码增加了技术债务。我们应该从被动变为主动，只有内建质量才能进入良性循环。
技术债是不可避免的。现在不去偿还只会让我们今后付出更大的代价。为什么我们必须首先修复软件缺陷？就是因为我们不能去重复垃圾代码以避免技术债。
2、新特性和旧缺陷的摩擦
在敏捷开发中，我们致力于在每个迭代或者看板中完成一些用户故事，如下图所示，我们希望价值流动起来。
所以，只有质量内建，减少每部分的缺陷，价值流动才会变得更加顺畅。 价值就像水一样向前流动，我们不能让水逆流（频繁回头修复之前的问题），也要尽最大可能不要让流动停下来。
3、无法预期的交付
迭代开发能使我们能够更早地识别和解决问题，以便在迭代结束时尽快实现客户价值的增长。在进入迭代之前，我们将使用各种方法来估计要开发的新特性的工作负载，以便选择合适的用户故事作为迭代承诺。这样我们就有了预期，即使我们真的不能在迭代结束时完成所有的承诺，我们也可以非常清楚地预测剩余的用户故事将延迟多长时间。但质量差会损害我们的期望和估计，你无法预测在接下来的两周里你能填补多少坑。坐在电脑前的你就像在雾中行走，你不知道尽头在哪里，也不知道你在哪里，你必须把头埋在坑里，等到天亮，才能看到路尽头的旗帜。
低质量的代码使得团队成员很难相互支持，特别是对于新人，他们甚至不得不开始重构。这就是为什么没有人愿意去动祖传代码，因为代码质量太差，无法理解和扩展，架构不清晰，逻辑混乱，这几乎摧毁了代码共有。一旦其他人涉及他们不熟悉的部分，就会遇到上面所示的各种大坑，自然就没有办法按照预期的时间完成承诺。
所以，软件开发过程往往是复杂多变的，批量修复不可避免地会带来新的缺陷。
4、团队对质量失去信心
Bug也是会累积的，你的Bug越多，就越难消除每个Bug。这在一定程度上是因为错误是相互作用的，失败可能是许多错误的共同结果，这使得查找每个错误变得困难， 这也是心理上的效应，当出现大量Bug时，人们自然会缺乏发现和解决错误的热情——这在《Pragmatic Programmer》一书中被称为“破窗效应”。
破窗效应（Broken windows theory）是由詹姆士·威尔逊（James Q. Wilson）及乔治·凯林（George L. Kelling）提出的犯罪学理论。根据这一理论，如果允许环境中的不良现象存在，就会诱使人们去模仿，甚至还会变本加厉。比如一栋楼有多扇窗户，少数几块玻璃破了没有去修理，那么就会有更多的窗户可能会被破坏者故意毁坏。
破窗理论很好地解释了为什么会违反代码整洁之道，而且忽视质量问题背后的原因：这是因为它们本来就是垃圾。如果有人在没有惩罚或胁迫的情况下做了坏事，那么我也会做同样的事情，以同样的方式行事，这是很正常的，大家都一样，但是所谓的错误或不相干的缺陷被掩盖和积累，当雪崩发生时，没有一片雪花是无辜的，最后，整个团队都在为质量付出代价。
那么，我们如何避免破窗效应？让我们的质量保持健康呢？
答案就是：每次提交代码时，我们都应该让代码比以上一个版本更干净，哪怕是减少重复的代码，或者是优化一个格式问题。只有这样做，我们才能够避免代码中的坏气味，保持代码和架构的整洁。
联系我们
| 联系人： | 田老师 |
|---|---|
| 电话： | +86 135 5227 9573 |
| Email： | clientservice@hardenx.cn |
| 地址： | 北京市朝阳区福码大厦B座17层1705 |
加微领1G资料
