Jira实战 | 创建你的工作流

工作流是每一个Issue生命周期所遵循的一个标准的状态（步骤）和移转（步骤间的移动）。

状态取自于一个idea从“概念”到“完成”，或是取自于一个Bug从“提交报告”到“在生产环境修复”，每一个项目可以有自己的专属的工作流，每一个项目内的问题类型能有自己专属的工作流，例如:

• 任务的问题类型可能需要一个非常简单的工作流，其中的状态可以使用如“开始(Open)”、“进行中(In Progress)”和“关闭(Closed)”。 

• 问题类型为新功能时，可能需要对此类问题在软件开发过程的步骤中增加其它的状态。  

• 测试、代码审查和部署的状态可能需要较为复杂的工作流。 

 

 

命名你的工作流

工作流名称应该用来描述整个生命周期过程的类型，而不是用项目名称来命名，例如: “任务生命周期”。

工作流方案的名称应该能够描述生命周期流程群组的类型，例如：“研发生命周期”。

状态名称应该要精简并且能够反应当前状况。

 

创建工作流

下面的步骤描述了创建工作流的最佳实践:

1.  在创建一个新的自定义的工作流之前，让用户来向你解释他们实际的生命周期流程，工作流应该要尽可能地简单。

2.  首先，绘制(可能会在纸上)一个工作流来确保该工作流具备的逻辑意义并且所有的向前向后流程都涵盖了，你能使用"自定义工作流文档"的模版来做为沟通和记录工作流的方式。

3. 在绘制工作流之后，尝试将工作流用文字写下来，这个能够发现你忽略的额外需求。

4. 包含逻辑上的向后转换流程，这样才能让用户能够自行管理，将自己的问题进行返工。

5.  给予用户在适当的时机抛弃或是停止进行问题的权力。

6. 让项目级别的管理员有适合的选项去修正不当移转的问题。

例如:  包含“重开(reopen)”的移转按钮在最后的状态上，用来处理不正确关闭的问题。(由于这是一个维护性的操作，请将此操作交由项目管理员进行处理。)

7.  谨慎的使用移转条件，如果需要使用条件的时候，为了维护上的便利，记得设置给项目角色而不是个人。

8.  使用校验和后处理功能等自动化来精简用户手动的工作。

• 当转换到“信息提供”或是“需要校验”的状态类型时，自动指派问题给报告人。 

• 在“分配(Triage)”的状态类型时，自动指派问题给项目负责人。

• 当子任务开始行进处理，自动将父任务移转到“进行中(In Progress)”。

9.  命名你的状态:

• 命名好的状态让状态能够反应当前的状况，好的状态名称能够立即让用户知道发生了什么事和问题在工作流的哪个状态，例如：

1. "Pending Review"

2. "InReview"

3. "Being Reviewed"

4. "Awaiting Review"

• 让所有的状态名称简单并且容易理解问题发生了什么事；长且多字的名称往往会造成查询上的困难，并且会在某些界面上被截断。 

10.  为转换动作命名:

• 移转状态的名称必须简短且能够反应所采取的动作。

• 好的移转名称能让用户立即地知道一个问题在执行什么样的动作。

例如:  对于一个问题在"PendingReview"的状态上，好的移转名称应该是："Review Complete"，如果你需要"pass/fail"状态，也就是说在移转前必须通过一个测试，好的移转名称应该是：简单的"Pass"和"Fail"。 

• 不好的转换名称会让用户混淆而不知道该如何移转。

例如:  "Review"。移转的按钮应该要能表示动作的开始和结束，"Review"这个词有点模棱两可的，如果用户点击"Review"时，这究竟表示应该开始一个复审？还是已经发生复审?

 

不要这么做

• 使用超过实际需求的状态和移转。 

• 使用你从来不会查询或提交报告的状态。

• 在问题还没到实际最终的状况使用“已关闭”状态。(“已关闭”应该只的是没有任何工作需要进行)

• 创建极为特殊(ultra-specific)的状态名称或是使用错误的时态。 

例如:"Pending Review by Marketing"或是"PendingReview by John"这两个太特定某个群体会导致跨项目的工作流非常难维护和分享。

例如: "(已复审)Reviewed"这个词在时态上是"死胡同(dead end)"，也无法让用户知道接下来会发生的事情，使用过去时态的字更适合在转换的用词上使用，而不适用于当前状态的用词上使用。.

• 创建多个状态都表示"已关闭(Closed)"。

• 弄不清楚"Resolution"和表示最终状态的"Closed"状态。

例如: 不使用类似"已抛弃(Abandoned)"或是"已拒绝(Rejected)"的状态，而是使用"解决结果"字段来指出问题在"已关闭"状态中的"how"或"why"。

• 创建"临时(temporary)"或是"结束(dead)"的状态，来表示问题可能会在不确定的时间内出现。

例如:"On Hold” (如果负责人主定且定期检视该问题的"On Hold”状态的话，这个状态是非常有用的。

建议

在一开始，让工作流越简单越好，直到你发现现有工作流的不足之处或是需要特别关注的流程步骤。

先在测试环境上建立工作流，接著当你验证所有的变更，导出工作流然后再导入工作流到你的生产环境里，这样可以避免用户因这些测试问题和移转通知上收到一堆垃圾邮件。

小贴士

为了修改使用中的工作流的状态，你必须需要先使这个工作流无效(inactive)(将他和当前项目和问题类型除去关联)，最简单的方法就是去复制使用中的工作流，在副本上进行变更，接著再将副本工作流和你的项目进行关联，最后删除原始的工作流。

任何无效(未分配)的工作流都会被列在“无效(Inactive)”的标题之下，位于工作流的管理页面的底部。

 

自定义工作流

自定义工作流操作非常简单，但是创建超过你实际需要的结构很容易陷入困境。

例如，任务需要非常简单的工作流，使用类似"Open"、"In Progress"和"Closed"就好；然而新功能的问题类型可能需要其它实际软件开发流程的状态；测试、代码覆审和部署的状态可能会需要更复杂的工作流。

 

分阶段法

你的公司雇用了一位新的JIRA管理员 招聘过程需要候选人在录用和辞退前去申请和面试，这是一个简单的流程：

开始->审核申请书->面试->关闭

然而在背后，在这些主要的阶段的过程，发生了很多其他事件，例如:  

在“审核申请书”阶段:

• 人力资源部门正在审核所有申请书的文档，(例如：是否提交了所有需要的的文件?申请人是否拥有必要的证件、证书或是安全许可?他们的薪资需求是否落在职位范围内?)

• 招聘经理确认申请人的经验和需求的技能组合，等等。

在“面试”阶段:

• HR和申请人确认日期并且给他们地址如何抵达招聘的办公室。

• 为了面试预留一个会议室。

• 招聘经理准备许多面试的问题列表。

• 招聘经理和所有的申请人进行会面并且带他们参观设施，等等。

在上述的例子中，创建面试过程所有的步骤的状态是否有用？你需要追踪会议室是否预定来面试？如果2个答案都是"否"的话，分阶段法会是更好的。如果你确实需要追踪会议室是否预定的话，你可以增加一个状态或是一些字段级别的指示作为工作流的一部分。

建议

构建自定义工作流应该在纸上开始，工作流定制化流程的最后一个步骤都应该在JIRA上创建和测试。

小贴士

如果你不需要查询“在某个特定状态的全部问题”，那有可能这个状态就不是必要或有用的。

 

关于本书

本文节选自《JIRA策略管理实战手册》，为应用程序管理员提供配置、清理和维护Jira的模板。

此实战手册包含：

• 152条建议- 帮助您设置、清理和维护Jira

• 50个工作表，以及其他相关模板、代码片段和示例

• 33个需避免的反面真实案例

• 每个管理区域的最佳实践和注意事项

• 作者作为管理员犯下的十大错误

此实战手册向您展现：

• 精心策划并得以实施的行动项

• 工作流管理的简单方法

• 如何审计及清理应用程序

• 维护和扩展Jira的方法

• 如何创建可重复的流程

• 如何远离“Jira沼泽”

 

推荐阅读

Jira实战 | 用户访问策略

Jira实战 | 关于IssueType

Jira实战 | 关于解决结果