前面的幾章基本已經完整構建了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個月左右的時間。
我們從指導思想、核心配置、核心插件、推薦插件一路走來，基本已經到了一個普通的研發管理人員能夠做到的極限了。這樣的環境應該已經能夠滿足大部分的公司需求。但是作爲一個研發出身，現在也還在編碼的研發管理人員，我們後面能夠提供更強大的管理工具能力，需要我們開始編碼了！下一章就是二次開發，打造我們自己趁手的研發管理利器！