剖析 Jira 基础架构与配置技巧

如果觉得这篇文章不错，请记得点赞、收藏和分享，也欢迎加我个人微信交流：craigyoung1985，请备注：姓名/城市/工作岗位。

Jira 和 Confluence 是 Atlassian 公司推出的企业级项目管理和团队协作产品，这两款明星产品的关系就像咖啡和甜甜圈，单独品尝很棒，结合在一起使用效果绝佳。很多创业公司和大型企业在管理工具的演进过程中都或多或少使用过它们。

但是由于缺乏专业顾问的指导和最佳实践的指引，很多公司在导入 Jira 过程走得并不顺利，过多的“反对声音”导致最终的“夭折”。在笔者看来，行业上的项目管理工具的功能大同小异，更关键的是工具背后的方法论和思想。如果大家不理解它们，即使尝试不同的工具也无济于事。

笔者自2011年以来，依次使用过Jira 3.x、6.x、7.x，最近也有幸体验了8.x，每次大版本升级都会给用户带来很棒的功能特性、用户体验和性能的提升，最让人振奋的是6.x版本引入了Agile，将之前列表显示方式以全新的“看板”方式来显示，进而慢慢地从缺陷和问题跟踪软件升级为敏捷项目管理软件。接下来，我为大家揭开 Jira背后的神秘面纱，以及在实践过程中的一些配置技巧。

Part I：Jira 基础架构

Issue（问题）是 Jira 项目的基本单元，用来跟踪一个项目中的所有工作或任务，无论是技术型、非技术型、支持型或其他类型。 Jira 项目是 Issue 的集合，提供了 Issue 的背景上下文，让用户知道应该在哪里创建 Issues，用户是 Jira 项目的成员，工作在项目的 Issues 上。根据每个组织和需求的特性场景，一个 Issue 可以是：

• 敏捷项目中的一个用户故事
• 用户故事中的一个任务
• 一个产品功能特性
• 一个测试缺陷或 Bug
• 帮助台中的一个服务工单
• HR管理中的一个请假审批请求

为了区分不同类型的工作，Jira 将相似的 Issues 归为同一个Issue Type（问题类型），常见问题类型有：Epic、Story、Bug、Task 和 Sub-task 等。问题类型可以分为“标准问题类型”（如：Story、Task）和“子任务问题类型”（如：Sub-task），它们之间是强父子关系（相对于 Jira 链接这种弱关联而言）。此外，我们还可以自定义问题类型，如：针对客户的咨询或查询场景，我们可以创建一个自定义问题类型Query。

在 Jira 中，问题类型是个很关键的概念，它与工作流、界面和字段的配置都有直接关系（如上图）。接下来，我们将逐一介绍下：

1. 问题类型方案

一个 Jira 项目通常需要搭配多种问题类型，比如：敏捷项目至少包含 Epic、Story、Task、Bug 和 Sub-task。为了满足某些特定场景（如：敏捷项目管理），我们将与之关联的问题类型“组合”在“问题类型方案”中，便于以后其他敏捷项目复用该问题类型方案。一个 Jira 项目关联一个问题类型方案，而一个问题类型方案关联 1~N 个问题类型。

2. 字段配置方案

Fields（字段）是 Jira 中最基本的数据单元，为 Issue 存储有意义的数据。Jira 字段分为系统字段和自定义字段，字段类型包含：文本型、下拉列表、用户选择器和日期等，例如：“经办人”属于用户选择器类型的系统字段，缺陷“严重程度”属于下拉列表类型的自定义字段。字段必须在其载体”界面“中展现。

此外，字段还有”隐藏“和”必填“行为，在“字段配置”中设置每个字段的行为。一个字段配置可以被 1~N 个问题类型使用，例如：一个 Jira 项目中除问题类型 Bug 之外的所有问题类型都使用默认的字段配置，而 Bug 的字段配置中强制自定义字段“严重程度”为“必填”。我们将这些与不同问题类型关联的字段方案组合称为“字段配置方案”。一个 Jira 项目关联一个自定义的字段配置方案或一个系统默认字段配置。

3. 问题类型界面方案

Jira 界面是显示在 UI 上的字段排列和展现，例如：新 Issue 创建界面、现有 Issue 编辑界面、状态转换的工作流界面。界面方案提供了在创建 Issue、编辑 Issue 和查看 Issue 时可以显示不同的字段（如下图），例如：自定义字段“发布结果”不显示在创建 Issue 界面，但是需要显示在编辑和查看 Issue 界面。所以，一个界面方案对应 1~3 个界面。

一个 Jira 项目中不同问题类型可能需要配置不同的界面方案，例如：在问题类型 Bug 的界面方案中，Bug 界面需要自定义字段“严重程度”和“缺陷原因”，而其他问题类型使用默认的界面方案即可（一个界面方案关联 1~N 个问题类型），我们将这些与不同问题类型关联的界面方案组合称为”问题类型界面方案“。一个 Jira 项目关联一个问题类型界面方案，一个问题类型界面方案会被 1~N 个 Jira 项目使用。

4. 工作流方案

Jira 使用工作流跟踪一个 Issue 的生命周期，工作流记录着一个 Issue 在其生命周期中 Status（状态）和 Transition（转换动作）的变化。一个 Issue 在某个特定时间点有且仅有一个状态（如：打开的、进行中或关闭的），Jira 状态有三个类别：初始、进行中、终态，每个 Jira 状态属于其中的某个类别，例如：“待办”和“打开的”为初始状态。

当一个 Issue 从一个状态移动到另外一个状态时，转换动作是这两个状态之间的连接，通过这个“连接”实现了状态的切换，例如：转换动作“关闭”将 Issue 从“进行中”切换到“关闭的”状态。在“转换动作”中可以配置“工作流界面”来收集必要的数据（如上图），例如：用解决 Issue 时的弹窗收集“解决结果”和工作在该 Issue 上的“耗费时间“。

一个工作流关联 1~N 个问题类型，比如：Task 和 Sub-task 可以共用一个工作流，Story和Bug分别有自己特定的工作流。我们将这些工作流“组合”在Workflow Scheme（工作流方案）中，为某些特定场景服务（类似于问题类型方案的作用）。一个 Jira 项目关联一个工作流方案，一个工作流方案会被 1~N 个 Jira 项目使用。

除了上面4个与问题类型直接关联的“方案”外，Jira 还有以下4个与 Jira 项目直接关联（1:1）的方案：

• 优先级方案：多个 Jira 项目可以共用一套优先级方案，例如：敏捷项目的需求管理使用 MoSCow 优先级，而其他项目使用 Jira 默认的优先级方案；

• 通知方案：将不同事件的触发通过邮件通知到特定的 Jira 用户或用户组等，例如：当“问题被解决”事件被触发时，通知到报告人、当前经办人和“产品经理团队”；

• 权限方案：将项目权限（如：管理 Sprint）、问题权限（如：分配问题）和评论权限（如：删除自己的评论）等类型的权限授予不同的项目角色、用户组、报告人和当前经办人等；

• 问题安全方案： 控制谁可以或不可以查看 Issue，为 Issue 级别的权限控制；

Part II：Jira 配置技巧

一般来讲，Jira 配置应遵循“简洁”和“可复用”原则，可以大大减少后期维护成本，对维持Jira性能也有帮助。

1. Jira 定制化流程

我们在处理 Jira 定制化需求时需要遵守一定的流程：

• 收集 Jira 用户的定制化需求，例如：产品研发团队想将客服问题处理流程从Excel 迁移到 Jira上，并记录每个工单的“订单号”和“客户名称”；

• 将设计的 Jira 解决方案落到文档里（为了方便后期维护），明确需要新建什么问题类型、工作流及其界面、权限方案和通知方案等，与相关方进行评审并定稿；

• 在 Jira 测试或沙箱环境中配置，并邀请用户参与一起测试并收集其反馈，按反馈建议进行配置修改，同时，对文档做必要更新；

• 在 Jira 生产环境中配置和应用；

2. 尽量“复用”现有字段

为了减少过多的自定义字段对 Jira 性能的影响，我们在创建自定义字段时尽量使用“通用名称”，例如：使用“客户ID”代替“商家ID”和“买家ID”，这样在使用到“商家ID”或“买家ID"的 Jira 项目中可以直接使用“客户ID”实现。所以，当需要创建自定义字段时，我们一定要看下是否有现有字段可以使用，或将现有字段改造成“通用名称”以达到“复用”的目的。

此外，这个原则也适用于“问题类型”、“界面”和”工作流“等的设计。笔者见过将”Jira任务“区分为多个问题类型：开发任务、测试任务和普通任务等，如果这些任务的工作流和界面无法统一，那么可以这么设计。如果这些任务的工作流和界面几乎一样（可以统一），那么更建议使用单独的自定义字段”任务类型“来做区分，这样简化了实现方式，减少了后期维护成本。

3. 慎重选择字段“类型”

由于字段类型一旦选中，以后将无法修改，除非新建一个字段。笔者曾经接到一个需求：在提交发布审批流程中，每个 Jira 只能对应一个应用名称（按应用来提交申请的场景）。自定义字段“应用名称”的类型为“选择列表”，按需求应该设计为“单选”。但是考虑到“扩展性，最终将该字段的类型设计为：选择列表（多选），因为这个方案既能应对按应用提交发布申请的场景，也能应对按实际需求或项目提交发布申请的场景。

4. 使用“项目上下文”配置不同的选项值

场景：不同的 Jira 项目都需要使用自定义字段“产品分类”，但是每个项目的“产品分类”的选项值不尽相同。那么，我们该如何设计 Jira 来适配这个场景呢？

可能的解决方案：

• 使用一个“产品分类”字段，包含所有项目用到的选项值，该方案会对用户造成困扰，可能会选择错误的“产品分类”；
• 根据不同的“产品分类”列表创建多个“产品分类”字段，命名为：A产品分类、B产品分类等。该方案会造成冗余，影响 Jira 性能；
• 使用“项目上下文”给同一个字段在特定的 “Jira 项目” 和 “问题类型” 下配置不同选项值，操作路径：配置 --> 问题 --> 字段 --> 自定义字段 --> 配置 --> 配置自定义字段（如下图）；

5. 沉淀通用的 Jira 配置模板

随着组织规模的扩大和实际业务的扩展，相关流程和 Jira 配置也在不断进化，从刚开始的尝试逐渐发展成熟，进而演变成组织的一些通用配置，例如：针对产品迭代管理的 Jira 敏捷项目管理配置，这套配置可以直接拿来管理新的产品线。在创建 Jira项目时，我们可以选择“创建与共享配置”选择一个标杆项目，或者使用插件“ Delegated Project Creator for Jira”从通用模板创建。另外，不要修改默认配置，可以从默认配置“复制”，然后来修改。如果有多个 Jira 管理员，那么需要对齐配置的命名规范。

6. 使用简单且可扩展的 Jira 工作流

我之前有听到过一个 Jira 工作流设计出 20+个状态，“完美”匹配现实中的业务流程。其实，过于规范的工作流会“怂恿”低效的行为。我也见过 “freestyle" 的 Jira 工作流，任何状态之间都可以随意转换，过于自由的工作流难以沉淀下来，也会影响数据度量的准确性。有效的软件开发依赖于人及其沟通，然后才是用工具辅助跟踪过程。我们使用 Jira 帮助沟通，但别使用它做不必要的工作。尽量使用简单的工作流，因为每增加一个状态都会增加更多的转换动作和复杂性。

写在最后：

从普通 Jira 用户转变为 Jira 配置管理员，一路走来，跌跌撞撞，踩了很多坑。但是通过不断地学习和实践，我逐渐领悟到 Jira 的设计理念和精髓，并通过分享与很多人建立起连接，这是一个很令人愉快的事情。同时，我也看到，很多公司由于缺乏专业人员的指导和最佳实践的指引，在导入 Jira 过程走得并不顺利，过多的“反对声音”导致最终的“夭折”。在我看来，行业上的项目管理工具的功能大同小异，更关键的是工具背后的方法论和思想。如果大家不理解它们，即使尝试不同的工具也无济于事。

如果觉得这篇文章不错，请记得点赞、收藏和分享，也欢迎加我个人微信交流：craigyoung1985，请备注：姓名/城市/工作岗位。