缺陷流管理技能连招详解

按照格式上报一下缺陷就叫缺陷管理吗?没有连招怎么行?

问题痛点

软件研发测试过程中的缺陷,是一个特殊的产物,它不会随着研发模型的改变而变化,从一年一发布的瀑布模型,到一周一发布的 DevOps,“缺陷” 无法简化,盲目的追求简化,只不过是掩藏技术债的行为。

  • 理想状态下:一提一修复,验完即上线,缺陷永不见
  • 实际情况中:知否知否,缺陷修复,又岂只在朝朝暮暮

缺陷流技能乃经验中之精品,无不闻之点头,听之惊叹。

那些我们曾经的痛:

  • 修复未修复,傻傻分不清楚
  • 踩坑再翻车,打脸没商量
  • 敏捷与流程,何以兼得

解决方案

用 JIRA 的好处在于能实现任何想实现的效果,难点在于需要一个很懂业务的 Atlassian 工具人。这里我们以 JIRA 生态为例,推荐解决方案。

JIRA 组合拳:工作流 + 字段配置 + 界面 + Automation for JIRA ,科学理论配合自动化,配置不简单,使用不复杂。

1. 缺陷流 (工作流)

先看工作流实图:

乍一看繁琐且复杂,但实际上对于每一次的状态变更只有两个选择:同意 vs 不同意

所有状态贯穿缺陷的完整生命周期,直到最终被验收。

每个状态清晰的表现了缺陷所处的阶段及进展,如:修复中 -> 已修复 -> 已验证

2. 专配专用 (字段配置)

信息不对称在工作交流中带来的弊端大家多少有感触,对于缺陷类型的 JIRA 问题,如果也是用常规字段方案明显是不够的,至少新增以下字段,并且添加说明配上默认值,保证大家认知统一且信息齐全

3. 不同阶段不同界面 (界面)

当然,不能让使用者靠脑力去记忆上报缺陷的时候要填哪些信息,应该是选择不同的问题类型,就展示对应的界面

除此之外,在状态发生变化的时候,也应该弹出需要的界面,过滤掉那些不需要在当前阶段再去考虑的多余信息,只填必要项

4. 自动化协助 (Automation for JIRA)

JIRA 问题的标签栏是个随意性较高的字段,但通常我们仍旧有一些约定好的格式和值,比如缺陷的最终状态总会变为验证,那么它到底是个什么结果,我们期望加上一些标签作为标记,以方便一眼就能识别它,这些操作其实是有规律的,所以我们完全可以解放人力,通过自动化手段去完成,还杜绝了标签添加错误的情况。除此之外,还有验证即需要改变解决结果为完成,缺陷重现需要把解决结果改为进行中等等。

总结一下

管理是一系列的组合连招,仅仅会用个工具很难达到效果,这里面包含了很多业务经验,而质量管理之缺陷流,是比较容易落地的一种流派,还可以通过该方法收集一些数据,对质量管理可以起到一些意想不到的效果。

你可能感兴趣的:(缺陷流管理技能连招详解)