扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
摘要:当你把这 5 幅图看懂了,研发效能分析和改进就容易了。作为 CTO 或企业管理者,我们如何去了解和衡量研发团队的研发效能呢?作为 PMO 和效能负责人,我们该从哪几个维度来回答关于研发效能的问题呢?如何通过效能数据分析,帮助企业管理者透明化研发效能水平和变化趋势,分析效能问题根因、指导改进行动、衡量改进效果。
成都创新互联专业为企业提供赞皇网站建设、赞皇做网站、赞皇网站设计、赞皇网站制作等企业网站建设、网页设计与制作、赞皇企业网站模板建站服务,10年赞皇做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
作为 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
指标卡中数据含义:
需求交付分布,也叫需求控制图,横坐标为时间,纵坐标为需求交付周期(天),图中:
在看到「需求交付分布」的数据时,我们可以从 5 个方面进行理解和分析:
1、纵向上,交付需求的圆点越向下越好,反映出周期时间越短、响应能力越快,可预测性越好;
2、横向上,交付需求的圆点分布越密越好,反映出需求在频繁地交付,即发布频率越高;
3、横向上,交付需求的圆点分布越均匀越好,反映出需求在持续稳定地交付,更趋向于持续交付;如果圆点分布间断而交付集中,可反映出是批量地交付需求;
图片来源:云效效能洞察Insight
注:每个批量的间隔时间比较长(譬如2周或1个月以上),可采取减少需求进出的批量和增加发布窗口的措施。
4、交付周期线,代表在所选时间段内,交付周期的一个基本水位,该水位越低越好;
5、动均值折线,展示需求交付周期的变化趋势,期望是有往下走的趋势,代表团队的响应能力在持续地提升。
「需求交付分布」可以反映出团队是否已具备持续快速交付需求的能力,帮助团队回顾和分析队的效能情况,并根据历史效能情况,设定团队的效能目标。其次,对业务人员来说,可随时查看交付团队的效能情况,预测需求的上线时间。
「需求交付分布」是针对交付的结果进行度量,如果需要对整个交付过程进一步了分析,我们可以中点关注「需求累积流图」,可综合反映了前置时间(交付周期)、在制品数量、交付速率等指标,并体现了团队协作、计划和交付需求的模式,常用以发现系统性的改进机会,下面就对该图进行进一步介绍。
通过「需求累积流图」指标卡,我们可以:
图片来源:云效效能洞察Insight
指标卡中数据含义:
累积流图:横坐标为日期,纵坐标为各个阶段累积的需求数量;从左到右的每个阶段,都是需求按顺序变化的阶段,相应的,曲线对应的分别是这些阶段的累积完成的需求数量。
「需求累积流图」同时具备整体性和动态性,它既反映了团队整体的协作模式,端到端的动态交付过程,同时还反映了交付模式和交付能力的变化趋势。我们可以从累积流图中,分析团队的协作和交付模式,并发现改进机会。我们从下面 3 个方面进行分析:
1. 团队的计划模式
主要看需求进入开发阶段的数量和频率,如一个项目中,进入开发阶段的批量大,而且频次低(譬如每月一次),往往是大批量的输入,很容易出现大量需求并行,导致需求交付周期变短。反之,如果是小批量,多频次的输入,让在制品数量变低,缩短需求交付周期;
2. 需求的转测模式
需求大批量转测,带来的问题是,开发完成的需求,要等待较长时间才开始测试,导致更多在制品,并延长了需求交付周期;
3. 需求的发布模式
需求发布会出现阶梯状,阶梯的间隔越长,代表发布的频率越少,也就是每个发布的间隔时间比较长。同时也可以看出来,发布间隔越长,则每次发布需求的数量就越多,而发布的难度随着需求的增加而增加。
通过云效Insight效能分析报表中的「缺陷趋势」和「缺陷修复分布」指标卡,我们可以:
首先,我们来看一下「缺陷趋势」,如下图:
图片来源:云效效能洞察Insight
指标卡中数据含义:
缺陷趋势图:横坐标为日期,纵坐标为缺陷数量,横坐标上方红色柱子代表这一天发现缺陷数量;横坐标下方绿色柱子代表这一天解决的缺陷数量;橙色曲线代表缺陷存量。
在「缺陷趋势」指标卡中,我们可以分析:
1. 看团队的交付模式
如果长时间没发现缺陷,而到某一段时间集中新增大量缺陷,能够反映出是瀑布交付模式。如果缺陷被持续发现和持续解决,且存量缺陷处于较低水位,这种情况更容易形成持续交付模式。
2. 看存量缺陷的多少,判断交付质量
需求在上线前,一般需要把缺陷数量清零,如果项目的存量缺陷一直处于较低水位,反映出交付质量比较高。
举一个从小瀑布模式向持续交付模式转变的例子,如图:
图片来源:云效效能洞察Insight
左半部分
团队属于小瀑布的开发模式。前期,团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。越到后期发现的缺陷,修复难度大幅提升,修复成本大幅增加。
小瀑布模式下,过程质量差,带来大量的返工、延期和交付质量问题。该模式下,产品的交付时间依赖于何时缺陷能被充分移除,无法做到持续交付,也无法快速响应外部的需求和变化。并且,这一模式通常都导致后期的赶工,埋下交付质量隐患。
右半部分
团队开始向持续交付模式演进,质量得到控制。在整个迭代过程中,团队以小粒度的需求为单位开发,持续地集成和测试它们,即时发现和解决问题。缺陷库存得到控制,系统始终处于接近可发布状态。这一模式更接近持续发布状态,团队对外的响应能力随之增强。
接下来我们来看「缺陷修复分布」:
图片来源:云效效能洞察Insight
指标卡中数据含义:
缺陷修复分布,也叫缺陷控制图,横坐标为时间,纵坐标为缺陷修复周期(天),图中:
在看到「缺陷修复分布」图的数据时,我们可以从 4 个方面理解和分析:
缺陷修复分布图,对于团队来说,可用于在回顾会上分析团队过去的质量情况,也可根据历史的情况,来设定团队的缺陷修复目标。
我们可以从产能、效率和质量 3 个维度来观测团队的研发效能现状,并进行针对性分析,重点观测 5 幅图:
如果需要更多数据进行分析,也可以参考:需交付时长按阶段分布、 需求累积流图、存量缺陷按成员排名、存量缺陷占比等。
不管在阿里内部,还是我们接触的大部分客户,大家通常以缩短需求交付周期为目标。阿里提出的“ 211” 目标中,第一个 2 就是要把需求交付周期缩短到到两周。
如果你想要体验云效Insight 的敏捷项目度量场景报表,点击下方链接,前往云效Insight 即可「免费试用」。
https://www.aliyun.com/product/yunxiao/insight?channel=yy_yc
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流