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

admin 提交于 周四, 06/01/2023 - 17:33

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

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

相比大多数所谓『数据看板』,GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水;而是先将具体场景下的具体度量目标拆解成问题,再由问题引出指标图表,层层递进地呈现效能表现,并引导用户适时下钻探索

我们认为,优秀的效能度量一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者,也能低成本理解每个指标的含义和指标给出的信息,实实在在将度量用起来,解决他们在研发管理中的遇到的各类“看不清”“说不明”。

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

0. 要说清研发质量,我们需要关注什么?

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

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

4.0 功能抢先看

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

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

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

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

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

 

4.0 功能抢先看

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

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

作为补充说明,缺陷统计图表中引入了千代码当量缺陷密度指标。有些项目缺陷数量多、但缺陷密度正常,说明缺陷多是伴随活跃开发活动的正常现象,只要严重缺陷占比合理、修复工作正常推进(可以借助修复成本来评估正常与否,下一节会介绍),就无须太过担心。

反而有些缺陷数量少、但缺陷密度高的项目,可能是新增代码质量不高,或者是意外的『牵一发而动全身』,可能需要重点关注。

4.0 功能抢先看

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

4.0 功能抢先看

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

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

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

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

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

4.0 功能抢先看

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

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

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

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

4.0 功能抢先看

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

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

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

例如,缺陷和事故的修复成本过高,可能是由于开发环节急功近利,只顾快糙猛地完成交付,不断引入技术债,导致软件复杂度不受控制;也可能是由于代码缺少注释难以理解,修改时牵一发而动全身。

设计和开发环节的内建质量,一般不会直接影响产品功能,因此也很容易被忽略,或被认为性价比低。但如果不顾内建质量,放任技术债堆积,代码与架构的腐化必然会迅速蔓延,带来大量难以修复的缺陷和事故。当质量问题被感知时,常常已经相当严重且不可逆。

这正是思码逸建议关注内建质量的原因:未雨绸缪,控制技术债累积速度,才能打造出稳健可靠的软件系统。

基于深度代码分析能力,质量保障看板的内建质量部分度量了代码不重复度、模块性、注释覆盖度、测试覆盖度、代码问题密度评分等工程质量指标。在此基础上,还提供了行业基线作为参考值,帮助团队全面评估项目内建质量,避免技术债堆积。

4.0 功能抢先看

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

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

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

4.0 功能抢先看

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

总结

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

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

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

访问量
3645
首图
4.0 功能抢先看