全部产品

如何展示和解读交付效能数据

一个迭代或者一个周期结束后,团队需要回顾复盘驱动效能改进,在回顾复盘前需要展示团队当前的效能数据。

作者:舍卫|阿里巴巴集团技术专家

阿里巴巴研发效能度量体系(如下图),通过五个维度来度量团队是否具备了「顺畅、高质量交付价值的能力」,包括需求响应周期、持续发布能力、交付吞吐率、交付过程质量和交付质量,期待能又快又多又好地交付需求。

度量1

1. 需求响应周期

具体包含两个细分的指标,分别是:

交付周期:指的是从确认用户提出的需求开始,到需求上线所经历的平均时长。它反映团队(包含业务、开发、运营等职能)对客户问题或业务机会的响应速度;

开发周期:指的是从开发团队理解需求开始,到需求可以上线所经历的平均时长。它反映技术团队的响应能力。

度量2

区分交付周期和开发周期,是为了解耦并明确问题,以做出针对性的改进。其中,交付周期是最终的目标和检验标准

需求累计流图

云效有丰富的报表统计功能,接下来,我将带领大家一起来学习如何在云效上配置上面的报表。

如下图所示,从「统计」进入,点击「新建报表」,可以看到云效的新建报表列表。

度量3度量4

选择「效能分析」,然后点击「需求累计流图」出现如下图所示的报表:

度量4

每一个蓝色的点代表一个已经发布的需求,横轴是日期,纵轴是天数。这些蓝色的点越朝下越好,代表需求的交付时间越短,响应力也越好;散点的密度越高代表交付频率越高,散点横向上更均匀分布代表持续交付的稳定性越好。

交付周期趋势图

选择「效能分析」,然后点击「交付周期报表」

如下图,选择按月统计,任务选择「需求」,开始状态选「已选择」,结束状态选「已发布」,更新左上角的图表名称为「交付周期趋势图」后保存,即可展现。

度量5

开发周期趋势图

选择「效能分析」,然后点击「交付周期报表」

如下图,选择按周统计,任务选择「需求」,开始状态选「就绪(待开发)」,结束状态选「待发布」,更新左上角的图表名称为「开发周期趋势图」后保存,即可展现。

諎6

下图是开发周期趋势图示例,横轴是时间,按照自然周排列,纵轴是需求个数。每个柱子代表的是当周已到待发布状态需求的数量,各柱子由不同的颜色堆积而成,蓝色代表需求的开发周期时长小于1周,绿色代表需求的开发周期时长在1-2周之间,橙色代表需求的开发周期时长在2-4周之间,红色代表需求的开发周期时长大于4周。

度量7

从上图可以看出,需求开发周期在1周内的需求数量在持续增长,同时一周内的占比也在逐步提升,由于该数据是在8月15日取的,所以最后一周的数据还不全。

2. 持续发布能力

具体包含两个细分指标,分别是:

发布频率:团队对外响应的速度不会大于其交付频率,发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。

发布前置时间(也被称为变更前置时间):也就是从代码提交到功能上线花费的时间,它体现了团队发布的基本能力。如果时间开销很大,就不合适加大发版频率

发布频率

从需求控制图上可以看出持续发布能力的变化,如果需求散点的密度越高,则交付频率越高,反之则越低。

度量8

发布前置时间

发布前置时间,与团队的工程能力有很大的关系,这和云效新品代码平台和流水线强相关,这里暂不做讲解。

3. 交付吞吐率

指的是单位时间内交付需求的数量。关于这一点,常见的问题是,个数能准确反映交付效率吗?这是个问题。所以,我们更多强调单个团队的需求吞吐率的前后对比,统计意义上它足以反映趋势和问题。

需求吞吐率趋势图(按周)

需求响应周期的图表中,需求吞吐率的趋势也已呈现,下图中纵轴代表这一周发布需求的数量,所以柱子越高代表这一周交付的需求越多。

这里吞吐率的计算是按照需求的数量来统计的,在需求颗粒度大小差别很大的时候,吞吐率数据会出现偏差,所以在统计这个之前,期待团队能对需求进行拆分,拆分到工作量在2周之内。

试题10

需求吞吐率趋势图(按迭代)

在自定义图表中选择按迭代和任务状态,然后添加两个筛选条件:迭代和状态。迭代选择需要比较的几个迭代,状态只选已发布的需求。出现如下按照迭代进行比较的吞吐率趋势图。

度量11

4. 交付过程质量

它包含两个细分的指标,分别是:

•开发过程中缺陷的创建和修复时间分布:我们希望缺陷能够持续和及时地被发现,并且在发现后尽快修复;

•缺陷库存:我们希望在整个开发过程中控制缺陷库存量,让产品始终处于接近可发布状态,奠定持续交付的基础。

交付过程质量的核心是内建质量,也就是全过程和全时段的质量。而非依赖特定的阶段,如测试阶段;或特定的时段,如项目后期。内建质量是持续交付的基础,关于其具体度量方法,下文会给出详细实例。

缺陷趋势图

度量12

如上图所示,图中的横坐标是日期,横坐标上方红色竖条代表这一天发现缺陷数量;横坐标下方绿色竖条代表当天解决的缺陷数量;橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。

左半部分,团队属于小瀑布的开发模式。“迭代”前期,团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。

小瀑布模式下,过程质量差,带来大量的返工、延期和交付质量问题。该模式下,产品的交付时间依赖于何时缺陷能被充分移除,当然不能做到持续交付,也无法快速响应外部的需求和变化。并且,这一模式通常都导致后期的赶工,埋下交付质量隐患。

右半部分,团队开始向持续交付模式演进。在整个迭代过程中,团队以小粒度的需求为单位开发,持续地集成和测试它们,即时发现和解决问题。缺陷库存得到控制,系统始终处于接近可发布状态。这一模式更接近持续发布状态,团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存,让系统始终处于接近可发布状态,保障了持续交付能力和对外响应能力。

在项目「统计」中,选择「缺陷分析」,然后点击「缺陷变化趋势」出现如下图所示。

度量13

5. 对外交付质量

它包含两个细分的指标,分别是:

  • 单位时间的故障(线上问题)数;

  • 故障平均解决时长

这两者共同决定了系统的可用性。

加餐:了解研发效能度量详情,欢迎学习阿里巴巴研发效能提升36计第4课-设置北极星指标,数据驱动效能改进

小结

通过以上五组指标,从流动效率、资源效率和质量三个方面讲述了一个完整的故事,回答了目前组织持续交付价值的能力如何这个核心问题。其中,持续发布能力和需求响应周期这两组指标反映价值的流动效率;吞吐率反映资源效率;交付过程质量和对外交付质量这两组指标共同反映质量水平。