草庐IT

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

云效DevOps 2023-03-28 原文

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

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

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

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

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

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

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

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

看交付速率

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

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


图片来源:云效效能洞察Insight

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

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

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

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

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

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

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

看响应能力

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

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

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


图片来源:云效效能洞察Insight

指标卡中数据含义:

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

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

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

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

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

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

 


图片来源:云效效能洞察Insight

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

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

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

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

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

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

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


图片来源:云效效能洞察Insight

指标卡中数据含义:

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

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

1. 团队的计划模式

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

2. 需求的转测模式

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

3. 需求的发布模式

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

看交付质量

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

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

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


图片来源:云效效能洞察Insight

指标卡中数据含义:

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

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

1. 看团队的交付模式

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

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

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

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


图片来源:云效效能洞察Insight

左半部分

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

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

右半部分

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

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


图片来源:云效效能洞察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

 

有关看懂这5幅图,研发效能分析和改进就容易了的更多相关文章

  1. ruby-on-rails - 我可以用鸭子类型(duck typing)改进这种方法吗? - 2

    希望我没有误解“ducktyping”的含义,但从我读到的内容来看,这意味着我应该根据对象如何响应方法而不是它是什么类型/类来编写代码。代码如下:defconvert_hash(hash)ifhash.keys.all?{|k|k.is_a?(Integer)}returnhashelsifhash.keys.all?{|k|k.is_a?(Property)}new_hash={}hash.each_pair{|k,v|new_hash[k.id]=v}returnnew_hashelseraise"CustomattributekeysshouldbeID'sorPropertyo

  2. 建模分析 | 平面2R机器人(二连杆)运动学与动力学建模(附Matlab仿真) - 2

    目录0专栏介绍1平面2R机器人概述2运动学建模2.1正运动学模型2.2逆运动学模型2.3机器人运动学仿真3动力学建模3.1计算动能3.2势能计算与动力学方程3.3动力学仿真0专栏介绍?附C++/Python/Matlab全套代码?课程设计、毕业设计、创新竞赛必备!详细介绍全局规划(图搜索、采样法、智能算法等);局部规划(DWA、APF等);曲线优化(贝塞尔曲线、B样条曲线等)。?详情:图解自动驾驶中的运动规划(MotionPlanning),附几十种规划算法1平面2R机器人概述如图1所示为本文的研究本体——平面2R机器人。对参数进行如下定义:机器人广义坐标

  3. 网站日志分析软件--让网站日志分析工作变得更简单 - 2

    网站的日志分析,是seo优化不可忽视的一门功课,但网站越大,每天产生的日志就越大,大站一天都可以产生几个G的网站日志,如果光靠肉眼去分析,那可能看到猴年马月都看不完,因此借助网站日志分析工具去分析网站日志,那将会使网站日志分析工作变得更简单。下面推荐两款网站日志分析软件。第一款:逆火网站日志分析器逆火网站日志分析器是一款功能全面的网站服务器日志分析软件。通过分析网站的日志文件,不仅能够精准的知道网站的访问量、网站的访问来源,网站的广告点击,访客的地区统计,搜索引擎关键字查询等,还能够一次性分析多个网站的日志文件,让你轻松管理网站。逆火网站日志分析器下载地址:https://pan.baidu.

  4. ABB-IRB-1200运动学分析MATLAB RVC工具分析+Simulink-Adams联合仿真 - 2

    一、机器人介绍        此处是基于MATLABRVC工具箱,对ABB-IRB-1200型号的微型机械臂进行正逆向运动学分析,并利Simulink工具实现对机械臂进行具有动力学参数的末端轨迹规划仿真,最后根据机械模型设计Simulink-Adams联合仿真。 图1.ABBIRB 1200尺寸参数示意图ABBIRB 1200提供的两种型号广泛适用于各作业,且两者间零部件通用,两种型号的工作范围分别为700 mm 和 900 mm,大有效负载分别为 7 kg 和5 kg。 IRB 1200 能够在狭小空间内能发挥其工作范围与性能优势,具有全新的设计、小型化的体积、高效的性能、易于集成、便捷的接

  5. 关于Qt程序打包后运行库依赖的常见问题分析及解决方法 - 2

    目录一.大致如下常见问题:(1)找不到程序所依赖的Qt库version`Qt_5'notfound(requiredby(2)CouldnotLoadtheQtplatformplugin"xcb"in""eventhoughitwasfound(3)打包到在不同的linux系统下,或者打包到高版本的相同系统下,运行程序时,直接提示段错误即segmentationfault,或者Illegalinstruction(coredumped)非法指令(4)ldd应用程序或者库,查看运行所依赖的库时,直接报段错误二.问题逐个分析,得出解决方法:(1)找不到程序所依赖的Qt库version`Qt_5'

  6. ruby-on-rails - 如何使用 ruby​​-prof 和 JMeter 分析 Rails - 2

    我想使用ruby​​-prof和JMeter分析Rails应用程序。我对分析特定Controller/操作/或模型方法的建议方法不感兴趣,我想分析完整堆栈,从上到下。所以我运行这样的东西:RAILS_ENV=productionruby-prof-fprof.outscript/server>/dev/null然后我在上面运行我的JMeter测试计划。然而,问题是使用CTRL+C或SIGKILL中断它也会在ruby​​-prof可以写入任何输出之前杀死它。如何在不中断ruby​​-prof的情况下停止mongrel服务器? 最佳答案

  7. 【Unity游戏破解】外挂原理分析 - 2

    文章目录认识unity打包目录结构游戏逆向流程Unity游戏攻击面可被攻击原因mono的打包建议方案锁血飞天无限金币攻击力翻倍以上统称内存挂透视自瞄压枪瞬移内购破解Unity游戏防御开发时注意数据安全接入第三方反作弊系统外挂检测思路狠人自爆实战查看目录结构用il2cppdumper例子2-森林whoishe后记认识unity打包目录结构dll一般很大,因为里面是所有的游戏功能编译成的二进制码游戏逆向流程开发人员代码被编译打包到GameAssembly.dll中使用il2ppDumper工具,并借助游戏名_Data\il2cpp_data\Metadata\global-metadata.dat

  8. 驱动开发:内核无痕隐藏自身分析 - 2

    在笔者前面有一篇文章《驱动开发:断链隐藏驱动程序自身》通过摘除驱动的链表实现了断链隐藏自身的目的,但此方法恢复时会触发PG会蓝屏,偶然间在网上找到了一个作者介绍的一种方法,觉得有必要详细分析一下他是如何实现的进程隐藏的,总体来说作者的思路是最终寻找到MiProcessLoaderEntry的入口地址,该函数的作用是将驱动信息加入链表和移除链表,运用这个函数即可动态处理驱动的添加和移除问题。MiProcessLoaderEntry(pDriverObject->DriverSection,1)添加MiProcessLoaderEntry(pDriverObject->DriverSection,

  9. ruby - 需要帮助改进 Ruby DSL 以控制 Arduino 控制的饮料分配器(bar monkey) - 2

    我正在用Ruby编写DSL来控制我正在处理的Arduino项目;巴尔迪诺。这是一只酒吧猴子,将由软件控制来提供饮料。Arduino通过串行端口接收命令,告诉Arduino要打开什么泵以及打开多长时间。它目前正在读取一个食谱(见下文)并将其打印出来。串行通信的代码以及我在下面提到的其他一些想法仍然需要改进。这是我的第一个DSL,我正在处理之前的示例,所以它的边缘非常粗糙。任何批评、代码改进(是否有任何关于RubyDSL最佳实践或习语的良好引用?)或任何一般性评论。我目前有DSL的粗略草稿,因此饮料配方如下所示(Githublink):desc"Simpleglassofwater"rec

  10. 2023爱分析·流程中台市场厂商评估报告:微宏科技 - 2

     目录1. 研究范围定义2. 流程中台市场分析3. 厂商评估:微宏科技4. 入选证书 1.   研究范围定义近年来,随着外部市场环境快速变化、客户需求愈发多样,企业逐渐意识到,自身业务需要更加敏捷、高效,具备根据市场需求快速迭代的能力。业务流程的自动化能够帮助企业实现业务的敏捷高效,因此受到越来越多企业的关注。企业的“自动化武器库”品类丰富,包括低/零代码平台、RPA、BPM、AI等。企业可以使用多项自动化工具,但结果往往是各项自动化工具处于各自的“自动化烟囱”之中,仅能实现碎片式自动化。例如,某企业的IT团队可能在使用低代码平台、财务团队可能在使用RPA、呼叫中心则可能在使用聊天机器人。自动

随机推荐