看懂这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

相关文章
|
新零售 测试技术 持续交付
阿里如何定义团队的研发效能?
作者:何勉,阿里巴巴研发效能部资深技术专家 相关阅读:都996了,研发效能还是提不起来,关键在这里 因为身处研发效能部,我接触了公司很多产品技术团队。他们几乎都把研发效能提升列为了本财年的重要目标,大部分还为此成立专项。
18509 0
阿里如何定义团队的研发效能?
|
3月前
|
开发框架 运维 Cloud Native
核心系统转型问题之提升研发效能和保障研发质量如何解决
核心系统转型问题之提升研发效能和保障研发质量如何解决
|
搜索推荐 测试技术
持续提高软件研发团队效能
提高软件研发团队效能是一个持续的过程,想要快速提高效能的实践几乎都是以失败告终。
170 0
|
6月前
也谈研发效能
也谈研发效能
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
4271 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
Cloud Native 前端开发 IDE
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
本文作者将给大家提供一些简单的容易实操的方法,能够让所有人都知道什么是效能的提升,如何提升个人的效能,如何提升团队的效能。
1628 9
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
|
Java 中间件 测试技术
研发效能的思考总结
很多时候,我们一直在思考如何高效支撑业务这个课题上。阿里技术分享平台或者网上都有非常多的文章分享,每个TL针对自己团队的状况也有一套自己的方法论。本文作者将结合自己所面临的状况,把自己的思考总结分享给大家。
研发效能的思考总结
|
运维 Cloud Native 数据可视化
2018-2021,60+篇阿里研发效能提升干货,都在这里了
今天,正值2021的最后1天,我们精心盘点了2018-2021连续3年来,云效团队在研发效能提升方面输出的所有干货,希望对大家有所帮助。
4912 3
2018-2021,60+篇阿里研发效能提升干货,都在这里了
|
机器学习/深度学习 人工智能 算法
解密蚂蚁研发效能:如何用数据驱动效能提升?
本文整理自蚂蚁金服解决方案架构师添棋在「中国DevOps社区杭州第3届Meetup」上的分享《研发洞察:如何用数据驱动效能提升》,将围绕决策辅助和研发辅助两个方向,详细讲解在蚂蚁金服内部如何基于AI、数据技术,洞察研发效率,提供面向一线研发和团队TL的提效解决方案
1062 0
解密蚂蚁研发效能:如何用数据驱动效能提升?
|
存储 监控 前端开发
深入前端研发效能治理:数据化运营思路及其实践
数据中台前端研发无不让人厚重真实地感受到“唯一不变的是变化”。拿集团的数据资产服务平台来说,业务上经过两年的发展,已由单一的数据管理和使用平台发展成了集团具有一定规模和影响力的全域数据要素交易所,而从前端技术侧,仅从代码提交报表就能明显看到,今年的代码提交量平均是去年的 2-3 倍,可见其业务扩张速度之快。
深入前端研发效能治理:数据化运营思路及其实践
下一篇
无影云桌面