研发效能度量指标构成及效能度量方法论

本文主要内容目录:1、研发效能度量指标体系定义及价值2、研发效能度量指标体系的设计原则、思路与建议3、研发效能度量指标体系设计的误区

本文共计2933字,建议阅读时间:6-7分钟。


本文主要内容目录:

1、研发效能度量指标体系定义及价值

2、研发效能度量指标体系的设计原则、思路与建议

3、研发效能度量指标体系设计的误区


作者简介

熊玉辉,10余年互联网测试开发与质量管理经验。曾就职于腾讯,带领团队进行Devpos实践,致力于工程效能提升。在移动端自动化测试、工具平台建设、研发效能度量等有非常丰富的经验,多次在MTSC、TICA等行业大会上进行专题分享。2020年加入快手,现任快手多媒体质效中心快影质量负责人,负责团队质量与研发效能度量建设,旨在通过合理的效能度量驱动研发效能提升


本文来源:转载熊玉辉老师的研发效能系列文章,本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南

01. 研发效能度量指标体系概述

研发效能度量指标体系,是指一系列可量化研发效能水平的指标集合。 在实际的研发效能度量活动中,需要使用多个指标从不同维度来综合评估与分析。简单来说,指标体系包括两个方面:

●指标:一般包括结果指标和过程性指标;结果指标是指最终反映研发效能状态的指标,过程性指标是指与研发过程息息相关,对最终研发效能产生重要影响的指标。您需要对指标进行定义,并给出计算方法

●体系:围绕研发效能度量目标,对指标进行系统化、结构化的梳理,避免针对单一维度进行度量与分析评估您可以将研发效能度量指标体系,用于任何软件研发团队的效能度量与改进活动中,包括:

移动终端App

●传统PC软件

●Web应用

●小程序

●基于硬件驱动的软件研发

02. 研发效能度量指标体系的价值

一套合理、优秀的指标体系,可以帮助您的团队:

●借助客观的结果度量数据,使研发产出更加直观

●找到痛点,推动研发流程改进,并衡量改进的效果

●引导研发团队做真正能解决问题的行为,而不是为了追求“数据”上的“好看”

03. 研发效能度量指标体系的设计

为了帮助您的团队能够更客观、有效的度量研发效能,请参考以下建议设计研发效能度量指标体系:

(1)指标设计原则:

●全局最优,而不是局部最优

●指标服务于度量目标: O-KR-指标定义(逐步拆解)

●指标不反映问题,那就没必要设计这个指标

●分层级设计,从三个层面逐层设计:结果(高层关注)<-过程(中层关注)<-操作(一线人员)a结果指标:用于衡量团队研发效能水平b过程指标:用于分析与发现效能改进点c操作指标:指导一线团队如何正确提升效能

(2)指标设计思路与建议:

以“更高效、更高质量、更可靠、可持续地交付更优的业务价值”作为研发效能改进的核心目标来说,研发效能指标体系一般分为3个维度:价值、质量与速度,整体图示如下:

图1:研发效能指标体系架构图

●价值:

研发交付价值应该是需求背后的客户/公司战略价值(1)。对于研发侧而言,假设产品/业务提出的需求是具备充分的客户价值,且经过了准确的优先级分析,那么“需求量”+“业务满意度”基本可以代表“交付价值”,价值指标则可以设计如下:


●质量:

研发交付质量,应该是指用户感受到的质量,但交付过程质量会对交付质量产生影响。 质量的指标建议参照以下方法来设计:

○交付质量:


○交付过程质量:

在设计交付过程质量指标时,常规设计思路是根据研发阶段“需求-开发&测试-发布”来组织,建议可以从以下指标中进行选取:

除以上会影响交付质量的过程指标外,一些公司也希望针对“开发工程师”、“测试工程师”等各个角色的产出质量进行度量,比如“需求提测通过率”、“线上缺陷漏测率”等等。此处将“产出质量”作为交付过程质量的补充,定义如下:

需要注意的是:这些产出质量指标统计存在很大主观因素影响。比如,需求提测通过率中,“提测通过”的判定并没有统一的标准,实践中经常以“测试提供的Case”通过率来计算,统计结果严重依赖测试提供的Case范围,且每个测试工程师圈定标准也存在较大差异。

因此,对于产出质量指标,本指南建议仅在度量分析时做参考使用,不应该作为单一维度指标来进行衡量和考核

●速度(效率):

研发交付速度指标,则是用来体现“持续“与“快速”的,即单位价值的交付时长越短,交付速度越快。从结果与过程两个方向来拆分,指标设计建议如下:


●操作指标:上面针对与效能相关的结果与过程指标做了详细介绍。三层体系中的操作指标,因与各个团队所采取的研发模式、基础平台建设成熟度,以及组织模式有很大相关性,本指南不做详细阐述,但操作层面的效率与质量,最终影响的是过程与结果指标。这里将业界常见的操作指标简单列出,供大家参考:

●持续集成成熟度相关:编译与构建时长/稳定性、部署时长/稳定性等等

●自动化测试相关:1)代码全量/增量自动化覆盖率。从自动化类型可区分单元测试、接口测试、验收测试等;从覆盖率计算角度,可分为行覆盖率、分支覆盖率、条件覆盖率等 2)自动化稳定性与拦截Bug能力等

●代码质量相关:代码可维护性(重复率、圈复杂度、注释率与可读性等)、代码依赖与制品规范等

●开发效率相关:本地编译时长、服务启动时长等等

●部署与架构相关:容灾能力、监控能力、故障自愈能力、资源调度能力等等3. 案例研究:国内某互联网大厂的研发效能指标体系


图2:某互联网大厂研发效能指标体系图如上图所示,该研发效能度量体系分为12个维度方向超过100个指标,指标体系有以下特点:

●从设计思路上:它遵循持续交付的理念,对组织管理机制、软件系统架构与软件基础设施建设三个方面进行度量,针对需求、代码、环境、制品等提出了详细的研发效能度量指标,改进对象包括产品团队、开发团队、测试团队以及运维团队。

●它的优势是:覆盖维度特别广,几乎涵盖了软件研发的各个层面,可以全方位推动研发底层能力的改革;此外不仅对最终结果指标有要求,同时也聚焦一线操作层面,可用于指导一线人员实践。

●它的不足有:

a、部分维度指标选择不合理,如自动化测试维度追求代码覆盖率,但未综合考虑自动化拦截问题的能力。所以在实践上可能会出现“为了追求覆盖率,对非活跃但很好写测试Case的代码进行了自动化补充“、“代码覆盖率很高但实际拦截问题很弱的自动化手段”这样违背初衷的情况

b、指标太多且层次不明显,结果指标、过程指标与操作指标没有很好的区分。在实际执行过程中容易形成过于关注“操作层面达标”,而忽视了“结果指标”。因为操作指标达标并不代表团队研发效能水平达标,前者并非后者的充分条件,也因此容易引发各角色之间的相互“甩锅”当然,根据业务效能所处的阶段,应该持续对研发效能指标体系进行更新,这一点也是本指南推荐大家参考的。

04. 研发效能度量指标体系设计的误区

关于研发效能度量指标体系的设计,一般情况下存在以下误区:

1、交付价值==需求数。

需求数越多交付价值就越多吗?因为需求有大小,拆分标准也不一定一致,所以需求数越多不代表交付价值越多

2、交付质量==缺陷密度——缺陷数/案例数、缺陷数/需求数、千行Bug率等都不适合用来度量交付质量。原因如下:

a、“案例”与“需求”的数量都依赖于拆分粒度,拆分粒度没有统一标准,依赖具体拆分执行的人。在实际度量中,很容易出现“粉饰”指标的现象

b、代码重复度、代码圈复杂度、架构设计是否合理等能更客观衡量代码质量的,并不能通过这一类指标体现出来。千行Bug率还有一个很经典的反例:同样的功能,同样的Bug数,代码写的更长的开发者千行Bug率更低。

3、交付价值,不建议使用 Average“均值”计算方式,建议使用中位数或分位数,如P50、P90等等。对于平均值,只需有一个点无穷大,均值就会无穷大量,从而使得均值失真,失去了度量的意义。以常见的效率过程指标“缺陷修复时长“为例:假设有100个缺陷,前99个各花费1小时,修复最后1个花了99个小时,那么平均时长就是1.98小时。平均值是99%的Bug修复时长的1.98倍,很显然产生了失真。请注意:如果研发效能度量指标的量化结果,跟大部分人主观感受不一致的话,就需要考虑下指标设计与定义是否合理了。


——结束——


如果您想了解更多关于研发效能的内容,可查看思码逸网站获取;

思码逸 Merico 研发效能数据分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在思码逸网站留下联系方式,我们将在24小时内回复。或拨打电话400-863-7426:

与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消