道生一，一生二，二生三，三生万物。 --《道德经》

如果说第一节的指导思想是管理之“道“，那我们本节的核心配置就是**Jira系统之”道“**了。有了核心配置，才有后续的各种管理方法的实施可能。本节的核心配置包括下面几点：

项目
用户组
问题类型
字段配置
工作流

项目（Project）

项目的主要用途是作为数据的隔离。但实际上项目做到的数据隔离还是通过逻辑隔离，根本来讲还都是存储在同一张表中的数据。项目列表

上图拆分出了三个项目，分别用于产研中心，支持中心（外部），管理中心（高层）为了达到数据隔离的目的，需要配置的就是

配置了权限的用户才能访问指定的项目

下面还有针对问题、评论等权限设置，细化到操作比如：分配问题、关闭问题、创建问题、删除问题等。

用户组（UserGroup）

这里主要讲的还是组的部分，我理解的用户组的用法主要还是行政组织架构+角色职能多级组合。你也可以根据你希望管理的维度设置多级用户组。 Jira原本实际上并没有多级概念，所以我的实现方式实际上就是“前缀法”，上图：

第一级：org代表是一个组织架构，还有其他如：jira（jira系统角色）、auth（权限角色）第二级：pd代表行政架构，大部门或者中心：product&develop 第三级：代表角色或者职能，比如：leader（管理岗），coder（编码人员），前端（frontside），后端（serverside）第四级：代表二级部门，比如前端分为h5（h5）和原生（native）中间用连字符隔开。这样的好处是我们很容易理解和记忆，在JQL输入语法时，也能够很好的利用语法提示。多层级都有用户组，这样在添加用户的时候会稍显麻烦，但是会方便后期根据多种维护进行数据筛选。添加用户我们一般也是指定某个用户作为样本，添加同样的用户组，不会遗漏。

问题类型

问题类型区分为下面几大类：

异常：内部BUG、线上异常
- 内部BUG是在测试环境产生的异常。
- 线上异常是在生产环境产生的异常。
职能任务：Epic、Story、Task、新功能、子任务、测试
- Story、新功能是用于产品的可实施需求与过程中需求区分。
- Task是研发内部发起的优化或者改进需求。
- Epic是大型任务的集合。
- 子任务是普通研发人员正常的拆分任务项。
- 测试是测试人员编写的测试用例和测试执行。
非职能任务：日常综合事务
- 日常综合事务是请假、周月会等事务性工作。
外部任务：服务工单
- 服务工单是外部客户服务、销售、技术支持统一支持格式。

总结：

外部数据来源多样，情况也很多，尽量保证单一规格有利于信息收集和反馈。
异常区分环境，有利于确认品质，以及不同的工作流程。

字段配置

自定义字段是Jira一定会使用的功能，针对不同的环境和业务流程我们一定会添加其他信息。本节针对我们自己的生产流程介绍几个我们感觉比较有代表意义的字段。

affectedVersion 与 fixVersion

影响版本与修复版本是系统提供的自定义字段，字段含义也是比较清楚的，影响版本能够明确某个BUG可能影响到哪些版本，修复版本是指会在哪个版本修复问题或者添加特性。在我们的使用过程中，放弃了影响版本直接隐藏了这个字段，因为会造成大家的困惑和工作量。你需要追溯代码去明确影响，使用者也需要了解两个版本字段的意义，造成某些歧义。所以在迭代过程中，唯一意味着问题归属版本的字段就是fixVersion。另外，我们除了常规的迭代版本，还设置了一个长期版本号 hotfix 用于修正的发布标记，并且设置了修正的状态【修正待发布/修正已发布】和修正发布的日期来构建修正发布的流程。

开始日

Jira的系统字段中有duedate（到期日）这个字段，却没有开始日，可能开发者认为所有的任务新建了就是要开始，所以只需要关注结束时间。但是我们很多任务都是要事先安排计划，需要明确开始结束时间，所以我们建立了开始日这个字段，用于完整的规划。

责任人

Jira默认有报告人和经办人两个用户字段，但是实际生产过程中常常涉及多流程环节多人同时进行，所以我们添加了一个多用户字段称之为责任人。在常规迭代任务中，会自动添加新建了子任务的用户，也可以事先指定需要参与的前后端研发、测试、产品等人员。在BUG中，会在工作流中在解决问题时自动添加当前操作的用户作为责任人。

任务持续时间（需要插件）

这个字段是计算某个任务开始结束时间之间的差值，用于我们观察发现某些延期了比较久的任务或者持续时间很长的遗留BUG。这种计算字段的类型是ScriptField需要ScriptRunner这个插件提供支持。

工作流

工作流与任务类型

针对工作流的设置，我们的建议是不同的问题类型，不同的工作流。

可以看到我们的系统中设置了多套工作流，这样能够根据不同的需求设置不同的工作流节点和其他设置。

工作流设置实践

以一个例子说明工作流状态与命名的设计建议

状态是分为三种颜色，蓝色：待办，黄色：进行中，绿色：完成。某个问题一定只会处于某一个确定的状态，会在问题的界面上直接显示。除去一开始的待办和最终的完成，中间所有的环节，都分为进行中和完成两步。正常的工作流程完成之后还要等待下一环节的人员继续处理，所以单环节的完成状态颜色设定为蓝色。测试比较特殊，测试完成之后是可发布状态，所以可以设定为绿色。这就是状态的设置建议。命名就是针对状态和转换：状态的命名建议是 XX中：进行中，XX完成：阶段性完成。转换是连接源头状态和目标状态的线，在问题的界面上，实际上就是一个一个的按钮。建议的命名是以转换到某个阶段进行中状态时以转向+目标阶段，转换到某个阶段完成状态时以完成+目标阶段。转换这么命名的好处有两个：

不用特别考虑，利用统一规则命名，整体系统风格延续。
当其他工作流需要驱动工作流时，不同的状态都可以以名称方式来驱动到目标状态。（比如：图示的工作流中，待办、UI设计完成、测试中都是可以转向研发中状态的，当命名都是转向研发的时候，我们子任务驱动主任务流程变化的时候，只要建一个驱动规则，调用“转向研发”转换，在上述的多个状态都可以直接转到研发中状态）。