4.0 功能抢先看 | 读懂一个项目的研发效能 之 项目质量表现

思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。

最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。更多解读可以查看《GQM 概述：构建研发效能度量体系的根本方法》。

相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水；而是先将具体场景下的具体度量目标拆解成问题，再由问题引出指标图表，层层递进地呈现效能表现，并引导用户适时下钻探索。我们认为，优秀的效能度量一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。

前两篇文章中，我们介绍了 GQM 看板中的『项目交付效率』和『项目人效』。这一篇将继续介绍『项目质量保障看板』。

0. 要说清『研发质量』，我们需要关注什么？

评估研发效能表现时，一个常被提起的关键词是『质效并重』。这也很好理解——以埋下质量隐患为代价，一味追求研发速度，绝大多数情况下都是不健康、不可持续的。无需太长时间，研发团队就会发现自己被用户的抱怨投诉、需要紧急救火的事故、难以理解难以修改的代码绊住手脚，不得不放缓脚步。

所以，我们常说效能≠效率，质量同样重要。去年发布的《软件研发效能度量规范》中，对效能的维度有更全面的阐述，这里不再展开。

那么，如何客观度量，用数据说清研发质量呢？可以明确的是，单环节单个指标是不可靠的，不仅容易产生负向牵引，也无法反映出质量的全貌。

举个例子，缺陷逃逸率低，研发质量就一定好吗？测试团队可能会花费精力多找些边边角角的缺陷来凑数，反而放过了真正重要的缺陷；线上的事故可能数量占比不大，但严重等级高、影响范围广，损害了用户体验，也挤占了研发团队开发新特性的时间。反过来说，缺陷逃逸率高也未必完全是测试团队的责任，只瞄着一个度量指标做改进，可能会导致改进动作走形，变成追逐数字的游戏。

思码逸认为，研发质量的度量应该关注全链路——从开发环节的技术债到测试缺陷和线上事故情况，从内在的软件工程质量到外在的软件品质，先掌握研发质量的整体情况，找到关键改进点或指标间的相关性，再有针对性的采取改进措施。

1. 项目的缺陷/事故情况如何？

说起研发质量，很容易立刻想到缺陷和线上事故——业务方和用户可直观感知的软件品质问题。

《当一位开发者试图修复线上事故》

思码逸从项目管理工具中提取缺陷/事故数据，直观对比多个项目的缺陷/事故数量和严重等级占比。但正如我们前面提到，仅关注单一指标可能会落进数据的陷阱。

作为补充说明，缺陷统计图表中引入了千代码当量缺陷密度指标。有些项目缺陷数量多、但缺陷密度正常，说明缺陷多是伴随活跃开发活动的正常现象，只要严重缺陷占比合理、修复工作正常推进（可以借助修复成本来评估正常与否，下一节会介绍），就无须太过担心。反而有些缺陷数量少、但缺陷密度高的项目，可能是新增代码质量不高，或者是意外的『牵一发而动全身』，可能需要重点关注。

事故统计图表则引入了缺陷逃逸率指标，用于发现那些事故数量不多，但漏测情况较严重的重点项目。

定位到重点项目后，可以下钻查看该项目的缺陷/事故的数量趋势、在各子项目/代码库中的分布情况，并结合修复情况，判断软件品质问题是否随着项目成熟而逐步收敛。需要时，还可以进一步下钻到具体的缺陷/事故 issue，查看经办人和修复情况。

这样从宏观到微观的度量、分析与追问，能够帮助研发团队更加全面客观地理解缺陷和事故，针对性处理质量薄弱环节，把握提质机会。

2. 修复缺陷/事故的成本如何？

项目的缺陷/事故数量显著降低？这当然值得高兴。不过，在庆祝之前，研发团队还需要换一个视角评估软件品质：如果出现问题，需要投入多少精力和时间来修复？

即使缺陷/事故不多，但如果每个缺陷/事故都需要花大力气解决，不仅使软件可用性下降，损害用户体验，也会导致团队忙于救火，无暇顾及新功能开发，开发者的工作价值感下降。

《重构整个模块后终于顺利解决了该缺陷》

思码逸通过时间和工作量两个视角来评估缺陷和事故的修复成本。

• 缺陷/事故响应周期：缺陷/事故类型的事务，从开启到关闭的时长。这一指标和之前项目交付效率中的事务前置周期一样，采用了 P85 分位值，代表该项目 85% 的缺陷/事故能够在该时间段内被解决，相比中位数或平均值，85%分位值更能反映修复速度的普遍情况。

• 修复工作量：关联到缺陷/事故类型事务的提交（commit）的代码当量。看板使用了箱线图来呈现修复工作量的分布情况。如果修复工作量普遍偏高，则可能架构腐化的情况比较严重，导致软件系统维护难度大，修改起来拖泥带水；如果修复工作量高过上限的异常点很多，建议也关注一下为何个别缺陷/事故如此棘手，从具体的案例复盘中发现普遍性问题，让软件系统更加健壮。

更进一步，看板还提供了缺陷/事故响应周期的变化趋势和修复工作量占总代码当量的比值，帮助研发团队建立参照系，通过对比更直观地理解软件品质问题的修复成本。

3. 研发环节的内建质量如何？

前面我们主要聊了软件品质。软件品质是研发质量的外在表现，其实早在设计和开发环节就已埋下伏笔。通过缺陷/事故数据发现的研发质量问题，也常常需要追根溯源到内建质量控制，基于测试左移等实践才能做出有效改进。

例如，缺陷和事故的修复成本过高，可能是由于开发环节急功近利节急功近利，只顾快糙猛地完成交付，不断引入技术债，导致软件复杂度不受控制；也可能是由于代码缺少注释难以理解，修改时牵一发而动全身。设计和开发环节的内建质量，一般不会直接影响产品功能，因此也很容易被忽略，或被认为性价比低。但如果不顾内建质量，放任技术债堆积，代码与架构的腐化必然会迅速蔓延，带来大量难以修复的缺陷和事故。当质量问题被感知时，常常已经相当严重且不可逆。

这正是思码逸建议关注内建质量的原因：未雨绸缪，控制技术债累积速度，才能打造出稳健可靠的软件系统。基于深度代码分析能力，质量保障看板的内建质量部分度量了代码不重复度、模块性、注释覆盖度、测试覆盖度、代码问题密度评分等工程质量指标。在此基础上，还提供了行业基线作为参考值，帮助团队全面评估项目内建质量，避免技术债堆积。

值得注意的是，内建质量也是有成本的。研发团队需要综合考虑业务阶段、业务属性、团队规模等实际因素，合理制定内建质量目标，避免把团队拖入内卷。

通过多指标分析，明确了质量改进方向，如何推动开发者在日常工作中落实？毕竟开发者们的时间和精力是有限的，很可能无法在内建质量上投入太多心力。

思码逸支持下钻至函数/文件级的待改进项，并给出了明确易执行的改进建议。当内建质量不佳时，开发者们只需要根据快速调整，及时响应，即可在潜移默化中落实研发规范。

例如重复代码的优化任务，可以识别到具体函数级别

总结

对于研发质量的关注，不仅是对项目负责、交付的软件产品负责、对使用产品的客户和用户负责，也是对研发团队的成员们负责。优秀的质量能帮助项目和研发团队走得更稳、更远。

覆盖从开发到上线全链路的研发质量度量，不仅给研发质量提供了更完整的视角，也能够更好地支持从现象到根因的追问，帮助度量数字转化为切实有效的改进措施。

这篇文章写完，GQM 看板的新功能抢先看就先告一段落。下一篇文章，我们会聊聊思码逸企业版 4.0 对研发流程的灵活支持能力。这一基础能力将帮助研发团队轻松接入思码逸平台，以更低成本、更快速度开启研发效能度量。

———————

思码逸一站式研发效能度量分析平台，致力于帮助研发团队解决研发效率、代码质量和人才发展三大痛点，提升研发效率与软件工程质量。更多详情，可访问官网。