当前位置: 首页 > 工具软件 > Gatekeeper > 使用案例 >

作为Gatekeeper,请守好交付质量关口(Quality Gate)

滕无尘
2023-12-01

作为Gatekeeper,请守好交付质量关口 (Quality Gate)

质量保证(QA)包括三个不同的领域:

  • 分析质量保证:根据标准检查软件产品的质量。如果软件产品不能达到特定的期望值,将采取适当的措施(很可能是返工)。
  • 建设性质量保证:建设性质量保证包括为预先构建无错误软件提供帮助的所有方法。
  • 组织质量保证:组织质量保证的任务是提供一个可以建立质量保证的环境。组织质量保证包括质量管理组织、培训课程和开发过程。

许多软件公司通过质量关口(Quality Gate,有的翻译为质量门)来分析其软件产品的质量并及时采取行动。

质量关口(Quality Gate)

质量关口(Quality Gate)是项目中的重要里程碑和决策点。

在每一个质量关口上,产品都根据预先确定的、以质量为中心的标准进行评估。在满足这些标准的基础上,看门人(Gatekeeper,通常是QA)决定一个项目是否可以进行。因此,项目的质量状况可以向管理层揭示,并及时采取行动。

质量门通常用于某些领域,例如汽车开发或工业品的批量生产。在软件开发领域,质量门在过去的几年中开始不断被使用。

软件项目使用质量关口的策略(Quality Gate Policy)

软件公司可以通过两种方式使用质量门(我们将其称为策略):

  • 质量关口作为质量指南:相同的质量关口(和标准)适用于所有项目,从而在所有这些项目中产生可比且至少相等的最低质量水平。
  • 质量门作为一种灵活的质量策略:在每一个项目中应用一个合适的质量门过程,以精确地满足项目的需要。

质量门参考过程封装了特殊的结构、活动、方法、角色和文档,软件公司可以单独实现这些结构、活动、方法、角色和文档,以满足其质量和业务目标。这种质量门参考过程,可以量身定做,以满足特殊项目的需要。行动的结果是一个质量门过程,包含一组标准和一组质量门。

软件公司如何实现质量门(Quality Gate)概念并不重要,因为实际实现取决于公司的规模和领域。

Scrum 开发常见的Quality Gate

在Scrum开发中,团队或者QA通常会设定一些开发质量检查标准,下面举一个例子:

某一个开发团队和QA协商后,根据公司的质量管理策略,设定的Quality Gate如下表格所示。

但是在实际Sprint迭代中,团队总是按照低水平交付,甚至某些指标的度量结果都达不到低水平的要求。

Items低水平标准值高水平标准值说明
Sprint中 Unit Test Coverage

50%~60%

 >85

使用JUnit或者Sonar检测结果
Sprint Test 测试用例执行通过率

>90%

= 100%

JIRA XRay统计数据或者Excel文件手工管理
Sprint Test 缺陷率< 10%< 5%根据缺陷率计算公式实施
Sprint Test 缺陷修复率

>95%

= 100%

JIRA XRay统计数据或者Excel文件手工管理
Sprint中 Code Inspection

Bug数为0

Vulnerabilities少量存在

Bug = 0

Vulnerabilities=0

检查工具:Sonar、FindBugs等

Sprint中 User Story开发完成率

与Sprint Planning对比无延期的User Story

> 90%= 100%管理工具:JIRA或者Redmine
User Story对于产品需求的覆盖率> 90%= 100%管理工具:JIRA或者Redmine

Sprint 规定的必要交付物

按照预设标准检查

[文档]

交付物数量基本满足

交付物内容评审后基本通过

交付物数量正确

交付物内容评审后符合要求[达到目标]

文档管理工具:

文件服务器SVN

JIRA或者Confluence

Gatekeeper 为什么不能守好交付质量关口

Sprint开发中,QA进行定期的质量检查,结果发现Scrum团队的开发质量不能满足Quality Gate的要求,大多数度量指标甚至连低水平都不能满足。但是产品交付期已经到了,产品必须在Deadline之前要进行Release。

这个时候整个组织或者团队开始进入“黑色地狱周”,不停的加班,夜以继日的工作。各种管理人员开始关注产品开发质量,各种会议,报告不断。最后实在没有办法时,只能有条件通过产品质量检测,实行上线发布。然后在实施紧急Hot Fixing。

QA是不是需要和管理者、干系人、Scrum团队等一起来分析为什么产品开发质量不能满足要求?

原因到底出现在哪里?从五个维度进行分析:结构、活动、方法、角色和文档。

  • 质量意识薄弱,检查不及时、不到位。
  • QA无力推动Scrum团队及时做出必要的改善,话语权不够(在组织中的地位不高,不能得到管理层的支持)
  • 组织的开发过程本身存在流程和活动的缺陷,QA没有能够及时发现。
  • ……

但是无论怎样,QA作为Gatekeeper,当产品交付产生质量问题时,肯定是存在责任的。为什么不能守好交付质量关口呢?

100个人会有100中说法。QA自身需要首先做出有效的改善

  • 做到“两个坚持”:坚持原则,坚持标准
  • 做到“三不怕”:不怕问题,不掩盖问题,不怕在工作中“得罪人”
  • 按照组织级的Quality Management Plan按时实施Quality Check活动
  • 不断改善组织的开发过程和Quality Gate,使其符合组织的实际情况(标准不能降低,要找到达到标准的办法)
  • 诊断开发过程,找到问题,逐一提出改善意见
  • 及时和相关管理者、干系人、项目团队进行有效的沟通,积极解决问题
  • 定期发布质量ISSUE报告
  • 参加Scrum团队的Retrospective活动,收集反馈质量管理意见和建议
  • 取得管理层的有力支持
  • 通过质量改善活动,分析效果,及时形成报告并共享给管理层和相关干系人

 

 类似资料: