共计 2714 个字符，预计需要花费 7 分钟才能阅读完成。
云效研发效力度量体系，如何展现和解读交付效力数据，一个迭代或者一个周期完结后，团队须要回顾复盘驱动效力改良，在回顾复盘前须要展现团队以后的效力数据。通过研发效力度量来度量团队是否具备了交付价值的能力。
作者：舍卫|阿里巴巴团体技术专家
阿里巴巴研发效力度量体系（如下图），通过五个维度来度量团队是否具备了「顺畅、高质量交付价值的能力」，包含需要响应周期、继续公布能力、交付吞吐率、交付过程品质和交付品质，期待能又快又多又好地交付需要。
1. 需要响应周期
具体蕴含两个细分的指标，别离是：
- 交付周期：指的是从确认用户提出的需要开始，到需要上线所经验的均匀时长。它反映团队（蕴含业务、开发、经营等职能）对客户问题或业务机会的响应速度；
- 开发周期：指的是从开发团队了解需要开始，到需要能够上线所经验的均匀时长。它反映技术团队的响应能力。
辨别交付周期和开发周期，是为理解耦并明确问题，以做出针对性的改良。其中，交付周期是最终的指标和测验规范。
需要累计流图
云效有丰盛的报表统计性能，接下来，我将率领大家一起来学习如何在云效上配置下面的报表。
如下图所示，从「统计」进入，点击「新建报表」，能够看到云效的新建报表列表。
阐明
立刻体验：云效项目管理
抉择「效力剖析」，而后点击「需要累计流图」呈现如下图所示的报表：
每一个蓝色的点代表一个曾经公布的需要，横轴是日期，纵轴是天数。这些蓝色的点越朝下越好，代表需要的交付工夫越短，响应力也越好；散点的密度越高代表交付频率越高，散点横向上更均匀分布代表继续交付的稳定性越好。
交付周期趋势图
抉择「效力剖析」，而后点击「交付周期报表」
如下图，抉择按月统计，工作抉择「需要」，开始状态选「已抉择」，完结状态选「已公布」，更新左上角的图表名称为「交付周期趋势图」后保留，即可展示
开发周期趋势图
抉择「效力剖析」，而后点击「交付周期报表」
如下图，抉择按周统计，工作抉择「需要」，开始状态选「就绪（待开发）」，完结状态选「待发布」，更新左上角的图表名称为「开发周期趋势图」后保留，即可展示。
下图是开发周期趋势图示例，横轴是工夫，依照天然周排列，纵轴是需要个数。每个柱子代表的是当周已到待发布状态需要的数量，各柱子由不同的色彩沉积而成，蓝色代表需要的开发周期时长小于 1 周，绿色代表需要的开发周期时长在 1 - 2 周之间，橙色代表需要的开发周期时长在 2 - 4 周之间，红色代表需要的开发周期时长大于 4 周。
从上图能够看出，需要开发周期在 1 周内的需要数量在持续增长，同时一周内的占比也在逐渐晋升，因为该数据是在 8 月 15 日取的，所以最初一周的数据还不全。
2. 继续公布能力
具体蕴含两个细分指标，别离是：
•公布频率：团队对外响应的速度不会大于其交付频率，公布频率束缚团队对外响应和价值的流动速度。它的衡量标准是单位工夫内的无效公布次数。
•公布前置工夫（也被称为变更前置工夫）：也就是从代码提交到性能上线破费的工夫，它体现了团队公布的根本能力。如果工夫开销很大，就不适合加大发版频率
公布频率
从需要管制图上能够看出继续公布能力的变动，如果需要散点的密度越高，则交付频率越高，反之则越低。
公布前置工夫
公布前置工夫，与团队的工程能力有很大的关系，这和云效新品代码平台和流水线强相干，这里暂不做解说。
3. 交付吞吐率
指的是单位工夫内交付需要的数量。对于这一点，常见的问题是，个数能精确反映交付效率吗？这是个问题。所以，咱们更多强调单个团队的需要吞吐率的前后比照，统计意义上它足以反映趋势和问题。
需要吞吐率趋势图（按周）
在 需要响应周期的图表 中，需要吞吐率的趋势也已出现，下图中纵轴代表这一周公布需要的数量，所以柱子越高代表这一周交付的需要越多。
这里吞吐率的计算是依照需要的数量来统计的，在需要颗粒度大小差异很大的时候，吞吐率数据会呈现偏差，所以在统计这个之前，期待团队能对需要进行拆分，拆分到工作量在 2 周之内。
需要吞吐率趋势图（按迭代）
在自定义图表中抉择按迭代和工作状态，而后增加两个筛选条件：迭代和状态。迭代抉择须要比拟的几个迭代，状态只选已公布的需要。呈现如下依照迭代进行比拟的吞吐率趋势图。
4. 交付过程品质
它蕴含两个细分的指标，别离是：
•开发过程中缺点的创立和修复工夫散布：咱们心愿缺点可能继续和及时地被发现，并且在发现后尽快修复；
•缺点库存：咱们心愿在整个开发过程中管制缺点库存量，让产品始终处于靠近可公布状态，奠定继续交付的根底。
交付过程品质的外围是内建品质，也就是全过程和全时段的品质。而非依赖特定的阶段，如测试阶段；或特定的时段，如我的项目前期。内建品质是继续交付的根底，对于其具体度量办法，下文会给出具体实例。
缺点趋势图
如上图所示，图中的横坐标是日期，横坐标上方红色竖条代表这一天发现缺点数量；横坐标下方绿色竖条代表当天解决的缺点数量；橙色曲线代表缺点存量。图中左右两个局部比拟了两种交付模式。
左半局部，团队属于小瀑布的开发模式。“迭代”后期，团队集中设计、编码，引入缺点，但并未即时地集成和验证。缺点始终掩藏在零碎中，直到我的项目前期，团队才开始集成和测试，缺点集中暴发。
小瀑布模式下，过程品质差，带来大量的返工、延期和交付品质问题。该模式下，产品的交付工夫依赖于何时缺点能被充沛移除，当然不能做到继续交付，也无奈疾速响应内部的需要和变动。并且，这一模式通常都导致前期的赶工，埋下交付品质隐患。
右半局部，团队开始向继续交付模式演进。在整个迭代过程中，团队以小粒度的需要为单位开发，继续地集成和测试它们，即时发现和解决问题。缺点库存失去管制，零碎始终处于靠近可公布状态。这一模式更靠近继续公布状态，团队对外的响应能力随之加强。
缺点趋势图从一个侧面反映了团队的开发和交付模式。它疏导团队继续且尽早发现缺点并及时移除它们。管制缺点库存，让零碎始终处于靠近可公布状态，保障了继续交付能力和对外响应能力。
在我的项目「统计」中，抉择「缺点剖析」，而后点击「缺点变化趋势」呈现如下图所示。
5. 对外交付品质
它蕴含两个细分的指标，别离是：
单位工夫的故障（线上问题）数；
故障均匀解决时长
这两者独特决定了零碎的可用性。
加餐：理解研发效力度量详情，欢送学习阿里巴巴研发效力晋升 36 计第 4 课 - 设置北极星指标，数据驱动效力改良
小结
阿里巴巴研发效力度量体系，通过五个维度来度量团队是否具备了「顺畅、高质量交付价值的能力」，通过以上五组指标，从流动效率、资源效率和品质三个方面讲述了一个残缺的故事，答复了目前组织继续交付价值的能力如何这个外围问题。其中，继续公布能力和需要响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程品质和对外交付品质这两组指标独特反映品质程度。
