研发质效评估体系及构建思路
质量管理&质量改进
质量管理部门包含质量改进的相关职能,关于质量改进,百度下解读如下:
- 质量改进(Quality Improvement)为向本组织及其顾客提供增值效益,在整个组织范围内所采取的提高活动和过程的效果与效率的措施。质量改进是消除系统性的问题,对现有的质量水平在控制的基础上加以提高,使质量达到一个新水平、新高度。
为什么要进行质效改进活动
- 1.领导及业务部门不清楚各项目的质量情况
- 2.产品缺乏明确的质量数据、实施个例无法体现产品整体
- 3.项目质量好坏无数据度量、项目间无客观的比较
- 4.质量改进措施效果是否有效无数据支撑
- 5.项目团队之间交流少,缺少相互借鉴学习的机会
关于质效的数据
- 1.数据是必要的
- 2.数据可以统计并有可能进行快速统计的
- 3.数据能够体现项目质量并能测算成本
研发质效总览
功能概述
研发质效度量是提供企业用以度量研发效能,通过对企业的项目管理,代码活动,应用发布,测试等研发协同功能中进行数据的同步抽取清洗分析建模,为企业提供研发效能分析和解读。
度量指标定义
- 一次性上线发布成功率:统计产品版本所对应项目上线成功率,代表产品版本的项目实施整体结果,成功率越高,代表版本实施成熟度越高。
- 容易发现缺陷数:统计产品版本内,该团队的低级缺陷发现情况,数量越高,代表开发人员开发能力越弱。
- 正式构建数:统计版本内构建执行次数,可计算通过构建所节省人力成本。
- 新增缺陷数:统计时间段内,该团队被指派的缺陷数量;这个指标用于度量团队产生的缺陷数,间接反映质量。
- 缺陷 Reopen 率: 统计时间段内,该团队缺陷 Reopen 次数除以解决缺陷数;这个指标用于度量团队缺陷的修复质量,Reopen 率越高代表返工越多。
- 缺陷平均修复时长:统计时间段内,该团队关闭的缺陷从创建到 Fixed 状态的平均时长(自然日按天计算);这个指标用于度量开发团队缺陷的修复效率,时长越短,代表缺陷修复越快。
- 缺陷平均关闭时长:统计时间段内,该团队关闭的缺陷从 Fixed 到 Closed 状态的平均时长(自然日按天计算);这个指标用于度量测试团队缺陷的验证效率,时长越短,代表缺陷被验证的越快。
- 人均提交代码量——统计时间段内,该团队提交的代码数量/人数;
- 代码规约扫描 ——统计时间段内,该团队相关应用通过规约扫描的 Critical Issue, Major Issue 数量,越低代表代码质量越高。
待补充指标
- 需求完成数: 统计时间段内,该团队完成的需求数; 这个指标通常用于度量整个团队的交付能力,越多代表团队的交付越多。
- 需求平均完成时长: 统计时间段内,该团队完成的需求从创建到终态(正常结束)的平均时长(自然日按天计算);这个指标是用于度量团队的交付效率,越短代表团队的交付越快越敏捷。
- 新增需求数:统计时间段内,该团队被指派的需求数量;这个指标用于反映整个团队的负载。
模型设计
- 1.采用汇总页 + 各项目详情页的设计风格(不采用以往的 word,查看困难)
- 2.汇总页展示所有产品的质量概述、线上问题、过程数据、各项目指标对比的图表等信息
- 3.详情页展示单个项目的版本情况、缺陷数据、测试产物、开发建议等信息
- 4.除上述表格统计的数据外,月报中还自动生成了图表,查看和分析起来会更加直观。
- 缺陷趋势:可以通过趋势图清晰的看出各缺陷指标是否收敛,来判断改进措施是否有效。
- 项目间对比:把各项目的同一指标进行横向对比,能够清晰看出哪个项目质量相对较好或较差。
特殊情况说明:
- 产品质量评价阶段单位
- 情况 1:以产品版本进行驱动的项目
- 情况 2:无标准产品,通过项目孵化产品的项目
质效总览
通过 excel 表报,提供企业研发关键指标和其趋势的分析展现能力。
产品质量一览.png
关键指标:
- 一次性上线成功率
- 需求
- 缺陷
- 新增缺陷解决率
- 平均关闭时长
- 平均修复时长
- 新增数量、解决数量、关闭数量、reopen 率
项目发布质量
项目进度、效率分析
项目进度对企业的活跃项目进行进度跟踪和效率分析
项目具体缺陷分析
项目版本及线上问题改进
↙↙↙阅读原文可查看相关链接,并与作者交流