自从2001年，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地签署《敏捷宣言》以来，敏捷开发（Agile）已越来越深入人心，在敏捷的推进过程中，最常听到的以下的几个问题：
-
敏捷不就是快么？
-
做敏捷是不是只关注效率，不用关注质量？
-
敏捷实施以后，我们的质量下降了，该谁来负责？
有以上疑问的同学需要先理解一个理念，敏捷并不单纯意味着效率的提升和交付时间的减少，敏捷也意味着在快速的反馈中去寻求最优的质量。（关于敏捷，推荐这篇文章：agile-10-years-on）
关于质量的定义有许多，哈佛商学院教授 David A. Garvin在1984 年所写的《定义质量的五种方法》将质量定义为卓越的质量、基于价值的质量、基于用户的质量、基于产品的质量和基于制造的质量。
卓越的质量：氛围，天生的卓越气质，举世公认的成就（很难，万众追求的目标）
基于价值的质量：价格和成本（股东们会很看重的部分）
基于用户的质量：对某些人（一考虑质量大多数人就会想到的那些人）的价值
基于产品的质量：你的用户在寻求什么?(包括产品的功能、性能、可靠性、一致性、耐用性、适用性、审美性、品质认知度-出自David的1988年《Managing Quality：The Strategic and Competitive Edge)
-
基于制造的质量：实践、过程、标准、要求、规范，我们做得对么？
5 type of quality .jpg
对于做研发的大部分人来说，重点关注的还是里面的三种质量，也就是基于用户的，基于产品的和基于制造的质量。
针对于基于用户的质量，通常会在需求分析及系统上线以后的用户反馈上得到很好的反馈，而后面的两项，组织中在设计质量度量体系的时候或者生产事件分析的时候，通常会从交付过程质量和交付产品质量两方面来做考量。
阿里最新的研发效能度量体系中也从这两个维度上对质量进行了度量：
交付过程质量指的是在完成产品交付的过程中所需要度量的质量，它包含两个细分的指标，分别是：
- 开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现（测试人员负主责），并且在发现后尽快修复（开发人员负主责）；
- 缺陷库存。我们希望在整个开发过程中控制缺陷量，让产品始终处于接近可发布状态，奠定持续交付的基础（团队都需要负责）。
交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础。
交付产品质量的核心是交付阶段的质量，决定了系统的可用性。能否让系统持续稳定的运作并能及时快速的解决线上问题，开发团队和运营团队都需要付出努力。
如何使软件质量能做的更好，这会是之后我们持续会想去讨论的问题。有相关问题的也欢迎大家来留言多多讨论。
