敏捷开发交付绩效度量

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

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

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

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

  • 变更前置时间,从开发到发版本之间的时间,个人解读:包括开发和测试,技术端的吞吐量,业务能力
  • 部署频率   作者认为频率高是好事情,个人认为频率高,版本发布频繁,在测试角度会增加工作量,对质量并不是一个好的指标
  • 变更失败率,基于以上理解,出现了这个指标,那么意味着前次版本有缺陷,所以不断提交版本,从变更次数上体现问题。可理解成一次通过率。
  • 服务恢复耗时,服务恢复耗时是指当服务中断或降级后,需要花费多少时间将服务恢复正常。反向思维,统计缺陷类的耗时,花费时间越长,一个反馈技术的整体能力,或者反馈需求的逻辑复杂型。通过事后分析原因,反应是技术问题,还是需求问题。

诊断型指标

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

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

你可能感兴趣的:(敏捷流程)