|看懂这5幅图，研发效能分析和改进就容易了( 三 )

图片来源：云效效能洞察Insight
指标卡中数据含义：
缺陷趋势图：横坐标为日期，纵坐标为缺陷数量，横坐标上方红色柱子代表这一天发现缺陷数量；横坐标下方绿色柱子代表这一天解决的缺陷数量；橙色曲线代表缺陷存量。
在「缺陷趋势」指标卡中，我们可以分析：
1. 看团队的交付模式
如果长时间没发现缺陷，而到某一段时间集中新增大量缺陷，能够反映出是瀑布交付模式。如果缺陷被持续发现和持续解决，且存量缺陷处于较低水位，这种情况更容易形成持续交付模式。
2. 看存量缺陷的多少，判断交付质量
需求在上线前，一般需要把缺陷数量清零，如果项目的存量缺陷一直处于较低水位，反映出交付质量比较高。
举一个从小瀑布模式向持续交付模式转变的例子，如图：
图片来源：云效效能洞察Insight
左半部分
团队属于小瀑布的开发模式。前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。越到后期发现的缺陷，修复难度大幅提升，修复成本大幅增加。
小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，无法做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。
右半部分
团队开始向持续交付模式演进，质量得到控制。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。
接下来我们来看「缺陷修复分布」：
图片来源：云效效能洞察Insight
指标卡中数据含义：
缺陷修复分布，也叫缺陷控制图，横坐标为时间，纵坐标为缺陷修复周期（天），图中：
圆点：代表一个已修复的缺陷，它所在的横坐标为修复时间，纵坐标为该缺陷的修复时长；折线：代表缺陷修复周期的滚动均值，取该点以及前后各1/3/5/7/9个点（随区间事项数变动）的平均值；面积：红色阴影区域代表滚动标准差，即实际数据与滚动平均值的变偏差量；横线：所选时间区间内，缺陷修复周期的平均值。在看到「缺陷修复分布」图的数据时，我们可以从 4 个方面理解和分析：

纵向上，代表已修复缺陷的圆点越向下越好，反映出修复周期越短、修复能力越快；横向上，代表已修复缺陷的圆点数量越少越好，越少代表缺陷的数量越少，开发提测的质量比较高；平均修复时长线，代表团队缺陷修复周期的一个基本水位，越低越好。很多团队会设定缺陷修复目标，譬如缺陷要日清，即缺陷要在发现后的 24 小时内修复；滚动均值折线，展示缺陷修复周期的变化趋势，期望有往下走的趋势，代表团队修复缺陷的速度越来越快。缺陷修复分布图，对于团队来说，可用于在回顾会上分析团队过去的质量情况，也可根据历史的情况，来设定团队的缺陷修复目标。整体回顾我们可以从产能、效率和质量 3 个维度来观测团队的研发效能现状，并进行针对性分析，重点观测 5 幅图：需求交付速率：反应团队历史的需求交付吞吐量，可对未来的交付产能进行预测；需求交付分布：反应团队历史的需求响应能力，可对未来的需求交付速度进行预测；需求累积流图：反应团队整体的协作模式，可分析团队的交付模式和交付能力；缺陷趋势图：反应团队历史的过程质量情况，可分析团队的交付模式和质量状况；缺陷修复分布：反应团队历史的缺陷修复速度，可对团队的缺陷修复速度进行预测。如果需要更多数据进行分析，也可以参考：需交付时长按阶段分布、需求累积流图、存量缺陷按成员排名、存量缺陷占比等。不管在阿里内部，还是我们接触的大部分客户，大家通常以缩短需求交付周期为目标。阿里提出的“ 211” 目标中，第一个 2 就是要把需求交付周期缩短到到两周。原文链接：http://click.aliyun.com/m/1000325317/ 本文为阿里云原创内容，未经允许不得转载。