DevOps研发模式下「产品质量度量」方案实践

简介: DevOps研发模式下「产品质量度量」方案实践

在当今互联网环境下,需求变更越来越快,交付周期却越来越短,

怎么判断一个系统是否测试充分?

产品质量满足什么样的条件才能投产?

如何判断测试工作、研发团队工作的效率是高还是低?

这些问题不能靠感觉、拍大脑,而是需要客观的数据来反映。质量度量指标就是用一组数据来客观衡量产品研发环节的各方面情况,作为评审和决策的依据。

而为了能够在产品发布前,对产品质量能够做出比较准确的判断,需要清楚质量的属性,这就需要建立质量模型。

说起质量模型,必然绕不开ISO9126,ISO9126软件质量模型是评价软件质量的国际标准,由6个特性和27个子特性组成,如图一所示。建议大家可以深入去理解各特性、子特性的含义和区别。这个模型是软件质量标准的核心,对于大部分的软件,都可以考虑从这几个方面 着手进行测评。

微信图片_20220524163541.png

(图一)

本文就给大家聊一聊关于产品质量度量以及研发效能度量的内容,并分享一些笔者在公司内部的度量实践和观点,希望对大家有所启发。

1. 摆正观点:产品质量度量原则


产品质量度量或研发效能度量的原则:不要与绩效挂钩,而应该作为参考和工具,帮助团队提高效能和产品质量。因为无法覆盖 100% 的度量指标,把度量与绩效挂钩就一定会产生“做数字”的现象。这时,使用质量度量或效能度量非但起不到正面效果,还会对公司和团队造成伤害。

2. 质量度量目标


研发质量度量核心思想一句话来概括:目标驱动,度量对的事;先从全局上找瓶颈,再深入细节;两个基本原则:

  1. 度量应聚焦在全局指标而不是局部指标
  2. 聚焦在结果产出而不是某阶段工作输出

围绕度量的核心思想和基本原则,在公司团队实际应用度量手段时,最终目标并不是为了提高表面的数字指标,本质还是需要借助度量方法达成以下几个目的:

  • 跟踪团队的表现、提高团队工作效率、绩效和产品质量;
  • 使用度量来寻找问题而不是用来做绩效考评;
  • 使用度量来检验改进措施的效果;
  • 提高项目计划、效付的精确度;
  • 了解流程是否高效,寻找需要改进的关键领域。

由此我们不应对那些看似繁忙但只产出了一大堆无效工作输出的团队或人员进行奖励,而是引导到那些对促进组织达成目标有实际帮助的工作上去。

3. 效能和质量度量的几个维度


正如刚提到的,度量的目标之一是为了帮助团队寻找问题,并检验改进措施效果,因此不同公司团队所处阶段、研发能力成熟度、团队面临问题的不同,导致了度量方法并没有所谓的唯一性,团队需要根据自己的问题选择合适的度量方法。并且即使是在同一个公司团队内,度量方法也应该是持续演进的,并不是固定不变。

虽然度量方法没有唯一性,但行业众多公司经过大量的度量实践,也有一些普适性的考量维度,供大家参考,大致分为三类:

  • 基于研发效能,3个维度:交付效率、交付质量、交付能力
  • 基于团队+个人,4个维度:质量、速度、效能、准确度。
  • 基于产品质量,3个维度:产品内部质量、产品外部质量、产品使用质量。

其中,交付效率、交付质量和交付能力,这些指标的提升需要组织进行管理、技术、协作等多方面的系统性改进。

而研发效能度量指标一般用来衡量软件产品的生产过程和产品质量,但公司真正需要关注的是否能产生用户价值。因此如果从质量管理的角度,我更倾向于第三种。

微信图片_20220524163417.png

(来源:facebook葛俊老师)

上图分享了一张facebook葛俊老师整理出来的一张研发效能度量指标,里面涉及到的度量指标有很多,实际还远不止于此,考虑到指标数据收集和统计的工作量及其对衡量工作和结果的权重,建议大家可以从众多指标中选取若干指标,并将这些度量指标进一步分为必选和可选两部分,可在不同的测试要求下进行自如地裁剪或添加。

4. 产品质量度量「V2」模型实践


接下来,分享一下,笔者公司对质量度量的一些实践经验。

结合2020年研发中心产品团队发展现状及团队当前目标,为了更好的促进产品质量发展研发效能过程管理,笔者将产品质量度量模型进行升级调整为:V2。

新的V2产品质量模型中,将产品质量按照:研发全产品质量各产品之间质量横向对比、单个产品质量详细等三个版块并从外部质量、内部质量、使用质量等三个维度进行产品效能质量过程管理,并提取出相应的适合当前团队的质量指标。

4.1 全产品质量度量

1、全产品研发质量度量指标导图:

微信图片_20220524163312.png

4.2 各产品之间质量度量对比

1、各产品研发质量度量指标导图:

微信图片_20220524163236.png

4.3 单产品质量度量

1、单产品研发质量度量指标导图:

微信图片_20220524163150.png

PS: 以上指标解释权归本文笔者所有,度量的目的是促进质效提升和检验改进的效果,是一种参考工具,但并非是捆绑手段。

以上只是列举分享了笔者当前正在实践的一些常用指标,实际应用时,结合了度量的通用报告模板、数据模型。当然这些指标并非唯一,仅供大家参考。

5. 小结


其实,使用何种度量方法、指标,是一个仁者见仁,智者见智的问题。所以,通过这篇文章,我更希望达到的目的是,能帮助你对日常工作中最常见的问题进行思考,寻找值得优化的地方,从而提高个人和团队的研发效能。但,我还要强调的是,度量只是辅助,更重要的还是思考。所以,我建议你不要花费过多的时间在指标研究上,要时刻留意实际的投入产出比。

最后,分享一下我个人对效能度量的几大感受:

  • 1、度量只是工具,不是目的。切记度量的真正的目标是提高效能,不要舍本逐末。比如说,如果度量花费的时间超过了收益,那就不要去做。
  • 2、虽然我们推崇数字驱动,但在效能的度量上,不要过于迷信数字,适当使用主观反馈效果反而更好。
  • 3、研发效能的度量看似是一个无解的问题。但如果使用得当,效能度量是可以给公司的研发带来非常大的好处。
目录
相关文章
|
28天前
|
jenkins Devops Java
DevOps实践:Jenkins在持续集成与持续部署中的价值
【10月更文挑战第27天】在快速发展的软件开发领域,DevOps实践日益重要。Jenkins作为一款流行的开源自动化服务器,在持续集成(CI)和持续部署(CD)中扮演关键角色。本文通过案例分析,探讨Jenkins在Java项目中的应用,展示其自动化构建、测试和部署的能力,提高开发效率和软件质量。
47 2
|
9天前
|
监控 安全 Devops
DevOps实践中,如何平衡开发速度和安全审核的效率
在DevOps实践中,为平衡开发速度与安全审核效率,可采取自动化安全测试、安全编码实践、持续监控与日志分析、集成安全工具、合规性代码审查、基础设施即代码、权限和访问控制、安全培训、漏洞及补丁管理和持续反馈改进等措施,确保高效安全的开发流程。
|
19天前
|
运维 安全 Devops
DevOps实践中的安全审核和合规性
DevOps实践中的安全审核和合规性
|
19天前
|
监控 安全 Devops
DevOps实践中,如何平衡开发速度和安全审核的效率?
DevOps实践中,如何平衡开发速度和安全审核的效率?
|
20天前
|
存储 监控 Devops
DevOps实践:持续集成/持续部署(CI/CD)的实战指南
DevOps实践:持续集成/持续部署(CI/CD)的实战指南
|
22天前
|
运维 安全 Devops
DevOps实践中的安全审核和合规性
DevOps实践中的安全审核和合规性
|
29天前
|
jenkins Devops 测试技术
DevOps实践:Jenkins在持续集成与持续部署中的价值
【10月更文挑战第26天】随着DevOps理念的普及,Jenkins作为一款开源自动化服务器,在持续集成(CI)与持续部署(CD)中发挥重要作用。本文通过某中型互联网企业的实际案例,展示了Jenkins如何通过自动化构建、持续集成和持续部署,显著提升开发效率、代码质量和软件交付速度,帮助企业解决传统手工操作带来的低效和错误问题。
54 4
|
29天前
|
运维 监控 Devops
DevOps文化:持续交付与持续反馈的文化构建与实践
【10月更文挑战第26天】DevOps作为一种将开发与运维紧密结合的文化和实践,通过促进团队协作与自动化流程,实现快速、稳定且高质量的软件交付。本文重点探讨持续交付与持续反馈两大支柱,通过实际案例和示例代码,展示其构建与实践过程。例如,使用Jenkins构建CI/CD流水线,通过Grafana和Prometheus实现实时监控,确保软件质量和快速响应。
33 1
|
24天前
|
运维 Devops jenkins
DevOps实践之持续集成与持续交付
【10月更文挑战第32天】在软件开发的快节奏世界中,DevOps已经成为提升效率和质量的关键策略。通过将开发(Development)和运维(Operations)紧密结合,DevOps促进了更快速的软件发布和更高的可靠性。本文将深入探讨DevOps的核心组成部分——持续集成(CI)和持续交付(CD),并展示如何通过实际代码示例实现它们,以帮助团队构建更加高效和稳定的软件发布流程。
|
28天前
|
运维 Devops jenkins
DevOps文化:持续交付与持续反馈的文化构建与实践
【10月更文挑战第27天】DevOps文化强调开发和运维的紧密合作,以实现快速、高质量的软件交付。核心在于持续交付和持续反馈。本文探讨了如何通过改变组织结构、构建跨功能团队、使用自动化工具(如Jenkins)和积极收集用户反馈,来构建和实践DevOps文化。
44 0