| 2023-05-10
在软件服务和解决方案提供商中，「在行业内，有领先的交付速度」是一个常被反复提及的价值主张。而速度的基本承诺是：尽早提供商业价值。但是，正如我们在过去有关敏捷和加速软件交付的文章中讨论过的那样，假如你没能定义出能产生价值的东西，那么构建它的速度可能就无关紧要了。
也就是说，价值探索环所决定的东西，其外部价值很可能已经是 0 或负值。验证环所要做的，只是如何低成本及快速地知道这个决定的最终商业答案而已。
为了说明这一点，我们只需看一下懂得很多关于速度的行业：汽车制造业。
丰田重新定义了对质量的看法
在第二次世界大战后的套装产品时代，关注点从质量转向了数量，美国商业领袖最初拒绝了这个想法。严格的质量控制被视为过度的，会减慢生产时间。
1970年代末期，曾经强大的美国汽车工业面临一个选择：进化或灭亡。
著名管理咨询师W。 Edwards Deming 的理念曾经帮助一个曾经不如人的日本汽车工业——特别是丰田汽车公司——成为一个行业颠覆者。
Deming 的哲学很简单：持续、渐进式的改进可以得到高质量的产品。通过在整个生产过程中加入质量控制原则，企业可以在时间范围内以最低的总成本生产出最高的质量。
Deming 关注质量的思想提供了许多关于如何构建更好的软件产品、更快地提供价值的见解。从软件开发的角度重新审视这些思想，可以深入了解企业如何改进其软件交付策略。Deming 的工作帮助开创了精益生产，改变了汽车工业。同样的原则也指导着敏捷软件方法的开始，特别是软件交付周期中的质量控制。
为什么软件产品质量很重要，尤其是 toB 产品。
在深入研究 Deming 的理论之前，首先需要讨论为什么拥有高质量的产品很重要。我们生活在一个客户期望不断上升、品牌忠诚度不断下降的时代。如果一个产品不符合客户的质量标准，人们就会转向符合标准的产品。即使客户留下来了，低质量的产品也会增加修复和维护的成本负担。
如何将持续改进付诸实践？
高质量的产品并不是神奇地出现的。它们是在整个产品生命周期中进行了严格的测试、反馈和相应的调整的结果。
“质量来自于生产过程的改进，而不是依赖后期的大规模检验。” —— 威廉·爱德华·戴明博士，美国工程师和作家
敏捷、DevOps和价值驱动的开发：有什么区别？
由于我们在使用多个时髦的术语，让我们简要定义每个术语的含义和其在更大的环境中的位置。
价值驱动的开发是应该指导团队下一步构建的愿景。敏捷方法赋予软件交付团队平稳执行日常活动的能力，并将可衡量的价值作为清晰的目标。DevOps则希望创造最优团队，以实现所定义价值的文化和组织结构。
以上可以称为上三路，用于设定方向与愿景，要想落实它们，需要下三路的支持：那就是：
持续集成（CI）：代码持续地编写到共享存储库中。 持续部署（CD）：在尽可能短的周期内设计、编码、测试和发布软件。 持续测试（CT）：测试在过程的每个阶段随时进行。如果代码失败，则返回开发；如果通过，则进入下一个阶段。 持续运营（CO）：生产环境是软件真正产生商业价值的现场。应该持续保持健康状态。
无论是哪个行业，构建高质量的产品都是长期增长和生产力提高的关键。
将日本汽车制造商从以质量差的Datsuns（参见下面的25马力Datsun 113）为代名词提升到拥有金安全标准的丰田凯美瑞的关键在于持续改进——随着时间的推移，对设计和流程进行小的、渐进式的改变。
以下是实施持续软件质量保证以改善流程的几个步骤：
1. 将测试和开发结合
在软件开发中，质量控制实践是通过质量保证（QA）和测试实现的。直到最近，主流的软件开发模型是瀑布式工作流，其中开发遵循线性路径：设计、编码、测试。在瀑布流程中，每个阶段可能需要数月的时间，这在构建和测试之间创建了巨大的间隔。
瀑布方法类似于主要美国汽车制造商采用的方法——也是德明所批评的方法：在产品构建后进行测试，这意味着任何错误或不正确的假设直到生产的最后阶段才会被发现。这使得问题更难以检测和修复，严重影响（甚至停止）生产。
虽然 Scrum方法 将设计-编码-测试开发周期缩短为两周，但两周的间隔仍然太长。为了将质量控制充分融入开发流程中，测试和QA必须是时刻进行。
最好的实现方式是打破部门之间的壁垒，创造一个测试和编码信息可以自由共享的团队环境。在软件交付中，这是一个称为 DevOps 的反馈循环，即开发和运维的融合。
2. 通过DevOps采用消除部门间的障碍
DevOps和敏捷并非相互竞争的理念，而是一脉相承，相辅相成的。敏捷宣言阐明了一些实践，使跨职能团队能够迭代地向用户交付工作软件。所有假设都通过在一个弹性环境中的用户测试进行验证，而不是预先确定的路线图。
DevOps方法将这种方法推向了更深入的一步，创建了一种消除两个部门间障碍的团队结构。在DevOps组织中，团队作为一个紧密的整体运作，而不是分散的孤岛。开发人员、测试人员、运维管理员甚至用户作为一个统一的团队，共同负责构建、测试和部署产品。
尤其在丰田公司，团队中的每个成员都对最终产品的质量和结果负责。这创造了对从生产线上下来的汽车的所有权感和自豪感。
3. 测试是一个连续的过程，而不是一个阶段
如我们所述，当测试发生在生产周期的最后阶段时，测试就成了一个瓶颈，导致质量下降和生产时间延长。
这就是测试自动化和持续测试的作用。构建自动化测试平台需要前期成本，许多组织对此感到犹豫不决。然而，如果你正在建造一座摩天大楼，自动化测试平台就是必须在放置一个砖头之前搭建的脚手架。
有了这个“脚手架”，组织可以每十分钟部署一次代码，而不是每两小时或两个月部署一次。这样可以更快地产生反馈和结果，更容易发现错误。由于测试可以实时进行，它允许 DevOps 团队专注于开发新功能，并在长期内降低测试成本。随着时间的推移，流程变得更加流畅，产生连续的、逐步的改进，从而创造出质量和效率——最终，实现更好的产品。
但是，如果将自动化测试仅视为效率和速度，那就错过了重点。当像测试清单这样的乏味任务被自动化时，团队就能够专注于开发更高水平的质量和定制的手工测试。优化、自动化的QA和测试的结果会影响开发团队编写新的干净代码的方式。
我已经有CI/CD流水线了，为什么质量还不好？
许多组织已经采用了DevOps和CI/CD流程，但仍未实现任何质量保证或有价值的成果。在评估为什么 CI/CD流水线未产生结果时，请考虑以下问题：
您想通过CI/CD系统实现什么目标？如果目标仅是为了更快地推向市场，那么您并没有遵循使得戴明和丰田成功的原则。将CI/CD系统设计为市场速度的策略只会导致质量不佳。通过优化CI/CD流水线来改善产品构建机器的问题，结果将是一个质量更好、过程中浪费更少的产品。
您是如何自动化以确保软件质量的？CI/CD流程的目标应该是在尽可能早的阶段暴露问题。当正确构建时，CI/CD系统甚至不允许您提交错误代码。当检测到错误时，暂停生产，修复问题的根本原因，然后继续前进。有了这样的实践，开发人员将变得更加擅长确保下次不会发生任何错误。首先掌握流程，然后再自动化它。
您的文化是否支持“快速失败”？要拥有质量文化，领导者必须创建一个接受失败并将其视为学习机会的环境。这需要一个让人们有权承担自己的错误、修复它们并确保它们不会再次发生的环境。每个人都要对质量负责。
您是否赋予QA分析师权力？请注意，我没有称他们为“测试人员”。质量分析师或策略师是一个可以分析系统中出现的问题并提出改进建议的人，贯穿整个产品开发生命周期。另一方面，测试人员是被动的，提供二进制的通过/失败反馈，而不考虑改进的方法。在这种环境中，QA分析师可以帮助开发人员了解他们正在进行的测试及其原因。开发人员反过来可以开始编写考虑测试如何运行的代码，从而加快交付和价值。
CI/CD 流水线几乎可以即时提供反馈，在加速开发方面具有巨大潜力。但是，该系统的成功，取决于领导者推崇鼓励信息自由流动、容忍失败和专注于价值的文化。
如果构建正确的系统，速度会随之而来。
戴明在优化汽车制造方面的工作为我们提供了一个历史背景，告诉我们如何构建质量软件产品或服务。
即使70年之后，他的思想仍然如此相关。
然而，软件服务和解决方案提供商以及IT企业在采用这种受戴明启发的哲学方面一直很慢。
如果快速交付是你唯一的目标，那么很容易陷入导致美国汽车制造商落后的数量思维中。
更好的方法是创建改进的质量系统-一个良好运作的持续交付流水线。
构建正确的系统，速度会随之而来。