看懂这5幅图,研发效能分析和改进就容易了

简介: 作为 CTO 或企业管理者,我们如何去了解和衡量研发团队的研发效能呢?作为 PMO 和效能负责人,我们该从哪几个维度来回答关于研发效能的问题呢?如何通过效能数据分析,帮助企业管理者透明化研发效能水平和变化趋势,分析效能问题根因、指导改进行动、衡量改进效果。

作为 CTO 或企业管理者,我们如何去了解和衡量研发团队的研发效能呢?

作为 PMO 和效能负责人,我们该从哪几个维度来回答关于研发效能的问题呢?

带着这两个问题,我们进入到研发效能分析的场景,聊一聊我们如何通过效能数据分析,帮助企业管理者透明化研发效能水平和变化趋势,分析效能问题根因、指导改进行动、衡量改进效果。

注:以下内容分为视频版和文字版,读者可自选学习。

观看地址:https://v.qq.com/x/page/j3324np3qir.html

在云效效能洞察 Insight 中,我们可以从 3 个维度衡量和分析团队的研发效能:

  • 看交付速率:单位时间内,团队能够交付多少需求,即需求交付的吞吐量;
  • 看响应能力:需求从提出到交付上线的时间长短,即需求交付周期;
  • 看交付质量:交付过程中缺陷发现和修复的及时性,以及缺陷数量的多少。

看交付速率

在云效Insight的效能分析场景报表,通过「需求交付速率」指标卡,我们可以:

  • 看到在单位时间内的需求交付量,及所选时间段内平均单位时间需求交付量;
  • 看到需求交付速率趋势,根据近期交付量来合理安排团队将来的交付节奏和对外的承诺。

image.png
图片来源:云效效能洞察Insight

需求交付速率:横坐标为时间,以周为单位,纵坐标是需求的数量(个),柱子高低代表一周交付需求数量的多少,柱子的颜色分布分别对应交付周期的长短分布。

注:按需求个数统计的方式,因需求大小不一致会出现一些统计偏差,因此期望做需求交付统计时能够将需求粒度拆分的相对较小且均匀。

「需求交付速率」指标卡中,我们可以深入分析:

1. 根据团队交付速率,评估团队交付能力

我们可以根据团队近期的交付速率,预测团队将来的交付速率,以便更好地安排团队未来可接纳需求的工作量。比如最近 6 周,每周交付需求数量为 10,12,15,13,11,17,平均值为 13,我们可以预测团队每周可交付需求数量在 13 个左右,当我们知道这个数据时,可以更好的安排需求交付的节奏和时间,并对外部承诺。

2. 通过观测发布频率,推进团队持续交付

如果每周都有柱子,说明每周都有发布,如果柱子有间隔性,即每两周有一个柱子,说明是两周一次发布,以此类推。

看响应能力

通过云效Insight效能分析报表中的「需求交付分布」「需求累积流图」指标卡,我们可以看响应能力。

首先,在「需求交付分布」指标卡中,我们可以:

  • 看到各需求上线时间的分布情况,反映团队的需求发布频率;
  • 看到需求交付周期的趋势,反映团队对需求响应能力及变化趋势;
  • 通过历史数据分析,预测将来的响应能力。

image.png
图片来源:云效效能洞察Insight

指标卡中数据含义:

需求交付分布,也叫需求控制图,横坐标为时间,纵坐标为需求交付周期(天),图中:

  • 圆点:代表一个已交付的需求,它所在的横坐标为交付时间,纵坐标为该需求交付时长;
  • 折线:代表需求交付周期的滚动均值,取该点以及前后各1/3/5/7/9 点(随区间事项数变动)的平均值;
  • 面积:蓝色阴影区域代表滚动标准差,即实际数据与滚动平均值的偏差量;
  • 横线:所选时间区间内,需求交付周期的平均值。

在看到「需求交付分布」的数据时,我们可以从 5 个方面进行理解和分析:

1、纵向上,交付需求的圆点越向下越好,反映出周期时间越短、响应能力越快,可预测性越好;

2、横向上,交付需求的圆点分布越密越好,反映出需求在频繁地交付,即发布频率越高;

3、横向上,交付需求的圆点分布越均匀越好,反映出需求在持续稳定地交付,更趋向于持续交付;如果圆点分布间断而交付集中,可反映出是批量地交付需求;

image.png
图片来源:云效效能洞察Insight

注:每个批量的间隔时间比较长(譬如2周或1个月以上),可采取减少需求进出的批量和增加发布窗口的措施。

4、交付周期线,代表在所选时间段内,交付周期的一个基本水位,该水位越低越好;

5、动均值折线,展示需求交付周期的变化趋势,期望是有往下走的趋势,代表团队的响应能力在持续地提升。

「需求交付分布」可以反映出团队是否已具备持续快速交付需求的能力,帮助团队回顾和分析队的效能情况,并根据历史效能情况,设定团队的效能目标。其次,对业务人员来说,可随时查看交付团队的效能情况,预测需求的上线时间。

「需求交付分布」是针对交付的结果进行度量,如果需要对整个交付过程进一步了分析,我们可以中点关注「需求累积流图」,可综合反映了前置时间(交付周期)、在制品数量、交付速率等指标,并体现了团队协作、计划和交付需求的模式,常用以发现系统性的改进机会,下面就对该图进行进一步介绍。

通过「需求累积流图」指标卡,我们可以:

  • 看平均交付周期:需求在各阶段的停留时长之和,指需求交付之前,从开始到结束所经历的时间;
  • 看在制品数量:需求在各阶段的停留数量,可以反应出处理需求批量大小和并行度情况;
  • 看交付速率:发布阶段曲线的整体斜率,可以反应出团队的需求交付速率。

image.png
图片来源:云效效能洞察Insight

指标卡中数据含义:

累积流图:横坐标为日期,纵坐标为各个阶段累积的需求数量;从左到右的每个阶段,都是需求按顺序变化的阶段,相应的,曲线对应的分别是这些阶段的累积完成的需求数量。

「需求累积流图」同时具备整体性和动态性,它既反映了团队整体的协作模式,端到端的动态交付过程,同时还反映了交付模式和交付能力的变化趋势。我们可以从累积流图中,分析团队的协作和交付模式,并发现改进机会。我们从下面 3 个方面进行分析:

1. 团队的计划模式

主要看需求进入开发阶段的数量和频率,如一个项目中,进入开发阶段的批量大,而且频次低(譬如每月一次),往往是大批量的输入,很容易出现大量需求并行,导致需求交付周期变短。反之,如果是小批量,多频次的输入,让在制品数量变低,缩短需求交付周期;

2. 需求的转测模式

需求大批量转测,带来的问题是,开发完成的需求,要等待较长时间才开始测试,导致更多在制品,并延长了需求交付周期;

3. 需求的发布模式

需求发布会出现阶梯状,阶梯的间隔越长,代表发布的频率越少,也就是每个发布的间隔时间比较长。同时也可以看出来,发布间隔越长,则每次发布需求的数量就越多,而发布的难度随着需求的增加而增加。

看交付质量

通过云效Insight效能分析报表中的「缺陷趋势」和「缺陷修复分布」指标卡,我们可以:

  • 看到缺陷被发现和修复的趋势,反映团队的交付模式;
  • 看到存量缺陷的变化趋势,发现与修复分布是否趋于合理,反映项目的质量状况;
  • 看到缺陷修复周期的变化趋势,反映团队对缺陷的及时修复能力。

首先,我们来看一下「缺陷趋势」,如下图:

image.png
图片来源:云效效能洞察Insight

指标卡中数据含义:

缺陷趋势图:横坐标为日期,纵坐标为缺陷数量,横坐标上方红色柱子代表这一天发现缺陷数量;横坐标下方绿色柱子代表这一天解决的缺陷数量;橙色曲线代表缺陷存量。

「缺陷趋势」指标卡中,我们可以分析:

1. 看团队的交付模式

如果长时间没发现缺陷,而到某一段时间集中新增大量缺陷,能够反映出是瀑布交付模式。如果缺陷被持续发现和持续解决,且存量缺陷处于较低水位,这种情况更容易形成持续交付模式。

2. 看存量缺陷的多少,判断交付质量

需求在上线前,一般需要把缺陷数量清零,如果项目的存量缺陷一直处于较低水位,反映出交付质量比较高。

举一个从小瀑布模式向持续交付模式转变的例子,如图:

image.png
图片来源:云效效能洞察Insight

左半部分

团队属于小瀑布的开发模式。前期,团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。越到后期发现的缺陷,修复难度大幅提升,修复成本大幅增加。

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

右半部分

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

接下来我们来看「缺陷修复分布」

image.png
图片来源:云效效能洞察Insight

指标卡中数据含义:

缺陷修复分布,也叫缺陷控制图,横坐标为时间,纵坐标为缺陷修复周期(天),图中:

  • 圆点:代表一个已修复的缺陷,它所在的横坐标为修复时间,纵坐标为该缺陷的修复时长;
  • 折线:代表缺陷修复周期的滚动均值,取该点以及前后各1/3/5/7/9个点(随区间事项数变动)的平均值;
  • 面积:红色阴影区域代表滚动标准差,即实际数据与滚动平均值的变偏差量;
  • 横线:所选时间区间内,缺陷修复周期的平均值。

在看到「缺陷修复分布」图的数据时,我们可以从 4 个方面理解和分析:

  1. 纵向上,代表已修复缺陷的圆点越向下越好,反映出修复周期越短、修复能力越快;
  2. 横向上,代表已修复缺陷的圆点数量越少越好,越少代表缺陷的数量越少,开发提测的质量比较高;
  3. 平均修复时长线,代表团队缺陷修复周期的一个基本水位,越低越好。很多团队会设定缺陷修复目标,譬如缺陷要日清,即缺陷要在发现后的 24 小时内修复;
  4. 滚动均值折线,展示缺陷修复周期的变化趋势,期望有往下走的趋势,代表团队修复缺陷的速度越来越快。

缺陷修复分布图,对于团队来说,可用于在回顾会上分析团队过去的质量情况,也可根据历史的情况,来设定团队的缺陷修复目标。

整体回顾

我们可以从产能、效率和质量 3 个维度来观测团队的研发效能现状,并进行针对性分析,重点观测 5 幅图:

  • 需求交付速率:反应团队历史的需求交付吞吐量,可对未来的交付产能进行预测;
  • 需求交付分布:反应团队历史的需求响应能力,可对未来的需求交付速度进行预测;
  • 需求累积流图:反应团队整体的协作模式,可分析团队的交付模式和交付能力;
  • 缺陷趋势图:反应团队历史的过程质量情况,可分析团队的交付模式和质量状况;
  • 缺陷修复分布:反应团队历史的缺陷修复速度,可对团队的缺陷修复速度进行预测。

如果需要更多数据进行分析,也可以参考:需交付时长按阶段分布、 需求累积流图、存量缺陷按成员排名、存量缺陷占比等。

不管在阿里内部,还是我们接触的大部分客户,大家通常以缩短需求交付周期为目标。阿里提出的“ 211” 目标中,第一个 2 就是要把需求交付周期缩短到到两周。


如果你想要体验云效Insight 的敏捷项目度量场景报表,点击下方链接,前往云效Insight 即可「免费试用」

https://www.aliyun.com/product/yunxiao/insight?channel=yy_yc

image.png

相关文章
|
3月前
|
开发框架 运维 Cloud Native
核心系统转型问题之提升研发效能和保障研发质量如何解决
核心系统转型问题之提升研发效能和保障研发质量如何解决
|
4月前
|
运维 算法 测试技术
通用研发提效问题之实现研发提效,如何解决
通用研发提效问题之实现研发提效,如何解决
|
搜索推荐 测试技术
持续提高软件研发团队效能
提高软件研发团队效能是一个持续的过程,想要快速提高效能的实践几乎都是以失败告终。
172 0
|
6月前
也谈研发效能
也谈研发效能
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
4288 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
Cloud Native 前端开发 IDE
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
本文作者将给大家提供一些简单的容易实操的方法,能够让所有人都知道什么是效能的提升,如何提升个人的效能,如何提升团队的效能。
1638 11
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
优秀度量与实践应该什么样?|2022阿里云研发效能峰会
随着数字化转型深化,研发效能管理成为热门话题。2022阿里云研发效能峰会·研发效能度量与实践专场希望通过理念和案例碰撞,让更多企业在效能课题上建立起科学认知。
168 0
优秀度量与实践应该什么样?|2022阿里云研发效能峰会
|
Java 中间件 测试技术
研发效能的思考总结
很多时候,我们一直在思考如何高效支撑业务这个课题上。阿里技术分享平台或者网上都有非常多的文章分享,每个TL针对自己团队的状况也有一套自己的方法论。本文作者将结合自己所面临的状况,把自己的思考总结分享给大家。
研发效能的思考总结
|
运维 Cloud Native 数据可视化
2018-2021,60+篇阿里研发效能提升干货,都在这里了
今天,正值2021的最后1天,我们精心盘点了2018-2021连续3年来,云效团队在研发效能提升方面输出的所有干货,希望对大家有所帮助。
4927 3
2018-2021,60+篇阿里研发效能提升干货,都在这里了
|
机器学习/深度学习 人工智能 算法
解密蚂蚁研发效能:如何用数据驱动效能提升?
本文整理自蚂蚁金服解决方案架构师添棋在「中国DevOps社区杭州第3届Meetup」上的分享《研发洞察:如何用数据驱动效能提升》,将围绕决策辅助和研发辅助两个方向,详细讲解在蚂蚁金服内部如何基于AI、数据技术,洞察研发效率,提供面向一线研发和团队TL的提效解决方案
1076 0
解密蚂蚁研发效能:如何用数据驱动效能提升?
下一篇
无影云桌面