研发效能实践之打造高效能团队

思码逸研发效能

于 2024-12-31 11:19:26 发布

阅读量645 大数据研发效能人工智能效能度量 devops

本文链接：https://blog.csdn.net/simayi2018/article/details/144845767

本次分享一共包含四个板块的内容，首先会给大家介绍下思码逸在研发效能领域这几年做的一些探索工作和心得体会，然后对思码逸帮助客户搭建研发效能度量分析平台的过程做一些简单介绍，另外也从在前段时间刚刚结束的“研发效能行业基准调研活动”的报告里提取了一些高效能团队的特征结合一个实际客户的案例跟大家做一次分享交流。

思码逸在研发效能领域的经验探索

思码逸在研发效能领域的探索过程

相信大家之前或多或少对思码逸都有一些简单的了解，思码逸成立于 2018 年，公司定位是为企业提供研发效能度量分析平台及相关解决方案，公司成立的背景是源于两位老板在 2018 年在软件工程领域顶会上发布的一篇学术论文，论文里详细阐述了《量化代码贡献的开发价值》并以此为基础研发了核心算法系统。2019 年正式发布思码逸第一款商业产品 DevInsight 并于当年获得多轮融资,其中核心度量指标“代码当量”上市后引起市场广泛关注，经过大量实践验证后也得到专业协会和行业的高度认可。

产品上市后思码逸一直积极参与推进研发效能行业的发展和度量标准的制定，在 22 年与信通院和多家头部公司联合发布了《软件研发效能度量规范》，补充了研发效能团队度量标准的空白，去年 TID 大会上被授予 23 年度“软件研发优秀工具奖”，同年发布第二款商业化 AI 编程助手“DevChat”，期望更全面的帮助企业提升研发效能水平。

思码逸创始人背景及公司愿景

思码逸的创始人是任晶磊任总以及殷和政殷总，目前任总在国内经常参加一些行业交流活动，也是今天我们研发效能分论坛的出品人。两位老板都是清华系出身，研究方向侧重于软件工程和机器学习领域，所以公司整体在数据准确性和数据应用上会比较敏感，公司的愿景也是希望通过客观数据驱动企业研发效能的有效提升。

目前已累计服务 100+合作客户

截止目前，思码逸已累计服务了 100 多家客户，客户涉及包含证券、银行、保险、运营商、汽车和互联网等多个领域，也说明了研发效能的发展并不局限于个体行业。在研发数字化和降本增效的大背景下，组织的发展需要研发部门提供更优、更快、更好的技术支撑，所以研发效能的关键词在近几年被提及地更加频繁，各家公司对研发效能建设的需求也越来越迫切。

效能提升需要补充更精细化的过程数据度量

根据以往的经验我也总结了一些大家在研发效能建设的常见问题：

- 投入产出难度量：研发的工作构成复杂，传统用工时做投入，交付数做产出的度量方式很难全面反映研发部门成本投入的合理性，工时主要依靠主观填报很容易掺假，需求难易不一样也会使结果指标失效。很难看清楚主要资源都用在了哪里。

- 研发成本居高不下：研发团队最大的成本是人，随着团队规模的扩大，管理和沟通的成本也成倍增加，度量结果就很难反映团队资源的使用情况，当前团队是否存在资源浪费情况，团队成员工作是否饱和，团队忙起来就要加人都是管理者需要面对的问题。

- 研发现状看不清：在遇到一些需求更新比较频繁的客户，发现整个团队都忙于交付而忽略了研发过程管理，当面对研发团队天天见，但交付结果仍然表现很差的情况，就陷入了效能改进的困境。

- 质量改进无从下手：质量方面的问题有两个，一个是原有度量指标的不准确，千行 bug 率指标很容易被研发主观改变，导致 bug 率波动很大不能反映真实质量情况，另外一个是当发现问题偏多时由于没有下钻分析的手段，强制要求研发提升单测等指标，达不到预期的效果还会影响研发的效率。

这些问题的根本原因是传统的度量更关注结果指标的表现，没有很好的手段能发掘问题的根本原因，导致陷入局部改进的陷阱，所以效能提升的环节是需要补充更精细化的过程数据来共同验证结果指标的结论，找到关键的影响因素。

研发管理需要看代码，代码当量为研发评价提供可靠的基准指标

我们在服务的客户过程中的经验也验证了前面的结论，在过程管理时，研发管理需要考虑的代码维度的度量，代码作为研发团队的主要产出，我们承接的是需求，但最终整个团队的交付物是代码，做好代码环节的度量也能帮我们建立起研发评价的基准指标，进而对需求、bug 等环节指标进行有效的分析。

传统对代码环节或者代码规模的度量，大家更偏向于是用代码行工时等指标，工时/故事点刚才说到本身依赖主观填报，填报人/拆分人的主观判断会直接影响统计结果，代码行由于本身抗干扰性差，不能进行有效对比，在历史大量公司的实践中也已经证明了代码行是一个不太适合的指标。

我们一般会推荐客户使用代码当量来替换代码行作为代码产出效率和代码规模的评估指标，代码当量本身有整套技术理论做支撑，计算过程中抛弃了数行数的方式，将每次代码变化前后的版本编译成语法树对比节点变化，挤压掉空行/换行/注释的干扰，除此之外也考虑到了研发实现代码的成本，新增代码，复杂代码会给予一定的加权并屏蔽掉第三方代码库、自生成文件、重复代码的当量。

以代码当量为基础，可以拉齐研发产出效率的标准，建立一套在代码产出效率客观的评估方式并应用在多个场景。

代码当量衡量投入产出，支撑降本增效

当量可作为研发投入，看资源分布，结合交付结果看是否符合预期

项目最终交付的是代码，所以一方面代码当量可作为项目的成本投入，以此观测各项目的代码规模投入与交付结果是否符合预期，重要业务上是否倾斜了更多的研发精力，研发主要精力是否用于需求开发，需求变更的浪费占比有多大，同时拉齐需求颗粒度后，也能结合交付数据验证投产比是否符合预期。

当量可作为工作产出，衡量人效，优化资源分配，提升资源利用率

另外研发人员主要工作是写代码，代码当量也可以用于衡量开发人员产出，通过当量拉齐人均产出，可用于团队间横向对比，识别到低效率团队，在日常管理中可以采用设基线的方式，避免低产和极端 0 产情况，通过团队贡献均衡度也可以了解当前团队研发资源的使用情况，从而对团队成员配置进行合理调整，充分发挥成员能力，提升整体效能表现。

利用代码当量看清研发过程和质量薄弱环节，保障交付结果

管理研发过程：代码反应过程管理的好坏和问题

- 传统研发过程对管理者及其他角色是黑盒状态，进入开发期很难清楚了解到具体进展，仅靠主观汇报容易忽略掉一些关键风险信号，出现延期或者质量频发的问题已经不可挽回，所以打开研发过程黑盒也是团队管理中的必要环节。

- 代码当量通过对接代码库，可自动拉取相关提交记录进行深度分析，量化每次提交的代码贡献。将历史提交记录和当量按照时间、步长绘制成趋势图。我们便可以了解团队在整个研发过程的产出趋势和效率变化情况，帮助管理者及时发觉过程中的卡点与异常，并根据情况及时调整管理手段，保障项目的顺利进行。

识别质量薄弱点：修复缺陷花费代码越多有可能导致新问题产生

- 质量方面我们遇到最常见问题是质量北极星指标千行 bug 率由于行数因素表现很不稳定，很难找出到底哪个项目/团队质量最差，其次在做质量提升时由于缺少关联分析的能力，项目问题多就强制要求大家提升单测，但往往找不到核心问题模块，导致写单测又成为影响研发效率的因素。

- 这里我们可以使用千当量缺陷率替换掉千行 bug 率，当量的稳定性保证质量核心指标能够反映真实的质量水平，同时借助用当量于 bug 进行关联，找出 bugfix 花费较多当量的模块，使用千当量缺陷率计算各模块修复 bug 可能产生新问题的数量。对问题数高的模块继续下钻，对圈复杂度，入度，当量，历史 bug 等因子进行加权计算，筛选出风险系数较高的文件和函数倾斜更多测试资源。

当然，研发效能的建设仅衡量代码维度肯定是不够的，这里度量代码的意义是为了建立研发工作的基准指标，同时对其余指标准确性进行校准，从而为接下来的研发效能度量体系搭建提供良好的数据基础。避免效能提升掉入结果改进的陷阱。下面我也结合思码逸服务客户过程，分享下如何快速搭建更全面的研发效能度量平台。

如何快速搭建研发效能度量平台

效能建设的每个阶段都会面临不同的问题

由于各家公司对研发效能的探索步调不一致，我们根据一些特征简单分为了三个阶段，每个阶段遇到的核心问题也不一样：

- 效能建设初期：面临更多的是取数问题，手工取数、excel 做表是常用的方式，会耗费大量的人工成本而且容易出现人工计算误差，并且指标相对也比较少，无法真正发现看清团队的效能现状。

- 效能建设中期：这个阶段可能已经尝试对接了各种 DevOps 工具，且已具备了自动化取数，算数的机制，但指标本身由于计算口径不一致，各团队数据源不统一，工具使用不规范等原因会导致数据有效性不能保证。缺少统一的衡量单位，团队间很难横向对比，说不清楚谁表现好谁差。

- 效能建设后期：研发效能建设已经相对健全，但也意味着要面临更复杂的管理诉求，需要通过多维度关联下钻等方式验证数据结论，找到影响效能的关键因素。同时需要根据各个角色的管理目标设计不同场景化的度量体系降低团队管理的成本。另外效能工作投入的成本也需要借助外部数据进行效能对照，验证当前水平寻找进一步改进的目标。

思码逸的研发效能数字化解决方案

在面对不同建设阶段遇到的问题，思码逸提供了全套的研发效能数字化解决方案，共提供了四个维度的核心能力帮助解决问题，快速完成研发效能度量分析平台的建设和使用。

- 快速数据整合能力：预置多个领域数据模型，节约大量数据采集、清洗成本

平台内部预置多个领域数据模型，可以支持代码托管/项目管理/CICD/代码评审等多类型工具的集成和导入，并通过在系统中配置规则解决团队间工具不统一、算数规则不统一的问题。帮助企业快速完成数据采集、清洗工作，最大程度降低了企业取数，算数的难度。同时依靠自动化手段也能节省人工成本，减少人工出数误差。

- 体系化度量能力：内置 30 多张宽表提供 100+指标，按需选择指标高效完成效能度量

平台沉淀了30多张宽表为客户提供研发效能中通用的100多种指标，可根据需要从研发各个环节中选取核心指标搭建适用于当前团队的效能度量体系，搭建过程中思码逸售后团队也会提供相应的经验和帮助。

- 场景应用能力：提供 10 多种研发管理场景及数据解读辅助功能，帮助管理者快速得到有效结论

依托行业和服务客户的经验，平台内沉淀了大量的场景化图表及看板，支持项目/团队/个人等多维度的数据度量与分析，预置关联分析模型以及专家系统功能降低数据理解难度，帮助管理者快速得到结论，找出根因。

- 完善的专家咨询体系：依托行业服务经验提供定制化落地场景方案

除提供标准化产品工具外，合作后附带售后服务团队，包含客户成功、售后技术支持、咨询师等角色。为企业提供技术支持及行业落地经验咨询等帮助。针对某些定制化的使用场景，思码逸也提供专家团队一对一指导及专题工作坊服务。帮助企业用好工具，打造出高效能团队。

高效能团队的典型特征

下面我也介绍下之前调研活动收集到的一些高效能团队典型特征

DevData ’24 研发效能基准报告背景

本次报告是由思码逸发起，邀请了行业 170 多家公司实际使用思码逸平台并参与贡献数据，初衷是为了弥补研发效能领域行业参考数据的空白，报告数据均来自于客户真实项目做脱敏处理，数据采集涵盖了《软件研发效能度量规范》的三个主要认知域：交付速率、交付质量和交付能力。

报告共产出 15 个指标基准线，从代码生产、需求交付、缺陷密度、构建部署等方面提供了重要数据参考。上周四思码逸的 DDT 直播活动中也邀请行业专家进行了相关的数据解读和分享，有兴趣大家稍后可以关注思码逸视频号观看视频回放。

「高效能团队」中位值水平画像

高效能团队定义：

思码逸分析师和行业专家综合各项调研指标的权重计算出各家公司的综合效能得分，选取排名前 20%定义为高效能团队，从中抽取中位数作为高效能团队数据特征供行业参考。

DevData ’24 研发效能关键洞察特征

此外分析师事后也对各维度数据表现比较好的公司做了回访，结合研发团队实际情况获取了一些关键的洞察特征：

其中我们可以发现，践行敏捷开发模式和小团队快跑的模式代码效率会更高，单测要求与效率间的冲突还是明显存在，外包团队的工作集中在代码开发但代码问题偏多，以及做度量管理的公司相对整体生产效率更高。上周四的基线报告解读直播活动中，来自京东、极氪、骏伯网络的老师和专家也结合自身公司情况印证了这一结论。

由于数据样本的限制，并不一定代表行业所有公司的情况，大家可结合情况用于参考。

某客户高效能团队建设实践

无独有偶，在发起基线调研活动之前，我们一家客户的研发效能建设思路与本次得到的数据洞察结论不谋而合，这次我也带来了这个客户提升团队效能的实践过程。

设定研发团队效能建设目标

在刚接触时，研发负责人就表达了强烈的降本增效诉求，公司今年的管理目标就是在成本和人员 hc 相对去年有所缩减的前提下要求研发团队有明确的效能提效目标，并在年底总结会上汇报提升效果。但苦于之前忙于交付并没有投入太多精力在团队的效能度量上，问题出在哪，目标怎么定是当时的主要问题。

基于这种情况，在沟通方案时我们建议客户进行初步的效能摸底，对接当前使用的多个数据源了解现状，判断问题主要出现在哪个环节，然后将团队的交付目标拆解成对应的指标，从而拉齐团队间的工作表现进行横向对比。借助找出后续需重点提升的团队，对该团队的过程数据进行下钻分析找出关键问题，并以此判断改进的难度和改进目标是否能够达成。合理设定年度效能提效目标。

研发效能整体改进思路

这个是当时整体改进方案的思路，方案整体遵循 MARI 循环度量方法论，先度量分析，找到问题后快速改进，通过评价体系复盘回顾改进效果，调整策略后重新进入新一轮度量循环。经过第一轮摸底基本确定改进的方向主要在研发流程改进、代码质量把控和资源管理优化三方面。

1. 研发流程改进

横向对比，找出影响交付效率的关键因素

首次在项目间进行交付效率对比时发现，个别项目交付周期远高于其他项目且项目间需求交付数差异巨大，了解原因后发现是由于各团队使用Jira时，需求来源、需求类型定义规范不统一，导致计算口径不一致。下钻交付过程中也发现需求/任务状态未及时更新，任务流转期间等待时间占比过长等现象。

针对这种情况做了如下调整：

- 团队使用工具做规范要求：对交付数据进行晾晒，促进各团队项目经理主动落实执行相关规范。

- 加强团队间协作：团队内拆分小组按模块践行敏捷文化，减少由于等待周期过长造成的无效损耗。

校准需求拆分力度，合理预估迭代资源投入

在迭代过程中，为了使团队资源得到充分利用，结合历史数据进行了迭代交付带宽和资源投入的预估模型，打通了需求与代码关联，在对各类型需求进行校准后，通过历史同类型需求当量与人均当量预估本次迭代投入人天，并以此作为分配对应研发资源和项目计划管理的重要参考。

2.代码质量把控

认知各项目的质量水平，优先解决高忧问题

为找到质量方面的薄弱环节，对原有北极星指标千行 bug 率进行了替换，使用千当量 bug 率对各项目质量水平进行重新评估，识别到缺陷密度高的项目进一步分析其 bugfix 当量，对耦合度高导致大量更改的问题模块进行解耦重构，对难排查的问题模块结合圈复杂度及入度分析识别高忧文件与函数，研发重点进行单测注释覆盖，测试环节重点关注。

测试左移，借助 AI 快速提升代码规范

为确保问题的提早发现解决，实施了测试左移的策略，对研发提测的代码进行了单测、注释覆盖度等代码规范的要求，低于一定比例不允许合入及构建，但实行一段时间由于研发团队交付压力大，单测注释会挤压业务开发的时间。后经内部沟通，决定使用思码逸 DevChatAI 助手与公司大模型深度结合，以插件的方式辅助研发快速提升代码规范，满足质效的高标准要求。