效能度量 “三级指标体系” 的应用实践 - 迭代质量预警机制

Mr 老J · 2022年05月24日 · 最后由 ff4e20 回复于 2023年07月05日 · 37959 次阅读
本帖已被设为精华帖!

Previously on “质量度量之 “三级指标体系”

管理学大师彼得 - 德鲁克曾说过:无数据,不管理。(伟人的声音值得一次又一次地被聆听~)

老 J 在质量度量之 “三级指标体系”中系统地拆解了效率、质量、稳定以及资源四个方面的度量指标。试图通过不断积累数据,能帮助我们选取合理、科学的路径以实现一个又一个的工程目标。

是否还记得文末预留 “彩蛋”?

“结合上线前的质量评审机制,通过对测试前、中、后三个阶段,选取指标组合,并通过公式测算而形成质量风险预警效果的 “红绿灯” 提示,是数据可视化应用的一种有效尝试。”

此处 “红绿灯” 提示相关的尝试,即:本文将详细介绍的 “迭代质量预警机制”。

理论指导实践,实践完善理论。

“三级指标体系” 是老 J 在质量度量方面实践的工程理论,而 “迭代质量预警机制” 是该理论的一种有效落地场景。

理论与实践两者往往呈现螺旋上升促进的态势。正如瑞 - 达里奥在其《原则》一书中提及螺旋模型。如下图所示:

同时,“迭代质量预警机制” 其自身也具备 “可迭代性”。可以通过 5 步法持续改进研发工程质量,后文将通过展开其计算逻辑详细说明。此处先介绍 “迭代质量预警机制” 的应用原理。如下图所示:

  • 目标:依据质量指标基线,结合 SMART 原则设置 “跳一下” 能达到的挑战性目标,并清晰的量化出来。比如:缺陷引入率(需求)通过双月从 2.0 bug/需求提升至 1.5 bug/需求;

  • 问题:通过三级指标下钻分析卡点、痛点并做列举排序。比如:通过缺陷归属 TOP 榜重点下钻缺陷贡献 “大户”;结合缺陷分布,缺陷归因等二级、三级指标优先分析 P0、P1 缺陷,以及缺陷高频出现的场景;

  • 诊断:通过 “5 WHY” 方法,定位问题根因。比如:边界未考虑、接后端接口约定变更、错误合入代码等等;

  • 方案:针对问题根因制定优化措施,优化措施按时间轴组合成实施方案。比如:边界场景开发 UT 覆盖,测试用例针对覆盖;统一的 API 管理平台与规则落实;每个 MR 由专人 CR 后合入。当然,举一反三形成通用方案是共识的终极目标,考虑到可操作性,迭代粒度可交付方案是现实折中;

  • 践行:以迭代为实施周期践行方案,取得改进。此步骤,重点在于通过指标大盘跟踪过程,做出及时关注与干预,确保执行有效性。

在每一个目标周期内,通过步骤 1 至步骤 5 的不断循环以改善工程质量的目的。接下来,将详细介绍 “迭代质量预警机制”。

“迭代质量预警机制” 是依据历史迭代过程质量与结果质量数据为基础,通过公式测算关键阶段的风险等级;并以可视化的方式呈现以引起关注,期望制定相应的风险降级措施规避风险发布。其中:

  • 历史迭代个数与目标周期重合,比如一个季度 5 至 6 个双周迭代;

  • 假设过程数据发展趋势呈线性化,即迭代质量线性发展;

  • 风险等级分为:高、中、低,并用红、黄、绿染色呈现;

功能简介

“迭代质量预警机制” 将研发交付过程分为准入、过程、准出以及线上四个阶段,并用相应风险等级预警准入质量、过程质量、准出质量以及线上质量。如下图所示:

功能上有如下特征:

  • 独立性:每业务域维度,业务域各自纵向比较。确保团队、迭代周期要素在功能应用时间段内相对稳定,如业务域团队采用双周迭代模式开展研发活动;

  • 动态性:指标基线每迭代变化。基于近 N 个迭代测算各指标基线,上图显示 N = 5。且默认质量指标持续改善;

  • 闭环性:引入线上质量校准准入标准以及准出风险规避措施有效性;(有一定反馈延迟性)

  • 可迭代性:横向关联的阶段指标可逐步累加;特定指标可在纵向维度细化拆解迭代,即:引入二级、三级指标进行下钻;

  • 基于统计原理,受样本数量影响;

关联指标

四个阶段分别选取相应关联的指标,下文按不同阶段逐步展开并做说明。

阶段 1:准入阶段,关注准入质量。质量度量之 “三级指标体系” 中明确:在通常情况下,设置合理的准入标准(质量门禁)有利于提前终止不达标制品的流转,保障流程的顺畅性,减少不必要的规模化投入。阶段指标有:

  • 准时提测率

  • 冒烟通过率

  • 冒烟缺陷率

阶段 2:测试执行阶段,关注过程修复响应及时性以及修复质量。阶段指标有:

  • 缺陷日清率

  • 缺陷 reopen 次数

阶段 3:准出阶段,关注准出质量。缺陷引入率是最直接描述软件内建质量的指标。从需求、开发(人均)、工时(开发)3 个层面反映迭代的缺陷密度。常规观测是需求维度的缺陷引入率,而需求受颗粒度大小影响;从而进一步引入开发人均缺陷的观测;同时,引入开发工时缺陷引入率作为其参考指标。因此,阶段指标有:

  • 缺陷引入率(需求)

  • 缺陷引入率(开发)

  • 缺陷引入率(工时)

阶段 4:生产运营阶段,关注线上质量。以达到校准风险预警功能和必要的风险规避措施的作用,形成闭环反馈系统。阶段结果指标有:

  • P0、P1 生产故障

  • 其它生产故障

  • 冒烟点

  • 线上问题数(bug 归因)

  • 线上问题总数

风险测算逻辑

基于近 N 个迭代的关键指标数据,通过公式测算其波动大小及变化趋势,得出红、黄、绿的亮灯提示,以帮助测试同学快速识别风险等级,并促成应有的关注与风险规避措施。其中:

  • 测算基于统计概念设计,准确性随着样本的增多呈线性关系;

  • 各研发交付阶段的风险提示,取所在阶段的风险最高值;

  • 指标存在 “正向指标” 和 “负向指标”,前者越大越好,后者则相反;

  • 图例中 N = 5 ,即:近三个月的时间周期;每个指标计算其均值 A (AVERAGE) 及标准差 S (STDEVP) 以划定历史基线及其波动上、下限;

  • 亮灯规则:举例正向指标,详见下图所示:

  • 当前指标值在波动区间(A-S,A+S),且环比增长则亮绿灯;

  • 环比降低则亮黄灯;

  • 如果超出 A-S 则亮红灯;

风险提示逻辑

接上图,进一步说明风险提示逻辑:

  • 基于相对 “粗粒度指标” 的指标(一级指标)计算,该类指标一般可以反映实际事件的组合特征;比如:提测质量、内建质量。

  • 各阶段指标有一定关联,各阶段风险取高风险预警(质量标准取高值原则);

  • 预期各阶段向好发展,对指标的要求(质量标准)动态变化;

说明:计算结果为理论计算反映,需要测试同学结合 “内部反馈” 对指标进行定性描述与说明,类似医生基于实验室报告,并结合实际线下 case 共同诊断病灶。

一线典型场景

依据前 3 个阶段以及每个阶段 3 种风险级别,可通过笛卡尔积产出 27 种理论场景。下文选取一些典型场景说明该功能如何应用。

场景描述:弱质量门禁(交易)(理论场景 #12)
特征:冒烟通过率环比下降,内建质量质量明显下降;冒烟采样未反应较客观版本质量,需求、开发缺陷引入率超出波动上限。

场景描述:内建质量不佳,测试兜底压力大,产生线上概率遗漏(理论场景 #27)
特征:延期提测,提测质量下降;缺陷修复不及时;缺陷引入率高;线上问题(生产故障)数不收敛。

场景描述:个别需求质量不佳,内建质量整体较好(理论场景 #13)
特征:个别需求冒烟不通过,过程修复较慢,整体质量较好。

文末总结

理论指导实践,实践完善理论。理论与实践两者呈现螺旋上升促进的关系。

“迭代质量预警机制” 是依据历史迭代过程质量与结果质量数据为基础,通过公式测算关键阶段的风险等级;并以可视化的方式呈现以引起关注,期望制定相应的风险降级措施规避风险发布。

在每一个目标周期内,循环步骤 1 至步骤 5(目标、问题、诊断、方案、践行),不断循环以改善工程质量的目的。

共收到 7 条回复 时间 点赞

缺陷引入率(工时)指标怎么计算

缺陷引入率是怎么计算的啊?

1、冒烟点是故障的一种轻量级级别。
2、线上问题来源一般有:内部反馈、客诉、监控告警。

想请教大佬:线上质量中,冒烟点这个指标是用于什么?线上问题总数这个指标是否是包含了哪些(用户反馈的缺陷、用户反馈的需求)?

Winn 回复

关于指标定义
准时提测率:在约定提测节点提测的需求数/总需求数,一般通过系统 “提测” 流转记录比对测算准时率;
冒烟通过率:冒烟阶段有缺陷的需求数/总需求数,需要界定冒烟阶段的缺陷提报规范;

关于测算逻辑
简单而言,历史平均定指标水位 + 标准差(波动上、下限);“红绿灯” 显示逻辑可看下 “风险测算逻辑” 一节

Winn 回复

风险测算逻辑部分有明确说明。。。

准时提测率、冒烟通过率,这些指标如何定义?
比如准时提测率是 80% 是红色,还是 60% 是红色?这些是自己自定义,还是有一个明确的标准规范? 有大佬能解答下吗,谢谢!

49875183 将本帖设为了精华贴 05月27日 14:10
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册