读书破万“卷”《软件研发效能度量规范》的先进认知与开源实现

读书破万“卷”《软件研发效能度量规范》的先进认知与开源实现

　　照相好的软件,好玩软件,看图纸的软件《规范》专家组由来自腾讯、京东、思码逸、横琴人寿、中国电科等企业的效能专家与行业知名顾问组成。华为、腾讯云、百度、京东、网易、思码逸、平安银行、光大银行、中兴、新华三等四十家企业参与共创。

　　《软件研发效能度量规范》因地制宜地建立了适合国内软件行业的研发效能度量框架和指标集，为软件研发团队的研发管理和改进提供依据，同时也为业界软件研发数据平台建设、数据交换和交流协作提供了理论基础。

　　专家组成员、思码逸创始人兼 CEO 任晶磊在 TiD 2022 会议上分享了《软件研发效能度量规范》的要点解读，并结合案例，讨论了相关研发效能指标的开源实现。

　　在经济环境收缩的大背景下，研发效能这个话题吸引了更多关注。今年年中，美团的内部会议总结了 2022 的三项关键命题，其中就包括了系统性降本增效，向更精益的管理要效益。

　　作为大量科技企业的成本中心的研发组织，其研发效能所受到的关注与期望无需再赘述。但用什么姿势去实践研发效能，才是科学有效的呢？争议最多的研发效能度量，又要如何推行呢？

　　对于这个问题，过去几年行业内有很多交流和探讨。本次发布的《软件研发效能度量规范》也正是基于四十家企业的真实实践和专家组成员的思考经验而得出。

　　通过梳理度量定义、制定度量框架、明确度量原则，提出度量方法等一系列工作，《软件研发效能度量规范》希望沉淀专业的研发效能领域知识，帮助研发团队实现读书破万“卷”——提升认知，避免用内卷等错误姿势，卷出研发效能反模式。

　　我们可以看到，研发效能（E3CI中的E）分为三个维度，分别是偏工程视角的效率，偏业务视角的效果、以及持续达成效率和效果的卓越能力。

　　度量所获取的认知，分为五个认知领域：交付的价值、速率、质量、成本及能力。《软件研发效能度量规范》根据认知域和软件研发环节，对常见度量指标进行了结构化的梳理。

　　然而，指标本身是静态、等待被调用的，指标本身的罗列并不能让研发团队了解如何使用它们。因此，《软件研发效能度量规范》还给出了软件研发效能度量的指标模型，指导研发效能度量平稳落地。

　　度量之所以存在，是为了满足业务价值流中的某些信息需要，这些信息的缺失导致我们无法做出可信的分析和决策。

　　而需求梳理环节所强调的，正是结合实际情况，清晰定义这些信息需要。团队的业务性质、阶段、战略重心等等属性不同，信息需要自然会有所差异。如果在还没理解为什么做度量的时候，就囫囵开启度量贪大求全，或生搬硬套他人的成功案例，难免使度量沦为鸡肋。

　　之前一次交流《理解研发效能度量 GQM 方法的精髓》中，茹炳晟老师也提到，很多公司是为了度量而度量，一上来就从指标出发，直接开始收集数据，而不是从自身具体且明确的目标出发，这是研发效能度量的一个常见坑点。

　　尽管不能完全重复前人的路线，但一些行业方法论能够起到指南针的作用，帮助研发团队全面、清晰地定义自身的度量需求。之前我们介绍过的GQM 方法，就是通过目标 - 问题 - 指标三个递进层次，带动研发团队层层拆解，思考怎样的度量指标体系才能真正满足需求。

　　从最下面的数据源到度量指标，则是工具实现的过程。数据源包括各种研发工具和手动录入的数据，其中都沉淀了大量研发数据。但由于数据体量大且分散、标准化程度低，无法直接使用。因此，需要将大量研发数据归集到数据湖中治理，提取出可信的数据集。

　　在研发效能实践中的常见误区之一，正是在非标的需求梳理环节偷懒，而在标准化的工具实现环节过于勤奋，重复造轮子。事实上，研发团队可以借助开源工具，低成本搭建研发效能度量工具。

　　前面提到度量工具需要实现数据汇集和治理工作，具体是什么呢？这里参考开源研发数据平台 Apache DevLake 的功能简单举例。

　　所谓研发效能度量，看起来只是从数据集中提取一个指标、一个数字。但放到指标模型中看，有效的研发效能度量，远不止一个数字这么简单。

　　如果您的团队正在推行研发效能度量，希望《软件研发效能度量规范》能够成为一本可靠的工具手册，帮助您的团队少踩坑。

　　同时，希望伴随着行业中的研发效能度量实践越发成熟，《软件研发效能度量规范》也能同步成长，不断充实，为行业持续注入有价值的知识和思考。如果您想了解更多关于研发效能度量的内容，欢迎下载《软件研发效能度量规范》

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

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