思码逸企业级软件研发效能度量平台_代码当量绩效考评量化分析工具

申请试用

思码逸企业级软件研发效能度量平台

思码逸企业级软件研发效能度量平台，驾驶舱看板，多快好省一目了然，认知各项目交付速率，及时识别延期风险。支持20+种语言与私有化部署，快速搭建研发效能平台，助力指标建设，完成DevOps成熟度评级。校准需求颗粒度，建立更可靠的交付效率度量。

立即咨询

首页 > 产品中心 > 数据计算与分析 > 思码逸企业级软件研发效能度量平台

研发效能是需要被度量的没有度量，就没有管理 icon

掌控全局
当前研发效能处于什么样的水平？

研发的投入产出比如何？

项目整体质量表现怎么样？

定位问题
哪些关键因素影响了开发产能？

交付进度顺利吗，是否有阻塞环节？

人力负载均衡吗，是否存在关键人力依赖？

定向改进
有问题的具体事务、任务在哪里？

是否在回顾和改进？质量薄弱环节在哪里？

哪些代码问题需要优先被修复？

工程师的个人画像是如何的？

哪些技能需要定向提升？

数据驱动研发效能提升 icon

一站式研发数据分析平台 icon

研发数据分析平台的难点 icon

快速实现数据治理，提供可靠数据基础 icon

科学的研发指标体系，全面覆盖研发场景 icon

预置高频使用指标

GQM选取北极星指标 icon

代码当量反映真实客观的代码产出效率 icon

代码当量

指标概述

代码当量是衡量开发者修改代码的工作量的指标。与代码行数（LOC）、提交个数（NOC）等简单指标相比，基于抽象语法树（AST）计算的代码当量能更准确地反应修改代码的工作量。

指标优势

代码行数是简单且常用的衡量代码工作量的指标。但是它的缺点很明显，例如：容易受到代码风格、换行习惯、注释、格式化操作等的干扰；无法识别出对代码的实际修改，简单的复制粘贴、移动代码块等会产生大量的行数增删变化。

代码当量

代码当量的基础计算过程如下：

1.分别将修改前的代码和修改后的代码解析为抽象语法树（AST）。2.使用tree diff算法计算将修改前的AST转换成修改后的AST的编辑脚本（Edit Script）。编辑脚本里包括四种对树的编辑操作：插入、删除、移动、更新。3.对于被编辑的抽象语法树节点，根据它的节点类型和编辑操作类型，分别进行加权计算，不同的节点类型和编辑操作类型，权重不同。4.最后，对所有被编辑的节点的加权结果进行求和，即为这次修改的代码当量。5.计算过程中如触发各种当量调节规则，如重复代码识别、第三方库识别、自动生成代码识别等，会根据当量调节规则扣减当量。

敏捷智能的数据分析，充分挖掘数据价值 icon

思码逸，一步到达先进研发管理水平所要求的数据成熟度 icon

不同层级管理者关注的问题 icon

高层管理者：少而精的驾驶舱看板 icon

中层管理者：关注过程指标，针对性下钻分析（1） icon

中层管理者：关注过程指标，针对性下钻分析（2） icon

项目经理：关注项目进度、质量及投产比 icon

技术经理：关注工程质量及资源分配 icon

场景1：驾驶舱看板，多快好省一目了然 icon

场景2：认知各项目交付速率，及时识别延期风险 icon

场景3：认知各项目的质量水平，优先解决高忧问题 icon

案例：快速搭建研发效能平台，首年节省6人月 icon

需求背景：券商，效能体系已经建设了四年，但由于指标缺乏体系，并且缺少更灵活的项目及团队分析维度，难以被真正使用起来。痛点归纳：指标缺乏体系，业务不知道怎么分析，缺少项目及团队分析的看板，需要数据分析师通过SQL分析，不仅工作量大，需求也描述不清楚。解决方案：筛选出北极星指标，并按照管理、项目、团队等业务视角建立起指标体系，从管理、项目、团队的视角，提供灵活的看板支持，节省数据分析师的人力，提高业务的使用率。

案例：助力指标建设，完成DevOps成熟度评级 icon

需求背景：金融企业，研发团队规模超300人。数据分散，治理困难，指标体系不完善。集团对信息化建设提出要求，以推动整体效能提升，其中完成内部的DevOps成熟度评级成为关键考核标准。痛点归纳：数据分散，收集困难，原始数据比较散乱，没有统一的度量的度量模型和方法论，评价指标体系不完善。解决方案：借助思码逸系统集成能力，陆续将DevOps工具集成到系统中，完成数据自动同步。建设企业领域数据宽表，对数据进行清洗整理，借助Dora指标建立评估模型。从思码逸指标体系中选取质量类评价指标，补充完善已有指标库。

案例：校准需求颗粒度，建立更可靠的交付效率度量 icon

需求背景：互联网房产企业，业务链条长、范围广，研发团队与业务方的距离远、沟通成本高。以需求为核心的研发效率度量，为跨部门沟通与协同提效提供了共识基础。所以需求颗粒度稳定、可预估非常重要。痛点归纳：需求大小不一，“需求交付数”难以说明研发效率现状，用故事点/工时评估需求颗粒度，但故事点/工时本身依赖主观评估和手动操作，可信度有限。需求交付数难以预估，研发任务排期、研发资源调度等缺乏客观信息参考。解决方案：依托更准确的工作量指标代码当量，量化需求颗粒度并建立基线,保障需求大小一致。代码当量与故事点/工时交叉分析，识别故事点预估偏差、工时记录不全不准等问题。需求颗粒度稳定后，可基于代码当量基线估算研发交付带宽，合理规划项目进度。

支持20+种语言与私有化部署 icon