敏捷开发交付绩效度量

在快速敏捷开发模式下，主要是要求技术能够快速响应，但并不是对质量没有要求，那么在又快又要质量好的前提下，如何去度量？

主要参考文章，软件交付效能度量 - Thoughtworks洞见

说明：如何在敏捷开发模式下，拆分需求——用户故事，如何建立度量指标，有一个比较好的方向，和指导原则。

这种开发模式适合面对用户市场，手机APP的开发模式。

对质量度量的升入了解，对本文的一些内容，有了更深层次的了解，一下斜体字部分是后续的解读，

参考资料：持续交付报告解读：敏稳双运，精英级效能组织DevOps五大黄金指标-优快云博客

速度指标

• 变更前置时间，个人解读：包括开发和测试，技术端的吞吐量，业务能力。

去掉需求占用的时间，体现开发，测试，技术团队实现变更的时间。

• 部署频率   作者认为频率高是好事情，个人认为频率高，版本发布频繁，在测试角度会增加工作量，对质量并不是一个好的指标。

从技术团队角度就是持续交付的角度，快速交付的角度，去衡量某种特别的项目，实现一个需求的部署时间，换算成一个月可以交付几次，从而体现部署频率

以上两个是从速度角度，来衡量技术团队响应速度的指标。

稳定指标

• 变更失败率，基于以上理解，出现了这个指标，那么意味着前次版本有缺陷，所以不断提交版本，从变更次数上体现问题。可理解成一次通过率。

深入了解以后，认为这个指标是从需求提出到上线，上线失败的衡量指标，从稳定的角度，一个新的需求，就是一个变更，新需求顺利上线的能力；失败率越低，就意味着整体团队维持稳定的能力越高，能持续接受需求的变更实施。但是需要明确失败的定义，是从需求价值回溯的角度，还是指上线失败的情况。

• 服务恢复耗时，服务恢复耗时是指当服务中断或降级后，需要花费多少时间将服务恢复正常。反向思维，统计缺陷类的耗时，花费时间越长，一个反馈技术的整体能力，或者反馈需求的逻辑复杂型。通过事后分析原因，反应是技术问题，还是需求问题。

从生产运维的角度，类似callcenter的机构，面对客户反馈的问题（导致服务中断或者降级），统计运维的技术团队，解决一个问题的恢复时间。还有一个角度从修复这个这个故障，开发和测试总体耗费的时间。去计算平均耗时。

诊断型指标

常见的"诊断型"指标包括但不限于:

1. 平均构建时间
2. 测试覆盖率
3. 代码圈复杂度
4. 团队速率