我们看到了质量是如何嵌入到敏捷的所有规程中的。如果缺陷在项目生命周期的后期被发现，那么缺陷去除的成本是如何以指数方式增加的，这是很容易理解的。复杂性不仅会增加，因为越来越多的代码是建立在bug之上的，而且修复缺陷还需要一个漫长而复杂的回归周期，因为更改会影响许多系统、模块、组件和数据，以及已经在使用它们的干系人。敏捷团队关注的是前期的质量，在他们的实践中，他们嵌入了预防、早期检测、遏制和早期解决问题和缺陷的原则。让我们在下面的部分中看看这是如何发生的。

    • 在Scrum或XP中，增量交付是一个部分开发、测试和部署的机会。这样可以尽早暴露潜在的bug，并避免在项目结束时进行繁重的集成和测试需求。增量交付的特点之一是简单的紧急设计。
    • 迭代交付，如在Scrum或XP中，确保团队经常让用户测试和审查他们的软件，这样就可以根据反馈进行迭代修改。这称为频繁验证和验证。
    • XP使用小版本发布，消除了长时间的开发周期和复杂的测试周期。通过减少发布版本的规模，XP团队可以确保工作软件的编码、版本控制、测试、构建、集成和部署。对于小的时间盒版本，自动化测试、回归套件测试，是很重要的。
    • 精益通过使用价值流图和无情地剔除非增值活动来持续关注质量。
    • 看板团队限制WIP，在他们接受任何新的工作项目之前，集体解决问题。
    • 敏捷团队不仅关注功能需求，他们也同样关注有助于提高系统性能、稳定性、弹性、可伸缩性和可用性的非功能需求。
    • Scrum团队与产品负责人和用户协作，确定验收测试用例，以验证实现是否符合需求。这些测试用例记录在故事卡片的后面。
    • Scrum团队提出DoD，以确定一个故事何时可以标记为“完成”。这包括证明产品质量的各个方面符合要求，并适合使用。
    • Scrum团队每天都有站立会议，公开分享他们的进展和障碍。其中一些障碍可能与质量实践有关。
    • 功能驱动开发(FDD)使用代码评审来确保良好的代码质量，甚至在代码执行之前防止缺陷。
    • 对于分布式团队来说，编码规范通常是一个很好的做法，这样整个团队都可以遵守相同的约定。
    • XP团队执行结对编程，这也是一种质量控制措施。当一个人编写代码时，另一个人立即审查代码，从大局出发并提供总体方向。
    • 敏捷团队，特别是XP团队，非常重视测试驱动开发(TDD)，团队首先编写测试用例，然后编写足够的代码以通过测试。TDD的细节将在本章后面描述。
    • XP团队不断重构代码，以消除技术债务。有复杂的软件工程工具和实践，如SONAR®，可以评估代码质量(使用SQALE®)，检测技术债务，并提供指示性工作量评估，以删除代码中的违规行为。
    • 敏捷团队使用各种工具和智能工程实践来维护版本控制存储库，并执行持续构建和集成——其中大部分在整个工作期间都在持续使用。
    • scrum团队有回顾会议，而XP团队有反思研讨会，他们在每次迭代结束时寻求持续改进他们的工作方式。
    • 正如在价值驱动的交付中所看到的，敏捷团队可以选择使用一系列指标来跟踪他们的交付，并关注质量方面。一些示例,这些指标是周期时间和前置时间(这有助于发现一些浪费的活动，不增加客户价值和应该被淘汰），逃逸缺陷（描述缺陷泄露和传播到客户），测试用例编写与传递，许多失败的构建等。
    • 团队参与和参与所有仪式、事件或检查点，如发布计划、迭代计划、优先级规划、评估、审查、风险识别、风险分析和缓解以及问题解决，有助于获得多样化和全面的观点，并从参与者那里获得更大的认可。