13518219792
摘要：当你把这 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
