缺陷流管理技能连招详解

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

问题痛点

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

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

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

那些我们曾经的痛：

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

解决方案

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

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

1. 缺陷流 （工作流）

先看工作流实图：

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

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

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

2. 专配专用 （字段配置）

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

3. 不同阶段不同界面 （界面）

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

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

4. 自动化协助 （Automation for JIRA）

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

总结一下

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