道生之，德畜之，物形之，势成之。 --《道德经》
Jira的道在于构建了整个环境和思维模式，也赢得了市场的认可，成了一种势。无数的厂家便成了Jira的海洋生态当中的重要组成部分。有些厂家的插件是提升了Jira的体验，有些则是强化了特定功能。这里只推荐三个算得上必须使用的插件。
- BigPicture
- Jira Misc Workflow Extensions
- Tempo
围绕这三个插件，我们能够搭建起研发管理的整体路线和迭代管控视图，简化流程，完善管理制度。接下来就介绍每个插件的场景和使用方式。
BigPicture
我们通过一张图形成一个大概的印象
我们当时选择这个插件期望满足的场景有下面几个：
- 能够直观的查看人员和迭代的工作安排，进度
- 能够了解人员的工作饱和度
我们项目管理常用的软件就是微软的Project，所以我们选项目标也是按照这样的思路来挑选的。最简化的概念就是甘特图。
BigPicture特点介绍
管理员管理菜单
当中有设置的必要的应该是Working schedule了
设置放假和周末，这样在计算任务起止的时候能够在甘特图中正确的显示，其他我没有做过多的设置。
任务列表
从上图可以看出甘特图的组织形式分为4层。
- 项目（Project）
- 版本（fixVersion）：注意是根据父任务的修复版本确定的
- 父任务（Story/Task）
- 子任务（Sub-Task）
任务管理
在甘特图的界面可以进行任务的管理。
可以拖动任务的两端进行开始和截止日期的调整，也可以直接拖动整个任务进行任务的调整。
任务的进度是通过下面的三角标识进度，这个计算是使用实际投入的工时与预计工时直接的比例。
蓝色的线是在日期栏直接左击，就可以设置一个时间线，默认是设置在选择日期的开始。可以用于设置迭代里程碑。
设置
显示内容的设置界面如下：
可以看到有四种方式可以混合使用：
- 面板
- 过滤器
- 项目
- JQL查询语句
任务列表界面上元素都是可以根据实际系统中设置的字段进行调整的，如下图所示：
绿色的是自定义字段，灰色的是系统字段。自定义字段基本都是单纯的显示，系统字段会有一些其他的效果。
最佳实践
- 一个甘特图面板最好值针对一个迭代，使用过滤器来方便的管理迭代边界。能够很清晰的看到所有任务的排期与时间里程碑控制。
- 任务管理的权限需要控制，可以由SM、职能小组负责人统一管理，因为一般都涉及前后端测试的配合，进度一旦变化就需要全局调整，而且可能会影响迭代里程碑时间点。
- 由于迭代任务分配时往往是连续的，前期的任务调整可能会导致后续的任务连锁调整。在甘特图面板可以很方便的进行调整，而不用一个一个打开任务进行修正。
- 如果有纵向职能管理角色（比如前端、后端有专门的部门和管理人员），可以建立部门的甘特图面板进行部门内的排期管理和调整。
Jira Misc Workflow Extensions
这个插件在前端没有任何感知，知道Jira系统中存在这个插件的基本也只有管理员了。但是对于管理员来说，这是流程推进、串联的最重要的工具了。
它的作用是在工作流的流转过程中可以附加其他的操作，列表如下：
可以看到主要有赋值、分配人员、评论、触发其他流转环节、自定义脚本等等，而且可以针对问题本身、父问题、关联问题。基本能够涵盖日常应用的场景了。
最佳实践
我讲一下我实践过程中，比较常用的几种场景：
自动分配
使用到 Assign to last role member 或者 Assign to role member 。场景例如bug，当测试发现一个bug时，可能并不直接指定具体研发，而是提交给研发管理小组确认之后再分配给具体研发，具体研发人员修改完成后，点击修改完毕按钮，转发给测试。测试若发现bug没有完全修复，点击退回研发按钮，直接退回对应研发（而且可以累积退回次数）。
这里面的几个步骤：
- 提交给研发管理小组，可以随机指定研发管理角色中的某一个人来处理
- 修改完毕，会追溯到测试角色的最后一个经办人，并且将问题分配给他
- 退回研发，会追溯到研发角色的最后一个经办人，并且将问题分配给他
为何要追溯某角色的最后一个经办人？因为内部可能还存在多次指派，甚至对bug进行分析后发现不是后端bug要指定给前端研发。测试不用自己分析要退回给谁，让流程来判断。
自动化流程
使用到 Transition linked issues 和 Transition parent issue 。我们最早就讲过，整个系统是子任务驱动的，具体人员只用关心和管理自己的子任务（子任务只有开始和结束两个简单状态），但是父任务涉及多人合作和角色含义，状态和节点可能会有几十个，无论让谁来管理都是很困难的。场景，一个父任务需要UI、产品、前端、后端、测试共同完成。其中可能产品先行，完成之后交付给UI，完成就可以前后端介入，研发全部完成后才能交付给测试执行。
这里面思想其实很简单，就是子任务工作流+角色。首先对于不同角色要区分出合理的用户组，当每个人完成任务时，判断他自身的角色从而触发父任务的状态流转。比如产品完成任务时，转至方案设计完成，研发完成时可以判断当前父任务下是否存在测试子任务，若存在转至研发完成待测，若不存在说明不需要测试转至研发完成无需测试。
这里给大家一个小小的建议
当你添加自动化工作流时，这里时可以选择名称或者id的，id就是一串唯一数字，当你需要精确触发工作流时可以指定。但是像上面描述的那种情况，其实并不能完全判定当前的状态是什么。比如需要产品协助时，产品会先完成任务之后研发才开始，这时候研发介入的上一环节是设计方案完成，但是也存在不需要产品研发直接开始比如研发内部优化，这种情况下研发介入的上一环节是待办。如果这时候指定的具体的工作流，起始状态不正确就无法执行。所以建议是使用名称，而且建议规范是转至+下一环节名称，比如到研发这个环节，无论从待办或者方案涉及完成，甚至测试退回，都成为转至研发，这样我们只要写一次post function就可以满足多种情况了。
注意：即使使用名称流转，也必须满足该流转的起始和中止状态满足当前情况。例如如果我方案设计中如果没有指向研发进行中节点，即使我尝试触发该流转也是无法执行的。
Tempo
研发在质问我，已经9012年了我们还要使用工时这种low爆的形式来做绩效管理么？每天凑满8小时工作时间对于管理层就这么重要么？你们的能力仅仅就是看着这个人工时有没有记录好么？
如果你这么想，说明你没有想过研发管理到底该做什么。研发管理控制三要素：时间、成本、质量。控制的目的是提升，如何提升？必然是发现问题，改进才能提升。最简单发现问题的地方是工时分配，而不是某个员工8小时工时本身。某个迭代中，那个story投入的工时超出成本，哪些人的bug工时投入超出正常比例、哪些人的线上问题投入工时较高、整体研发部门投入在非研发工作上的比例是多少，要不要优化。这些才是我们应当去关注并改进的。当所有人员只有3-5个人，可能这个数据受个人影响比较大，但是当人员超过30-50人时，个人少报或者没有正确填写的影响就已经比较小了，我们要观察的是趋势，大项的时间投入正常都是有记录的，这样基本就能够反应真实情况了。
所以Tempo作为目前时间管理最好的工具，在研发管理中重要性相信各位管理人员都有认知了。
tempo当前最新是9.4.2版本，我使用的是8.15.3 。我尝试升级过一次插件，结果大家都不习惯新的界面，我不得不退回老版本。
配置
全局配置中有几点说明，我们是子任务驱动所以工时不允许记录在父任务。但是只有一个任务下有子任务的时候才是父任务，否则就可以记录工时。
Work Attributes是设置工时填写面板的自定义字段
注意：这里的字段只有通过记录工时按钮呼出的界面才有，比如完成任务时填报工时的界面是没有自定义字段的。
工时表
v9去掉的就是这个工时表，这个基本上是我们最常用的功能了。所以去掉之后大家都不知道怎么用了。
用户这个地方的下拉框可以选择如下几种选项。其中比较难理解的是账户这个概念，tempo里面实际上是有成本概念的，就是通过账户当中的金额来管理，不过我们没有使用过。
常用的几个是用户（分析单个用户的工时分布），团队（每个小组整体任务工时分布），高级（指定过滤器查看任务工时分布），问题（查看单个问题的人员工时分布）
时间区间可以任意指定，查询出的结果可以直接导出excel用于做透视图之类的。
Reports
v9主推的就是Reports操作的内容和界面形式应该是更加优化，上面的时间区间、过滤器设置（可以多选），分组可以多选和排序。
这个我们用的比较少，主要会针对某个具体问题、或者较大的Epic相关的项目站会、总结会时，分析人员工作进度和使用。
总结
上述三个插件加入到Jira之后，我们完成了迭代整体控制、工作流实施、研发管理规范与提升三方面配置，基本已经可以开始组织一个研发团队为了同一个既定目标按照统一规范流程进行开发，而且尽量简化过程降低研发非研发类工作的占比。但是我们还是可以使用一些其他的插件来提高研发管理整体效率。另外必须说一句，这些插件的仪表盘可用插件没一个能用的。