敏捷研发过程中如何评判软件产品质量的好坏？

经常听到有领导问：我们的系统产品质量怎么样？很多你都是凭主观来评判，主观的评判缺少数据支撑都是苍白无力的！！！

产品质量好不好数据来说话！！！

按照国家标准应该是这样子的：

 

 但是实际公司内部是这样子的，以下为敏捷研发跑火车模式下的软件质量管理办法：

《产品宏观质量评价标准与预警汇报管理办法》

第一章 产品宏观质量评价标准

产品宏观质量评价标准主要由3个度量数据来体现：

①　疾管师们的线上bug反馈

②　内部人员使用过程中的bug反馈

③　疾管师们使用过程中对使用不顺或者影响她们工作效率方面的 产品优化

现根据2022年1月开始至今得出的产品质量数据如下：

 

2022年第5-6-7-8月份bug较多的主要原因是由于敏捷研发流程体系存在不足(敏捷研发模式的起步阶段、开发周期短上线节奏快)以及 历史遗留的业务需求太多等问题导致

2023年2-3月份 bug较多主要原因是 新入职的前端开发人员对业务还不熟悉，产生的前端bug较多导致

 

根据线上外部反馈的bug产生的影响不同，特设定了 线上累积bug、内部bug、产品优化累积的分值依次为5、2、1

根据每个月 线上bug、内部bug、产品优化 质量高设定的数量分别为8、10、4,

月度质量分数(Monthly Quality Score)的计算公式 MQC= 线上bug数*5+内部bug数*2+ 产品优化*1

类型	分值	优秀月平均值(个)	极差月度结果值(个)	优秀	<=64	MQC小于64
线上bug累积	5	8	16	良好	（64,84]	65到84
内部bug累积	2	10	18	合格	(84,105]	84.01到105
产品优化累积	1	4	10	差	(105,126]	105.01到126
月度质量得分（MQC)		64	126	极差	>126	大于126

 

优秀(MQC)=8*5+10*2+4*1=64

极差(MQC)=16*5+18*2+4*1=126

月度质量得分数值越小 代表月度质量越好

当前划分了5个质量标准

0<= MQC<=64  代表 当前月度质量优秀

64< MQC<=84  代表 当前月度质量良好

84< MQC<=105 代表 当前月度质量合格

105< MQC<=126 代表 当前月度质量差

 MQC>126代表 当前月度质量极差

宏观质量预警

 

预警等级	影响等级 依据	预警人	处理人	处理措施
低	MQC>64	测试组长	测试组	部门群内@吴总@技术经理预警，测试组长分析输出bug较多的模块图表；迭代中针对模块进行回归测试，测试结果 信息技术部群里公告
中	MQC>84	测试组长	测试组长 开发组长	部门群内@吴总@技术经理@开发组长预警，测试组长分析输出bug较多的模块图表；开发组长进行迭代监督优化，指出迭代过程中的不足 信息技术部群里公告
高	MQC>105	测试组长	测试组长 技术经理	部门群内@吴总@技术经理@项目经理预警，测试组长分析输出bug较多的模块图表； 组织站立会探讨质量现状，大家对迭代研发流程提出改进意见，最后信息技术部群里公告

 

每日预警汇报方式：

 

类型	6月9日	昨天新增	当前属于	质量是否下降	是否触发预警	是否站立会
线上bug	2	0个	0<= MQC<=64 月度质量优秀	不明显	否	否
内部bug	3	0个
产品优化	2	0个
MQC	18

 

 

 

第一章 预警汇报管理办法

 

Bug预警机制是对跟踪当前的产品上线质量变化、研发过程质量、研发交付时效，我们采取一些措施（例如：对产品业务进行重构优化、对技术方案设计进行重构、对测试对象进行梳理重点测试等）以此来规避我们产生bug的风险，达到提升产品质量的目标。

这里我们分为了几大块：

①　对线上bug+内部反馈bug的模块进行预警

②　对迭代研发过程中出现的bug进行预警

③　对研发阶段各个研发需求交付的时效性 进行预警

④　对宏观产品质量变化进行预警

一.1. 线上内外部bug模块- 产品+开发+测试 预警

 

预警等级	影响等级 依据	预警人	处理人	处理措施
低	二级模块bug累积>=10个	测试组长	测试组长	预警：测试组长部门群里@产品@技术经理@项目经理@吴总 罗列出当前模块的bug情况以及bug明细条目
			产品经理	改进建议：产品人员 关注当前模块的bug动态，提出改进建议 项目组群里公告
			开发组长	改进建议：开发组长及技术经理 关注当前模块的质量情况，指出改进建议 项目组群里公告
			测试组长	测试检查：测试组长在生产环境对bug所在二级模块核心功能 进行精准 回归测试，测试结果项目组群里公告
中	二级模块bug累积>=20个	测试组长	测试组长	预警：测试组长部门群里@产品@技术经理@项目经理@吴总 并通知站立会 罗列出当前模块的bug情况以及bug明细条目
			产品经理	改进方案：产品 针对当前的bug 提出一些优化改进方案，信息技术部群里公告
			技术经理	处理bug：开发组长及技术经理 安排处理禅道上的高优先级的bug，同时评估当前的一些技术实现方案，信息技术部群里公告
			测试组	测试检查： 针对生产环境中当前bug所在二级模块全量进行回归测试，测试结果 信息技术部群里公告
高	二级模块bug累积>=30个	测试组长	测试组长	预警：测试组长部门群里@产品@技术经理@项目经理@吴总 并通知站立会 罗列出当前模块的bug情况以及bug明细条目
			产品经理	产品经理 组织专项会议检查 当前模块业务设计的合理性，是否需要进行业务重构，并提出解决方案，
			技术经理	开发组长及技术经理 对当前迭代研发过程进行监督加强，对出现的bug进行溯源分析；对bug出现的根源进行排查分析，及时改进研发过程；信息技术部群里公告
			测试组	针对SIT环境中当前bug所在一级模块进行全量回归测试；测试结果 信息技术部群里公告

 

一.2. 迭代bug预警

 

预警等级	影响等级 依据	预警人	处理人	处理措施
中	迭代bug总数>10	测试人员	测试人员	预警：测试人员 @开发组长@测试组长 @技术经理 @项目经理 项目组内截图bug
			开发组长 开发责任人	警示：开发组长项目群里通报谁的bug最多； 自查：组长让让开发责任人员写一份代码质量差的分析报告 发项目组内 @所有人
高	迭代bug总数>15	测试人员	测试人员	预警：测试人员 @技术经理 @开发组长@测试组长 @项目经理 项目组内截图bug
			技术经理 测试人员	警示：技术经理在部门内通报谁的bug最多； 测试检查：测试人员对SIT环境进行全量回归测试，并项目组群内 @所有人 通告测试结果 说明测试了哪些功能，测试结果如何?

 

一.3. 迭代需求-延迟提测时效 预警

 

预警等级	影响等级依据	预警人	处理人	处理措施
低	需求延迟天数=1	测试人员	测试人员	计划：每天站立会上，测试人员提前1天确定要提测的需求，第2天没拿到提测需求，发项目组群里 预警：项目组群内 @开发组长、测试组长、项目经理 罗列已延迟的需求条目 并说明对测试及整体进度影响
			开发组长	自查：开发组长监督好开发人员的开发进度及遇到的困难，责任人为 开发责任人 并项目组群内@所有人说明
中	需求延迟天数=2	测试人员	测试人员	预警：测试人员在延迟的第3天，项目组@开发组长、测试组长、技术经理 罗列已延迟的需求条目，并说明对测试及整体进度影响
			开发组长	解决问题：开发组长找技术经理 沟通解决办法，开发组长在项目组群里公告，开发组长担责
高	需求延迟天数>=3	测试人员	测试人员	预警：测试人员在延迟的第4天，部门内@开发组长、测试组长、技术经理、吴总 罗列已延迟的需求条目，并说明对测试及整体进度影响
			技术经理	解决问题：技术经理组织站立会给出解决方案，技术经理担责

 

一.4. 迭代需求-测试执行时效 预警

 

预警等级	影响等级依据	预警人	处理人	处理措施
低	测试完成延迟天数=1	测试人员	测试人员	预警自查：项目组内@开发组长@测试组长测试人员梳理罗列测试完成延迟的需求条目，并说明延迟原因。
中	测试完成延迟天数=2	测试人员	测试人员	预警自查：项目组内@开发组长@测试组长@技术经理 测试人员梳理罗列测试完成延迟的需求条目，说明延迟原因。
高	测试完成延迟天数=3	测试人员	测试人员	预警自查：部门群内@开发组长@测试组长@技术经理@吴总 测试人员梳理罗列测试完成延迟的需求条目，说明延迟原因。