产品
目录
我们仍然以这张图作为开头，之前已经讲了，Project创建、问题相关、字段相关、界面相关的内容。接下来就是最重要也是最复杂的工作流相关的内容。
以前的文章中曾经介绍过工作流的思路，主要是2点：
工作流服务的主体是问题（Issue），也就是Jira当中的核心载体。工作流中有两个核心概念：转换（Transition）和状态（State）。
我们用最简单的一个工作流来解释一下。
在上图中，TO DO、IN PROGRESS、 DONE表示三个状态，注意三种颜色也代表了其中的含义，蓝色代表未开始，黄色进行中，绿色完成。
当你需要在流程中添加一种新状态时，会需要选择三种颜色之一。
连接两个状态的线，就是转换，意义就是通过这个行为，将问题从状态1变为状态2。
状态是一个结果，是由通过执行转换得到的结果，所以我们可以在转换执行时定义大量的操作，下图就是工作流在选中转换时可操作的内容。
图中我选择了 “转至进行中” 这个转换，右侧出现了五个选择，我们依次解释一下：
看一个例子吧
这里的用法就是标题和提交按钮的国际化的键值
可以关联到Crucilbe和Fisheye对代码分支和CodeReview自动转换执行。
只有条件被满足，转换才可以被执行
这里包含Jira自带和插件增加的一些条件
类似表单提交时的验证脚本，可以进行填写有效性的确认
转换成功执行后，自定义一些操作。
我们的自动化的流程推进都是需要后处理功能介入。
给大家看一个子任务的后处理功能触发自动工作流的例子：
自定义工作流需要从我们实际的管理需求出发，每个团队的管理方式方法不同，自然问题类型和工作流也不相同。我在这里提出研发管理实际过程中整理出了四种工作流。
这样四种工作流，基本能够覆盖到研发管理工作中的相关流程和角色。
主任务概念包含故事（Story）和任务（Task），故事一般是由产品发起对应平常概念中的需求（主要是功能性需求，当然也可能包含非功能性需求，但是一般都会能够让用户感知到），任务一般是由研发推动的发起的工作（例如代码重构、服务拆分、性能优化等，用户可能无法明显感知的内容）。
主任务就是一个研发团队的核心工作内容的概括，所以工作流是需要包含研发团队内的所有角色，产品、设计、研发、测试、运维等。一般工作任务也是顺序从各个角色流转的，所以可以将工作流划分成这些角色，每个角色都设置待办、进行中、完成这三种状态。其中完成可以设置为下一个环节的待办，这两个状态可以考虑合并为同一个。
还记得我们的研发管理原则之一就是简化操作，实际的任务执行者不需要了解整体复杂的设计与逻辑，通过简单的操作就能够驱动整体流程前进。这就是要依赖子任务这个概念。
在我们的研发团队中，所有的人员具体的可执行项都只能以一种类型记录，就是子任务。子任务的字段精简，只包含必须的内容。流程简单，只需要包含待办、进行中、完成。由于子任务新建后默认就是待办，所以正常的操作只会包含2个行为，进行中和完成。人员事先用分组进行标记，通过简单的进行中和完成的状态的切换，就能够推动各自角色的主流程状态变化。
Bug是研发质量管理的重要形式，Bug的提出方一般是QA，接收方大部分是研发，也可能是产品。在Bug的工作流过程中，流程其实还是比较清晰的，就是围绕Bug的解决和验证，在提出、接收方之间流转。我们要优化的点在于，能够实现流程的人员自动转换，无需手动指派。
就像我们写代码，分支循环时都会需要一个默认选择，这个默认选择就只要最简单的待办、进行中、完成即可，甚至只需要待办和完成，大家可以根据实际情况来确认。
工作流的设计中有一个重要的前提就是用户组的划分，用于对角色的区分。
接下来会对上面的四种工作流进行详细的说明，涉及到一些设置或者脚本的地方也会尽量贴出明确的图例或者代码。
主任务的工作流覆盖到所有角色，所以是最多状态的一个，先来看图。
这个流程中有11个状态，一开始是默认的待办状态（TO DO），接下来大家其实能看出，根据角色分成了几个区块，最右侧是产品，接下来向左依次是UI设计、研发、测试，最终是完成。
这里有几个设计点和大家一起讨论一下：
主任务的状态很多，但是特殊的配置其实很少，我在这里只有一个特殊的后处理功能设计，场景如下：
我们有研发中心和客户支持中心，客户支持中心可能有一些外部客户的Bug或者建议会转为内部的研发任务。我们会使用“工单关联”将研发中心的Story与支持中心的工单关联，当研发内部的Story执行“转至完成”后，变更关联工单的状态。
这个功能需要安装一个插件JMWE，提供了 Transition linked issues 这样的方法。
这里的配置比较清晰
第一行选择的是要触发关联问题的什么转换（可以通过名称或者ID），下面选择的是链接的类型。
下面Transition screen的部分，我们将“经办人” 修改为 “报告人”，意思就是工单已经发布上线，谁报告的这个问题已经可以做后续的跟进了。
最后会在对应的工单下做一个评论：内部研发流程已经完成并且发布。
主任务本身是管理方法的体现，为了将流程中的各个角色串联起来，并且能够站在较高的视角跟进相关任务推动流程迅速衔接。
所以主任务正常是不会有人去维护的，也就是不会有人主动的管理主任务的状态，大家都只是看。
如果说主任务是复杂而简单（状态多而复杂，但是背后的逻辑简单），子任务就是简单而复杂。这句话怎么理解，我们先来看子任务的工作流。
看这个图基本上就明白，我完全没有调整过这个最简单的工作流，而且这个工作流只有三个状态，排除掉初始的待办状态，正常只有两个状态可以切换。所以子任务是简单的。
接下来我们看复杂的意思
从待办到处理中这个转换，我们一共有15个后处理功能，除去系统自带，我们也有9个自定义的后处理功能。
同样，我们一起来讨论一下其中的一些设计点：
子任务主要的转换是两个，从待办到处理中，以及从处理中到完成。我们的所有后处理功能都在这两个转换上。
待办到进行中一共9条自定义规则我们一起来看：
1的规则是使用了设置字段值这个功能，意思就是要在点击开始的时候，将任务的开始日期置位当前时间。
目的是希望保持子任务的开始时间为实际的时间，不需要操作人手动的调整时间。
2的规则也是使用了设置字段值，是将子任务的解决结果设置到父任务。
目的是希望将子任务的结果能够在父任务体现，从而让管理着了解是否存在特殊的解决结果。
3 4 5的规则也是使用了设置字段值，都是对责任人字段的维护。
目的是希望将子任务或者主任务的责任人字段添加当前涉及到的人员，主任务的责任人字段是为了维护所有参与者快速确认人员范围。子任务则更多是为了明确责任。
12-15的规则使用的是Transition parent issue (JMWE add-on)，这是插件提供的。是触发主任务流程流转。
目的是通过子任务的流转推动主任务流转。这里会比较复杂，我们来看一下具体实现，下图
这里我们分为4个部分：
设置触发主任务流转：我们要讲到命名的原则在这里的作用了。这里触发主任务流程的前提，还是要求当前主任务的状态是在目标流转的起始点的。也就是说如果现在的工作流是 A→B→C，如果我们期望执行A→B，那当前主任务的状态必须在A才能顺利到达B，否则不会产生效果。我们的命名规则里，把所有转向某个状态的流转都命名为“转至xxx”，这样一个方法就能够触发多种起始状态下的流转了。
设置字段值：这个已经是比较常规的设计了，这个流程中没有需要设置的内容
添加评论：所有的自动化流程执行，都会自动添加一条评论到主任务下，记录由谁推进到什么状态。用于后期的记录跟踪
设置执行条件：这个实际上是最核心的，后处理功能会按照顺序全部执行，应该执行哪个才能够顺利的推进主任务流程流转，只能通过执行条件来判断。这里面主要还是通过当前用户的用户组来判断角色，从而决定推进主任务的什么流转。下面是从产品、设计、研发、测试四个角色的子任务开始脚本：
这里是判断当前用户是在系统用户组 org-pd-product-pm （产品经理） 中的话，并且任务类型没有特别设置。
用户分组大家好理解，任务类型是什么意思呢？
我们发现因为所有人的工作都要落地成为子任务，有些子任务实际上并没有推进流程状态变化。比如产品经理的需求预研、可行性分析等，实际上还没有推进需求落单，暂时不应该将主任务推进到产品设计进行中这样的状态。这种情况可以通过补全主任务流程状态来弥补，我们是通过另外一种方式，就是设置特殊子任务类型来避免推进流程到错误的状态。所以我们形成了内部约定，一旦子任务的任务类型设置了值，就不会推进流程流转。
这里的自定义规则有5条：
6-10 的规则使用的是Transition parent issue (JMWE add-on)，不复述上面的内容了
这里主要只有后处理功能，我们就拆解一下说明
子任务的核心，就是简单而复杂。简单的流程才能更好的在团队内推行，复杂的后台逻辑才能满足管理层的管理需求。
Bug是研发测试过程中的质量缺陷，流程不会复杂，主要是自动化的流转和管控要求。
状态只有四个，和子任务相比，实际上只多了一个状态“已解决”。默认Bug是由测试提出，新建之后状态是“待办”，研发开始处理转换为“进行中”，研发完成后转换为“已解决”，测试会跟进“已解决”的Bug，如果确认解决则转换为“完成”，如果未解决则转换为“进行中”。
关于Bug，最重要的后处理功能实际上在于“进行中”和“已解决”直接来回转换，所以我们来看一下 “解决问题”和“未解决”两个转换的后处理。
这里需要关注的主要还是责任人的处理。只有在解决结果是“Done”（其他一般是无法复现、网络环境异常、需求设计如此等）的时候，才将当前操作人作为责任人。这个是为了确认研发的责任归属，只有研发认可并且实际有处理的Bug责任才需要归属于研发。
经办人的会自动分配给报告人，这样避免研发手动指定经办人。
未解决的转换意义在于说，研发提交给测试的Bug实际上并未修复，需要退回给研发。这里是需要累加“退回次数”这个自定义字段，
经办人也是需要将当前人员直接指派给之前流转过来的研发人员。使用的是“Assign to last role member (JMWE add-on) ”插件提供。
这个Project Role，是需要我们在项目设置的。
可以在项目设置中这个菜单下进行设置。
Bug的整体逻辑相对来讲简单很多，主要是方便了研发和测试之间的流转，并且尽量保证转换时人员分配的自动化。
默认任务这里不再过多说明，正常的“待办-进行中-完成”的流程即可满足。
至此，所有的工作流设计介绍完成，其中涉及到脚本的部分都是使用Groovy语言编写，其中最难的部分还是在于确认如何获取需要的字段在Groovy中的获取方式。
主要还是通过这里的一些帮助工具来进行探索。
155-2731-8020
