在快速敏捷开发模式下，主要是要求技术能够快速响应，但并不是对质量没有要求，那么在又快又要质量好的前提下，如何去度量？
主要参考文章，软件交付效能度量 - Thoughtworks洞见
说明：如何在敏捷开发模式下，拆分需求——用户故事，如何建立度量指标，有一个比较好的方向，和指导原则。
这种开发模式适合面对用户市场，手机APP的开发模式。
- 变更前置时间，从开发到发版本之间的时间，个人解读：包括开发和测试，技术端的吞吐量，业务能力
- 部署频率 作者认为频率高是好事情，个人认为频率高，版本发布频繁，在测试角度会增加工作量，对质量并不是一个好的指标
- 变更失败率，基于以上理解，出现了这个指标，那么意味着前次版本有缺陷，所以不断提交版本，从变更次数上体现问题。可理解成一次通过率。
- 服务恢复耗时，服务恢复耗时是指当服务中断或降级后，需要花费多少时间将服务恢复正常。反向思维，统计缺陷类的耗时，花费时间越长，一个反馈技术的整体能力，或者反馈需求的逻辑复杂型。通过事后分析原因，反应是技术问题，还是需求问题。
诊断型指标
常见的"诊断型"指标包括但不限于:
- 平均构建时间
- 测试覆盖率
- 代码圈复杂度
- 团队速率
