云效研发效能度量体系，如何展示和解读交付效能数据

云效研发效能度量体系，如何展示和解读交付效能数据，一个迭代或者一个周期结束后，团队需要回顾复盘驱动效能改进，在回顾复盘前需要展示团队当前的效能数据。通过研发效能度量来度量团队是否具备了交付价值的能力。

作者：舍卫｜阿里巴巴集团技术专家

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

1. 需求响应周期

具体包含两个细分的指标，分别是：

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

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

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

需求累计流图

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

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

说明 

立即体验：云效项目管理

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

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

交付周期趋势图

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

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

开发周期趋势图

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

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

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

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

2. 持续发布能力

具体包含两个细分指标，分别是：

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

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

发布频率

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

发布前置时间

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

3. 交付吞吐率

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

需求吞吐率趋势图（按周）

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

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

需求吞吐率趋势图（按迭代）

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

4. 交付过程质量

它包含两个细分的指标，分别是：

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

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

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

缺陷趋势图

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

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

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

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

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

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

5. 对外交付质量

它包含两个细分的指标，分别是：

• 单位时间的故障（线上问题）数；

• 故障平均解决时长

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

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

小结

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

关于我们

了解更多关于云效 DevOps 的最新动态，可微信搜索关注【云效】公众号；

彩蛋：公众号后台回复【指南】，可获得《阿里巴巴 DevOps 实践指南》&《10 倍研发效能提升案例集》；

看完觉得对您有所帮助别忘记点赞、收藏和关注呦；