大家好，我是阿萨。今天聊一个质量内建的话题。
敏捷中的质量内建Built-In Quality
质量内建保证每个解决方案在增量解决方案时满足开发过程中的质量标准。企业在最短的可持续交付周期内发布新功能并适应快速变化的企业环境，取决于解决方案的质量。
不用惊讶于质量内建是SAFe的核心价值之一，同时也是敏捷宣言的原则之一。持续关注技术卓越和良好的设计可增强敏捷性。质量内建也是精益敏捷思维的核心原则，有助于避免与召回、返工和修复缺陷相关的延迟成本 (CoD)。 SAFe质量内建的理念应该使用用系统思维来优化整个系统，确保整个开发价值流的快速流动，让质量成为每个人的工作。
所有的团队，包括软件、硬件、运营、产品营销、法律、安全、合规等，共享质量内建的目标和原则。但是，实践因学科而异，因为它们的产品不同。
SAFe以团队和产品的技术为中心的质量内建的五个方面：Flow、架构和设计质量内建Architecture & Design Quality、代码质量Code Quality、系统质量System Quality 、发布质量Release Quality。基于业务的团队在质量内建实践时，可将参考这五个方面。
Establishing flow是所有团队基本的，因为它描述了如何消除错误，返工和其他降低吞吐量的浪费。其他四个方面描述了适用不同领域的质量内建，包括测试为先test-first、 自动化automation、 基于集合的设计探索替代方案。
1. 通过测试为先和持续交付流水线实现流
敏捷团队在一个快速的、基于流的系统中运转，可以快速开发和发布高质量的业务能力。
敏捷团队不是在最后执行大多数测试，而是尽早、经常和在多个维度上定义和执行大多数测试。
使用测试驱动开发TDD来定义代码更改测试，使用行为驱动BDD来定义故事卡、特性和能力验收标准，使用Lean-UX定义特性收益假设。
构建质量可确保频繁更改的敏捷开发不会引入新错误并实现快速、可靠的执行。
1.1 以测试为先Think Test-First
敏捷团队为一切生成测试，包括特性，故事卡和代码(Features, Stories, and code)等等，理想情况下，在创建item之前或同时，或测试为先。
测试为先的理念同时适用于功能需求(特性和故事卡)和非功能需求的性能和可靠性等。通过开发生命周期中尽早创建测试的一个测试为先的方法来改善传统的“V 模型” 。
为了支持更快的流，测试需要跑的更快，团队努力使它们自动化。至今，大型的基于UI的端到端的测试比小型的自动测试跑的更慢些，我们期望平衡下测试用例，有大量小型快速的测试和少量慢的测试。
测试为先的理念创建一个平衡的测试金字塔。但不幸，很多组织机构的测试不平衡，有太多大量的慢的昂贵的测试和少量快速的性价比高的测试。通过构建大量代码和故事卡测试，组织将减少对慢速的端到端的昂贵的测试的依赖。
1.2 构建持续的交付流水线
质量内建实践有助于构建一个持续的交付流水线(CDP：Continuous Delivery Pipeline)和培养根据需求发布的能力。下图展示了CDP的持续集成部分，展示了在未被产品集成前跨多个环境都要测试组件构建的变更。通过用更快、性价比更高的代理（例如内存数据库代理）替换缓慢或昂贵的组件（例如企业数据库）。
1.3 减少测试套件以加速反馈
随着测试时间的推移而增长，它们将延迟敏捷团队。完整的测试套件可能需要很大的时间来设置和执行。 团队可以创建减少的测试套件和测试数据(“冒烟测试”)，以确保最重要功能，在切换到其他流水）线之前。 他们与系统团队合作以平衡速度和质量，并有助于确保流。
2. 架构和设计质量
系统的架构和设计无疑决定了系统支持当前和将来的业务需要。架构和设计中的质量将未来需求更容易实现，系统更容易测试，更能满足非功能性特性。
2.1 支持未来业务需要
随着市场变化的需求，开发发现或其他原因，架构和设计必须要解决。传统流程中早期决策可能影响次优选项，导致慢流或返工的低效率。识别最佳决策需要知识，通过实验，建模，模拟，原型制作和其他学习活动获得。它还需要一种基于集的设计方法，从多种替代方案中找到最佳决策。一旦确定，开发人员使用架构跑道来实现最终决策。敏捷架构为团队间的设计和实现同步提供指导。
2.2 设计质量
随着系统的需求发展，系统设计必须要支持需求。低质量的设计难以理解和修改，影响到面临多种困难的慢速的交付。应用良好的耦合/凝聚和适当的抽象/封装使实现更易于理解和修改。SOLID原理使系统灵活具有弹性，因此可以更轻松地支持新的需求。设计模式描述了解支持这些原则的知名方法，并提供一种简化的语言，以便于理解和可读性。 命名元素“工厂”或“服务”快速描述系统内更广泛的含义。
2.3 设计和架构使测试容易
架构和设计决定了系统的可测性。通过定义好的接口进行通信的模块化组件创建接缝，允许测试人员和开发人员使用测试替身来代替昂贵的慢速的组件。
3. 代码质量
所有系统的功能最终都是由系统的代码执行起来提供的。添加新功能的速度和难易程度取决于开发人员对其进行修改的速度和可靠性。受极限编程 (XP) 的启发，列出了几种实践。
3.1 单元测试和测试驱动开发
单元测试实践将代码划分成段，并保证每一段可以自动测试。每个片段变更后会自动测试，开发人员可以快速修改并相信修改不会影响到系统中其它部分。测试同样可以作为文档，组件接口间可执行的案例，展示了组件怎样使用的。
测试驱动开发指导我们单元测试的创建，为变更点指明测试点。这迫使开发人员在实施之前更广泛地考虑问题，包括边缘情况和边界条件。更好的理解导致更快的开发，更少的错误和更少的返工。
3.2 结对工作
结对将有两个开发人员在同样工作条件下做相同的变更。开发角色变换频繁。一个充当编写代码的驱动程序，而另一个充当提供实时审查和反馈的导航器。 开发人员经常转换角色。 结对创造和维护质量，因为代码将包含每个成员的共享知识、观点和最佳实践。 随着队友相互学习，它还提高和拓宽了整个团队的技能组合。
3.3 集体所有和代码标准
集体所有可以减少了团队之间的依赖关系，并确保任何开发人员或团队都不会阻碍价值交付的快速流动。任何人都可以添加功能、修复错误、改进设计或重构。因为代码不是一个团队或个人所有，支持编码标准鼓励一致性，以便每个人都可以理解和维护每个组件的质量。
4. 实现系统质量
当代码质量和设计质量保证系统可以很容易理解和变更，系统质量确保系统按期望操作，每个人对每次变更都都保持一致。下面是实现系统质量的几点建议。
4.1创建任务实现快速流
共享理解和一致理解将减少开发延迟和返工，以建立快速流程。
行为驱动开发 (BDD) 定义了一种协作实践，产品负责人和团队成员对故事卡或特性的理解要达成一致。BDD可以帮助开发人员在第一时间构建正确并减少返工和错误。基于模型的系统工程 (MBSE) 将这种对齐方式扩展到整个系统。通过分析和综合过程，MBSE提供了系统所有功能的高级完整视图，以及系统设计如何实现它。
4.2 持续端到端解决方案集成
扩展敏捷性导致许多工程师进行许多小更改，必须不断检查冲突和错误。持续集成 (CI) 和持续交付 (CD) 实践为开发人员提供快速反馈。每个变更都会快速构建，然后在多个级别进行集成和测试，包括部署环境。 CI/CD在所有阶段将变更这一流程自动化，并在测试失败时如何做出响应。NFR的质量测试也是自动化的。 虽然 CI/CD努力使所有测试自动化，但某些功能（探索性）和 NFR（可用性）测试只能手动执行。
5. 发布质量
产品发布时企业会衡量一个特性的收益假设有效性。一个组织发布的越快，学习的越快，交付的价值就越大。组件之间定义了标准接口，这样的模块化架构允许独立发布更小的组件级的变更。 较小的变更允许更快、更频繁、风险更低的发布，但需要自动化流水线来保证质量。
与传统的服务器基础设施不同，“不可变基础设施”不允许手动和直接对生产服务器进行变更。 相反，应用于服务器镜像的变更，验证后启动并替换当前运行的服务器。这种方法创建了更加一致、更可预测的发布。它允许自动恢复。如果操作环境检测到生产错误，它可以通过启动先前的镜像来替换错误的镜像来回滚版本。
5.1 支持合规
对于必须要证明其合规或审计的客观证据的系统，发布具有附加条件。这些组织必须证明该系统符合预期目的并且没有意外的有害后果。 如合规性文章所述，精益质量管理体系 (QMS) 定义了支持精益敏捷、基于流的持续集成-部署-发布流程的批准实践、政策和程序
5.2 完成的可扩展定义
完成的定义是确保增值的一种重要方式。增量系统功能的持续开发需要对完成进行可扩展定义，以确保在正确的时间做正确的工作，有些是提前完成的，有些只是为了发布。 示例如表 1 所示，但每个团队、培训和企业都应建立自己的定义。 虽然每个ART或团队的可能不同，但它们通常共享一组参数项的核心集合。
