设计最佳的 Jira工作流跟踪bug

Jira 是市面上最佳的任务跟踪工具之一，几乎所有功能都可以定制，这也是它的强大之处。您可以根据自身的情形制定工作流。
Jira 平台在开发者社区广受欢迎，这些团队面临的最严重的挑战之一就是修复软件 bug。事实上，Jira 最初就是一个 bug 跟踪器。因此，在构建 bug 跟踪工作流时，Jira 本身就有一系列可供选择的选项。但我们可能仍然还会问自己一个问题，哪些是最佳实践和方案。本指南将围绕着该话题展开探讨，以便在 Jira 中为组织建立一个有效的解决 bug 的工作流。

Jira 工作流跟踪 bug 的基本和一般原则

最有效的 bug 跟踪工作流允许团队识别、记录和跟踪 bug，并从单一视图访问问题，同时和其他任务相关联。

不过，我们首先要问一个问题，为什么不直接就使用现成的工作流。答案是，当然可以。Jira 默认的 bug 工作流是一个很好的出发点。尽管如此，您可能需要添加步骤，插入审核和批准，确保流符合组织的标准和要求，这就是我们定制流的原因。

Bug 工作流分解
那么，需要将哪些阶段纳入 bug 跟踪工作流呢？下面我们进行分解：

• 报告 bug 并创建问题（包含相关详细信息）
• 确定问题的优先级别
• 分配和解决问题
• 如果需要，请重新打开
• 开展工作、报告进展情况并解决问题

一种方法是使用子任务在单个问题下涵盖多个任务，然后单独跟踪和分配这些子任务。您甚至可以设置阻止条件，防止问题在所有子任务得到解决之前在工作流中移动。
不过，最有效的方法通常是增加工作流的步骤。这样，我们就可以不受子任务问题类型的限制，另外，也方便可视化和定位工作流中的问题。
然后，在每个环节，将问题分配给不同的用户。根据组织使用的任务分配模式，分配到的人员可以自己直接负责工作，或者将任务委派给团队中合适的成员。
然后，可以使用通知，让团队成员了解问题的最新情况，并在项目准备就绪后立即发出通知。
以下是一个相当常见的工作流，推动团队朝着解决 bug 的方向发展：

• 搁置
• 进行中
• 固定
• 审核中（QA）
• 批准
• 已部署
• 关闭

  分步骤工作流最佳实践

  步骤1：报告 bug

Bug 报告让开发者专注在解决 bug，可以包括问题描述、截图以及关于用户系统和软件的信息等。因此，bug 报告应具备必要的结构和格式，以包含所有必要的技术细节，这一点非常重要。
鉴于此，在 B2C 和大多数 B2B 场景中，您可能希望工程师与任何直接用户之间找到一个媒介。

一个简单方法是允许客户支持人员创建问题，同时减少系统中创建的重复项目数量

同时，在将 bug 关联到支持项目的工单时，使用 “is delivery by”/“delivers” 问题链接类型。这样，可以在解决相应的 bug 时创建受影响的所有工单的报告。

步骤2：分配并确定 bug 优先级

创建 bug 报告只是解决问题的第一步，下一个问题是团队评估 bug 的重要性并相应地分配它们。
毕竟，紧急问题需要得到尽快的解决。在有资源可用的情况下，可以处理积压的小问题。
幸运的是，我们可以直接在工单中快速轻松地分配问题并指定优先级，这样很容易看到最迫切的问题。

以下因素有助于确定问题的轻重缓急：

• 如果可以通过极少的工作（例如，更改单行代码）就能修复，应将其移动到队列的前面并快速完成。
• 应立即识别关键或阻碍前进的 bug 并插入冲刺队列。此外，还应评估是否需要向其中添加故事点。
• 重大和次要问题应按组成部分分组，并插入相关功能开发行列。
• 与此同时，作为技术债解决办法的一部分，需要在工作过程中或以后处理一些琐事。

如果 bug 无法在短时间内解决，则应将其记录为“已知问题”，稍后再作处理。

步骤3：分配问题，并确定 bug 根源

确定了问题的优先顺序之后，开始分配工单，并开展解决 bug 的工作。
解决 bug 的第一步是了解它们发生的时间及原因。这样，可以重复问题，并确定在根本原因阶段的责任人。
我们建议使用测试驱动开发（TDD）方法，首先写一个测试程序并验证其失败，然后作出更改并证明测试成功。
如果 Jira 实例与 Bitbucket 等工具集成，您可以直接从问题页面开始处理 bug。同时，代码更新可以根据工单自动记录，让整个团队随时了解拉请求、合并和部署。

步骤4：影响评估
代码更改可能带来重大后果和副作用，如果修复的影响很大，则必须作为功能请求处理，并对测试用例进行必要的调整。

步骤5：测试覆盖率
修复 bug 后，应该询问：

• 为什么会有 bug？
• 将来如何避免这种 bug？
• 是否需要调整支持和文档，反映修复或防止此类 bug 的发生？

如果过程故障导致 bug，那么须确保识别并解决，防止造成额外的问题（很显然！）。
此类审查可以包括冲刺回顾讨论，和文档补充。
因此，解决问题之前需要考虑的一个重要问题是，是否需要进行流程审核。

步骤6：解决问题
最后一步当然是解决问题了，此时：

• Bug 应该予以修复
• 应该可以确保问题不会再次发生
• 应该调查产品（或相关产品/集成）中是否存在潜在的类似 bug
• 文件和辅助流程应予更新，以反映所作出的任何变动

步骤7：重启问题
如果 bug 复发，则表示修复失败，可能意味着没有找到正确的根本原因。
只要修复尚未到达发布分支，就可以重新打开 bug 报告。但是，如果已到达发布分支，则应创建一个新的问题，以跟踪后续的工作，然后，继续工作，直到永久解决问题。

处理 bug 的热门应用

Jira 与 Bitbucket 的强大集成使工程师可以直接从 Jira 中处理 bug，这只是 Jira 集成的众多源代码管理工具之一。

在为跟踪 bug 构建 Jira 工作流，我们有许多非常有用的插件可供使用。以下是部分最佳插件：

Capture for Jira

Capture 是一种可视化反馈和协作测试工具，团队可以在审查软件时录制视频和屏幕截图并注释。
它将用户浏览器和系统的所有相关信息直接保存到 Jira，避免了繁琐的笔记。Instabug for Jira 是一款具有类似功能的第三方应用。
您可以 Atlassian Marketplace 中找到 Capture app。

qTest for Jira Test Management

q Jira Test Management 可以使 Jira 完成敏捷测试、QA 和 bug 报告。
Jira bug 通过可重复使用的测试运行，完全控制配置变量。应用允许实时可视化与 Jira 问题相关的所有测试用例和测试运行。
另外，还可以从单一视图组织测试自动化、回归和 CI 结果。
这些功能使这款插件成为在 Jira 中跟踪 bug 的强大工具。您可以 在Atlassian Marketplace 中找到这款应用。

Bug Watcher Notifications

Bug Watcher Notifications 可以非常精确地控制谁获取问题更改的更新，确保只获得对您重要的事件更新。
此外，还可以根据角色、分组和电子邮件地址设置观察人员，因此，即使是非 Jira 用户也可以浏览问题。
最后，您可以根据需要设置通知，指定是否要通过电子邮件、桌面或应用程序进行更新，最大限度地减少背景程序切换，继续工作，提高效率。

Jira 的强大体现在它可以无限定制，因此，完全可以根据组织的情况进行适当的调整。
不过，也要记住一点，增加流程的复杂性会拖慢速度。过多的自定义工作流会使平台与其他团队和小组使用的工作流越来越不兼容。

因此，有必要保持 bug 跟踪工作流的精简性。确保每个人在需要时都能获得所需的信息，并致力于构建高效的工作流。然后，通过简单的迭代和优化，创建一个尽可能完善的流程。