术语：SAFe(Scaled Agile Framework) 规模化敏捷架构。
敏捷中的质量内建Built-In Quality
质量内建保证每个解决方案在增量解决方案时满足开发过程中的质量标准。企业在最短的可持续交付周期内发布新功能并适应快速变化的企业环境，取决于解决方案的质量。
不用惊讶于质量内建是SAFe的核心价值之一，同时也是敏捷宣言的原则之一。持续关注技术卓越和良好的设计可增强敏捷性。质量内建也是精益敏捷思维的核心原则，有助于避免与召回、返工和修复缺陷相关的延迟成本 (CoD)。 SAFe质量内建的理念应该使用用系统思维来优化整个系统，确保整个开发价值流的快速流动，让质量成为每个人的工作。
所有的团队，包括软件、硬件、运营、产品营销、法律、安全、合规等，共享质量内建的目标和原则。但是，实践因学科而异，因为它们的产品不同。
SAFe以团队和产品的技术为中心的质量内建的五个方面：Flow、架构和设计质量内建Architecture & Design Quality、代码质量Code Quality、系统质量System Quality 、发布质量Release Quality。基于业务的团队在质量内建实践时，可将参考这五个方面。
Establishing flow是所有团队基本的，因为它描述了如何消除错误，返工和其他降低吞吐量的浪费。其他四个方面描述了适用不同领域的质量内建，包括测试为先test-first、 自动化automation、 基于集合的设计探索替代方案。
1. 通过测试为先和持续交付流水线实现流 Achieving Flow with Test-First and a Continuous Delivery Pipeline
敏捷团队在一个快速的、基于流的系统中运转，可以快速开发和发布高质量的业务能力。Agile teams operate in a fast, flow-based system to quickly develop and release high-quality business capabilities.
敏捷团队不是在最后执行大多数测试，而是尽早、经常和在多个维度上定义和执行大多数测试。Instead of performing most testing at the end, Agile teams define and execute many tests early, often, and at multiple levels.
使用测试驱动开发TDD来定义代码更改测试，使用行为驱动BDD来定义故事卡、特性和能力验收标准，使用Lean-UX定义特性收益假设。Tests are defined for code changes using Test-Driven Development , Story, Feature, and Capability acceptance criteria using Behavior-Driven Development (BDD), and Feature benefit hypothesis using Lean-UX.
构建质量可确保频繁更改的敏捷开发不会引入新错误并实现快速、可靠的执行。Building in quality ensures that Agile development’s frequent changes do not introduce new errors and enables fast, reliable execution.
1.1 以测试为先Think Test-First
敏捷团队为一切生成测试，包括特性，故事卡和代码(Features, Stories, and code)等等，理想情况下，在创建item之前或同时，或测试为先。
测试为先的理念同时适用于功能需求(特性和故事卡)和非功能需求的性能和可靠性等。通过开发生命周期中尽早创建测试的一个测试为先的方法来改善传统的“V 模型” 。Test-first applies to both functional requirements (Feature and Stories) as well as non-functional requirements (NFRs) for performance, reliability, etc. A test-first approach collapses the traditional “V-Model” by creating tests earlier in the development cycle。
为了支持更快的流，测试需要跑的更快，团队努力使它们自动化。至今，大型的基于UI的端到端的测试比小型的自动测试跑的更慢些，我们期望平衡下测试用例，有大量小型快速的测试和少量慢的测试。To support fast flow, tests need to run quickly, and teams strive to automate them. Since larger, UI-based, end-to-end tests run much slower than small, automated tests, we desire a balanced testing portfolio with many small fast tests and fewer large slow tests.
测试为先的理念创建一个平衡的测试金字塔。但不幸，很多组织机构的测试不平衡，有太多大量的慢的昂贵的测试和少量快速的性价比高的测试。通过构建大量代码和故事卡测试，组织将减少对慢速的端到端的昂贵的测试的依赖。Test-first thinking creates a balanced Testing Pyramid. Unfortunately, many organizations testing portfolios are unbalanced, with too many large, slow, expensive tests, and too few small, quick, cheap tests. By building large amounts of code and Story-level tests, organizations reduce their reliance on slower, end-to-end, expensive tests.
1.2 构建持续的交付流水线Build a Continuous Delivery Pipeline
质量内建实践有助于构建一个持续的交付流水线(CDP：Continuous Delivery Pipeline)和培养根据需求发布的能力。下图展示了CDP的持续集成部分，展示了在未被产品集成前跨多个环境都要测试组件构建的变更。通过用更快、性价比更高的代理（例如内存数据库代理）替换缓慢或昂贵的组件（例如企业数据库）。Built-in quality practices help create a Continuous Delivery Pipeline (CDP) and the ability to Release on Demand. Figure 5 illustrates the Continuous Integration portion of the CDP and shows how changes built into components are tested across multiple environments before arriving in production. ‘Test doubles’ speed testing by substituting slow or expensive components (e.g., enterprise database) with faster, cheaper proxies (e.g., in-memory database proxy).
1.3 减少测试套件以加速反馈Accelerate Feedback with Reduced Test Suites
随着测试时间的推移而增长，它们将延迟敏捷团队。完整的测试套件可能需要很大的时间来设置和执行。 团队可以创建减少的测试套件和测试数据(“冒烟测试”)，以确保最重要功能，在切换到其他流水）线之前。 他们与系统团队合作以平衡速度和质量，并有助于确保流。As tests can grow over time, they delay Agile teams. Complete test suites can take significant time to set up and execute. Teams may create reduced test suites and test data (a ‘smoke test’) to ensure the most important functionality before moving through other pipeline stages. They collaborate with the System Team to balance speed and quality and help ensure flow.
2. 架构和设计质量Achieving Architecture and Design Quality
系统的架构和设计无疑决定了系统支持当前和将来的业务需要。架构和设计中的质量将未来需求更容易实现，系统更容易测试，更能满足非功能性特性。A system’s architecture and design ultimately determine how well a system can support current and future business needs. Quality in architecture and design make future requirements easier to implement, systems easier to test, and helps to satisfy NFRs.
2.1 支持未来业务需要Support Future Business Needs
随着市场变化的需求，开发发现或其他原因，架构和设计必须要解决。传统流程中早期决策可能影响次优选项，导致慢流或返工的低效率。识别最佳决策需要知识，通过实验，建模，模拟，原型制作和其他学习活动获得。它还需要一种基于集的设计方法，从多种替代方案中找到最佳决策。一旦确定，开发人员使用架构跑道来实现最终决策。敏捷架构为团队间的设计和实现同步提供指导。
2.2 设计质量Design for Quality
随着系统的需求发展，系统设计必须要支持需求。低质量的设计难以理解和修改，影响到面临多种困难的慢速的交付。应用良好的耦合/凝聚和适当的抽象/封装使实现更易于理解和修改。SOLID原理使系统灵活具有弹性，因此可以更轻松地支持新的需求。设计模式描述了解支持这些原则的知名方法，并提供一种简化的语言，以便于理解和可读性。 命名元素“工厂”或“服务”快速描述系统内更广泛的含义。
Applying good coupling/cohesion and appropriate abstraction/encapsulation make implementations easier to understand and modify.
2.3 设计和架构使测试容易Architecting and Designing to Ease Testing
架构和设计决定了系统的可测性。通过定义好的接口进行通信的模块化组件创建接缝，允许测试人员和开发人员使用测试替身来代替昂贵的慢速的组件。Architecture and design also determine a system’s testability. Modular components that communicate through well-defined interfaces create seams that allow testers and developers to substitute expensive or slow components with test doubles.
3. 代码质量Achieving Code Quality
所有系统的功能最终都是由系统的代码执行起来提供的。添加新功能的速度和难易程度取决于开发人员对其进行修改的速度和可靠性。受极限编程 (XP) 的启发，列出了几种实践。All system capabilities are ultimately executed by the code (or components) of a system. The speed and ease to add new capabilities depend on how quickly and reliably developers can modify it. Inspired in part by Extreme Programming (XP) [9], several practices are listed here.
3.1 单元测试和测试驱动开发Unit Testing and Test-Driven Development
单元测试实践将代码划分成段，并保证每一段可以自动测试。每个片段变更后会自动测试，开发人员可以快速修改并相信修改不会影响到系统中其它部分。测试同样可以作为文档，组件接口间可执行的案例，展示了组件怎样使用的。The unit testing practice breaks the code into parts and ensures that each part has automated tests to exercise it. These tests run automatically after each change and allow developers to make fast changes, confident that the modification won’t break another part of the system. Tests also serve as documentation and are executable examples of interactions with a component’s interface to show how that component should be used.
测试驱动开发指导我们单元测试的创建，为变更点指明测试点。这迫使开发人员在实施之前更广泛地考虑问题，包括边缘情况和边界条件。更好的理解导致更快的开发，更少的错误和更少的返工。 Test-Driven Development (TDD) guides the creation of unit tests by specifying the test for a change before creating it. This forces developers to think more broadly about the problem, including the edge cases and boundary conditions before implementation. Better understanding results in faster development with fewer errors and less rework.
3.2 结对工作Pair Work
结对将有两个开发人员在同样工作条件下做相同的变更。开发角色变换频繁。一个充当编写代码的驱动程序，而另一个充当提供实时审查和反馈的导航器。 开发人员经常转换角色。 结对创造和维护质量，因为代码将包含每个成员的共享知识、观点和最佳实践。 随着队友相互学习，它还提高和拓宽了整个团队的技能组合。
Pairing has two developers work the same change at the same workstation. One serves as the driver writing the code while the other as the navigator providing real-time review and feedback. Developers switch roles frequently. Pairing creates and maintains quality as the code will contain the shared knowledge, perspectives, and best practices from each member. It also raises and broadens the skillset for the entire team as teammates learn from each other.
3.3 集体所有和代码标准Collective Ownership and Coding Standards
集体所有可以减少了团队之间的依赖关系，并确保任何开发人员或团队都不会阻碍价值交付的快速流动。任何人都可以添加功能、修复错误、改进设计或重构。因为代码不是一个团队或个人所有，支持编码标准鼓励一致性，以便每个人都可以理解和维护每个组件的质量。
Collective ownership reduces dependencies between teams and ensures that any individual developer or team will not block the fast flow of value delivery. Any individual can add functionality, fix errors, improve designs, or refactor. Because the code is not owned by one team or individual, supporting coding standards encourages consistency so that everyone can understand and maintain the quality of each component.
4. 实现系统质量Achieving System Quality
当代码质量和设计质量保证系统可以很容易理解和变更，系统质量确保系统按期望操作，每个人对每次变更都都保持一致。下面是实现系统质量的几点建议。
While code and design quality ensure that system artifacts can be easily understood and changed, system quality confirms that the systems operate as expected and that everyone is aligned on what changes to make. Tips for achieving system quality are highlighted below.
4.1创建任务实现快速流Create Alignment to Achieve Fast Flow
共享理解和一致理解将减少开发延迟和返工，以建立快速流程。Alignment and shared understanding reduce developer delays and rework, enabling fast flow.
行为驱动开发 (BDD) 定义了一种协作实践，产品负责人和团队成员对故事卡或特性的理解要达成一致。BDD可以帮助开发人员在第一时间构建正确并减少返工和错误。基于模型的系统工程 (MBSE) 将这种对齐方式扩展到整个系统。通过分析和综合过程，MBSE提供了系统所有功能的高级完整视图，以及系统设计如何实现它。
Behavior-Driven Development (BDD) defines a collaborative practice where the Product Owner and team members agree on the precise behavior for a story or feature. Applying BDD helps developers build the right behavior the first time and reduces rework and errors. Model-Based Systems Engineering (MBSE) scales this alignment to the whole system. Through an analysis and synthesis process, MBSE provides a high-level, complete view of all the proposed functionality for a system, and how the system design realizes it.
4.2 持续端到端解决方案集成Continuously Integrate the End-to-End Solution
扩展敏捷性导致许多工程师进行许多小更改，必须不断检查冲突和错误。持续集成 (CI) 和持续交付 (CD) 实践为开发人员提供快速反馈。每个变更都会快速构建，然后在多个级别进行集成和测试，包括部署环境。 CI/CD在所有阶段将变更这一流程自动化，并在测试失败时如何做出响应。NFR的质量测试也是自动化的。 虽然 CI/CD努力使所有测试自动化，但某些功能（探索性）和 NFR（可用性）测试只能手动执行。
Scaling agility results in many engineers making many small changes that must be continually checked for conflicts and errors. Continuous integration (CI) and continuous delivery (CD) practices provide developers with fast feedback (Figure 8). Each change is quickly built then integrated and tested at multiple levels, including the deployment environment. CI/CD automates the process to move changes across all stages and knows how to respond when a test fails. Quality tests for NFRs are also automated. While CI/CD strives to automate all tests, some functional (exploratory) and NFR (usability) testing can only be performed manually.
5. 发布质量Achieving Release Quality
产品发布时企业会衡量一个特性的收益假设有效性。一个组织发布的越快，学习的越快，交付的价值就越大。组件之间定义了标准接口，这样的模块化架构允许独立发布更小的组件级的变更。 较小的变更允许更快、更频繁、风险更低的发布，但需要自动化流水线来保证质量。
Releasing allows the business to measure the effectiveness of a Feature’s benefit hypothesis. The faster an organization releases, the faster it learns and the more value it delivers. Modular architectures that define standard interfaces between components allow smaller, component-level changes to be released independently. Smaller changes allow faster, more frequent, less risky releases, but require an automated pipeline (shown in Figure 2) to ensure quality.
与传统的服务器基础设施不同，“不可变基础设施”不允许手动和直接对生产服务器进行变更。 相反，应用于服务器镜像的变更，验证后启动并替换当前运行的服务器。这种方法创建了更加一致、更可预测的发布。它允许自动恢复。如果操作环境检测到生产错误，它可以通过启动先前的镜像来替换错误的镜像来回滚版本。
Unlike a traditional server infrastructure, an ‘immutable infrastructure’ does not allow changes to made manually and directly to production servers. Instead, changes are applied to server images, validated, and then launched to replace currently running servers. This approach creates more consistent, predictable releases. It also allows for automated recovery. If the operational environment detects a production error, it can roll back the release by simply launching the previous image to replace the erroneous one.
5.1 支持合规Supporting Compliance
对于必须要证明其合规或审计的客观证据的系统，发布具有附加条件。这些组织必须证明该系统符合预期目的并且没有意外的有害后果。 如合规性文章所述，精益质量管理体系 (QMS) 定义了支持精益敏捷、基于流的持续集成-部署-发布流程的批准实践、政策和程序
For systems that must demonstrate objective evidence for compliance or audit, releasing has additional conditions. These organizations must prove that the system meets its intended purpose and has no unintended, harmful consequences. As described in the Compliance article, Lean Quality Management System (QMS) defines approved practices, policies, and procedures that support a Lean-Agile, flow-based, continuous integrate-deploy-release process.
5.2 完成的可扩展定义Scalable Definition of Done
完成的定义是确保增值的一种重要方式。增量系统功能的持续开发需要对完成进行可扩展定义，以确保在正确的时间做正确的工作，有些是提前完成的，有些只是为了发布。 示例如表 1 所示，但每个团队、培训和企业都应建立自己的定义。 虽然每个ART或团队的可能不同，但它们通常共享一组参数项的核心集合。
Definition of Done is an important way of ensuring increment of value can be considered complete. The continuous development of incremental system functionality requires a scaled definition of done to ensure the right work is done at the right time, some early and some only for release. An example is shown in Table 1, but each team, train, and enterprise should build their own definition. While these may be different for each ART or team, they usually share a core set of items.
参考资料
