Atlassian In Action-Jira之推荐插件（四）

前面的几章基本已经完整构建了Jira的管理平台，而且有了一套比较完成的制度和方法。可是优化是永无止境的，咱们做为研发管理人员，须要让系统使用起来更加高效和便捷。为了达到这个目的通常有两种途径，插件和开发。咱们本章再推荐一些插件，下一章会介绍一些很轻量的二次开发，无需修改到jira自己而是使用接口或者数据库的。 本章的推荐插件其实是暗含了不推荐的同类型插件，由于我在测试过程当中，同类型的插件也试用了不少，做为一个排雷说明也一块儿告知给你们。满分5星

• 效率类【Adaptavist ScriptRunner for JIRA（☆☆☆☆☆）】
• 配置优化【Project Specific Select Field（☆☆☆☆）Default Values for Create Issue screen（☆☆☆）】
• 界面优化【Subtasks section for JIRA（☆☆☆）STAGIL Navigation（☆☆☆）】
• 移动端【Mobile for JIRA（☆☆☆）】
• 其余类【Universal gadget for JIRA（☆☆☆☆）】
• 报表类【无】 分类也只是我我的基于插件使用场景作出的，你们能够有不一样的理解。接下来对类别和插件以及使用的场景作个简单的介绍。

效率类

效率类目的是Jira的使用效率，这里只推荐了一款插件，几乎能够说是必备了。Adaptavist ScriptRunner for JIRA，也就是常说的ScriptRunner 。

Adaptavist ScriptRunner for JIRA（☆☆☆☆☆）

这款插件引入了脚本（Script）的概念，你能够编写本身的脚原本注入Jira的系统中运行。最简单的提高就在于JQL的提高。 插件提供了一个函数issueFunction，这个我认为提高了Jira官方JQL至少30%的可用性。

例如： subtasksOf()或者parentsOf()，括号中能够再次定义一个JQL语法用于查询一个issue清单，从而得到这个清单的全部子任务或者父任务。 若是你安装了，那你能够在 https://jira.yourdomain.com/plugins/servlet/scriptrunner/admin/jqlfunctions 查看全部的JQL函数。

另外再推荐一个用法就是Script Fields，个人使用方法是做为一个计算字段。 例如咱们内置了一个成为责任人的字段，用于断定为bug负责的人员，正常来说这个字段只有一我的，可是有特殊的状况多是多人均有责任。好比先后端都出错致使了测试提的一个bug的现象。咱们要重点确认这类的状况，可是单纯用责任人字段没法排查出多责任人的状况。因而咱们设计了一个计算字段，返回值就是责任人字段的长度。 参考截图

其中值得一提的就是字段类型的定义，同时能够指定issue进行验证，下面也给出代码。

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.fields.CustomField

/**
 * Get number of users for multiuser picker
 */
CustomField multiuserCstFld = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("责任人")
if (multiuserCstFld == null || multiuserCstFld.getValue(issue)==null)
    return 0;

return ((ArrayList) multiuserCstFld.getValue(issue)).size()

配置优化

配置优化的定义是针对管理员在进行设置时，能够增长或者提高配置能力的一些插件。

Project Specific Select Field（☆☆☆☆）

这个我应用的场景其实是多选字段的使用改进。没有用这个插件以前咱们的多选字段是这样的

若是要选择多个，须要按住ctrl才能多选。修改以后变为：

以标签的形式展现多选，同时也支持搜索。 但要记住，添加自定义字段类型的时候须要选择 Project Specific Multi Select Field 类型，而不是本来的 **选择列表（多选） **。

Default Values for Create Issue screen（☆☆☆）

这个就是自定义字段的插件了，好比说明字段，咱们会要求不一样的issue类型有不一样的模板，这样就能够经过这个来设置。 这个插件分为 Schemes 和 Field Configuration 两部分。 Schemes 用于将 Field Configuration 和项目进行关联。也就是同一个问题类型能够定义多个Field Configuration ，在不一样的项目中，出现不一样的默认值。 可是实际使用过程当中，使用者还会出现更复杂的需求，好比某些字段变化时但愿可以联动出现不一样的默认值，或者在某些类型的issue评论时也要出现不一样的模板。目前还没法支持。 假如必定须要，应该思路是使用scriptrunner。 放弃插件： Power Custom Fields/Jira Misc Custom Fields，这款彷佛也很强大，可是相似Script Field，并且比较复杂。因此在和上面插件比较后放弃。更重要的系统字段是不能够修改的，因此没法应用这类自定义字段修改的插件。

界面优化

这里主要是针对前端界面显示时能够提供一些优化的插件

Subtasks section for JIRA（☆☆☆）

这个是为了自定义主任务视图下的子任务展现，这个是以前的子任务视图

这个是使用插件设置以后的

本来使用的插件的意图就是为了可以方便任务的查看与管理，通常在同步排期、需求管理时会须要看到。 可是这个插件也存在一些问题，首先是时间格式化没法以中文地区限制，其次有时候某些任务会没法应用样式，具体为何尚未摸索出来。

STAGIL Navigation（☆☆☆）

这个插件其实是一个导航栏的自定义插件

看一下配置就可以理解大概。 我使用这个插件主要场景仍是在于，jira在安装插件以后顶部导航就会增长入口，咱们对于不一样人员分组以后，但愿他们可以看到的顶部导航栏的内容不用那么多，只关注于自身须要的内容。所以使用这个插件 对某些用户组隐藏。

移动端

Jira的使用环境仍是比较适合PC端，可是当外勤人员也须要参与时就比较复杂。咱们的环境里面涉及了客户支持、销售等外部环节，因此移动端的选择也是很重要的一环。 Jira当中最主流的就是两款 Mobility for JIRA和Mbile for JIRA。 咱们选择的就是 Mbile for JIRA。

Mbile for JIRA（☆☆☆）

做为一个移动端的app能够和Jira官方app比较一下，感受使用体验差不少。那为何选择这款，是由于Mobility for JIRA更差劲。在作选型时，最基础的一关就是数据隔离验证，咱们将外部人员和研发内部切分为两个Project，而且不能互相查看。可是在Mobility for JIRA里面没有任何过滤，能够搜索到全局全部的数据。直接放弃。 放一个截图

放弃插件： Mobility for JIRA

其余类

这里就是放不太好归类的了

Universal gadget for JIRA（☆☆☆☆）

这个插件算是个神器

因为只是一个Gadget，因此只可以在仪表盘展现，可是却可以自定义html和js，配合Jira的接口，能有不少有意思的玩法。其实有点偏向与简易的二次开发了。 场景1：公告板

全部角色的仪表盘都插入这个信息，天天打开首页就可以同步全部信息。这个作法也是很讨巧，贴一下代码能够看出

$.getJSON('https://jira.yourdomain.com/rest/api/2/search?jql=key%3dJIRA-3713',function(result){
 $("#cc_main").html(result.issues[0].fields.description);
})

使用了Jira提供的api获取某个issue的描述字段。这样就能够以某个issue做为html内容，修改以后达到发布信息的目的了。

场景二：工时与任务管理 去除了一些敏感信息，这个界面能够比对某天内某个小组人员的投入工时与待办任务之间的关联以及异常。

主要使用到仍是普通的js，以及jira提供的api接口。

报表类

从使用Jira的第一天开始就在尝试可以作出可自定义的图形化报表，可是尝试了几款插件都达不到指望的目的。 All-In-One Reports for Jira，eazyBI Reports and Charts for Jira 这两款是尝试了最屡次的软件，可是最终都没有成功应用 All-In-One图形化作的比较好，eazyBI 在自定义二维表方面作的更好。可是我尝试了好久，连最简单的合计功能也没有达成，后续就放弃了，使用了更简单的方案。

总结

从公司上Jira开始，到如今大概已经9个月了。全部人都已经熟悉而且承认了Jira，也成为了最重要的信息交换媒介。任什么时候候有零碎工做、Bug、待分析的需求，你们都会第一时间在Jira发布，而且按照对应流程执行。这须要研发管理人员不断的努力和改进Jira使用环境和流程优化，我本身测试各类插件最终造成完整落地方案大概一共花了2个月左右的时间。 咱们从指导思想、核心配置、核心插件、推荐插件一路走来，基本已经到了一个普通的研发管理人员可以作到的极限了。这样的环境应该已经可以知足大部分的公司需求。可是做为一个研发出身，如今也还在编码的研发管理人员，咱们后面可以提供更强大的管理工具能力，须要咱们开始编码了！下一章就是二次开发，打造咱们本身趁手的研发管理利器！

原文出处：https://www.cnblogs.com/pluto4596/p/11248321.html