• 《软件研发效能度量规范》的解读与实践(文末附有下载)


    前言

    由中关村智联软件服务业质量创新联盟、中国软件协会过程改进分会发起的软件研发效能度量规范》团体标准已于 TiD 2022 质量竞争力大会上发布。

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

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

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

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

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

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

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

    01 《软件研发效能度量规范》指标体系

    以下这张图是《规范》中定义的 E3CI 软件研发效能框架。

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

    而研发效能是需要度量获得认知(C),加上实践改进(I)从而实现的。

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

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

    以下这张指标模型图,可以从需求梳理和工具实现两个方面来解读。

    1.1 需求梳理

    从最上方的价值流到度量指标,是度量设计阶段的需求梳理过程。

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

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

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

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

    1.2 工具实现

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

    相比前面讲到的需求梳理过程,工具实现过程实际上是更加可复用的。

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

    02  标准指标的开源实现

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

    • 数据的汇集方面,需要处理每个数据源的并发、容错、调度等工作,设计多种数据拉取或推送方式,并设计原始数据到抽象数据的分层存储,以满足速度和可靠性两方面的要求。

    • 同类型的不同工具(例如 JIRA 和 TAPD)中的数据实体可能并不一致,如果组织内同时使用多款工具或切换工具,则需要建模,通过抽象、映射和关联来解决工具间一致性的问题。

    将数据抽象到研发过程各环节的领域模型

    • 为了数据查询/读取性能和管理便利,可能还需要聚合数据,存储在高关联性的仓库中。

    • 筛选出可信的数据集后,还需要提取出指标,并面向场景需求组合为数据看板,以满足分析与决策的信息需要。

    持续集成场景的数据看板

    03 总结

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

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

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

    欢迎各位读者朋友们点击下方文字下载呦!

    《软件研发效能度量规范》下载

  • 相关阅读:
    面试突击87:说一下 Spring 事务传播机制?
    Spring+CXF restful开发WebService
    重磅来袭!豆瓣评分9.9,万人血书的多线程与高并发v2.0版本
    Java发送邮件 启用SSL
    java计算机毕业设计济南旅游网站MyBatis+系统+LW文档+源码+调试部署
    JuiceFS 在多云存储架构中的应用 | 深势科技分享
    MyBatis笔记
    【开发篇】二十三、SpringBoot Admin端点指标控制以及自定义端点
    git rebase -i 详解
    学习笔记 谷粒02 Cloud
  • 原文地址:https://blog.csdn.net/simayi2018/article/details/127577676