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

時間 2020-07-12

標籤 atlassian action jira 推薦插件简体版

原文原文鏈接

前面的幾章基本已經完整構建了Jira的管理平臺，而且有了一套比較完成的制度和方法。可是優化是永無止境的，咱們做爲研發管理人員，須要讓系統使用起來更加高效和便捷。爲了達到這個目的通常有兩種途徑，插件和開發。咱們本章再推薦一些插件，下一章會介紹一些很輕量的二次開發，無需修改到jira自己而是使用接口或者數據庫的。本章的推薦插件其實是暗含了不推薦的同類型插件，由於我在測試過程當中，同類型的插件也試用了不少，做爲一個排雷說明也一塊兒告知給你們。滿分5星html

效率類【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的現象。咱們要重點確認這類的狀況，可是單純用責任人字段沒法排查出多責任人的狀況。因而咱們設計了一個計算字段，返回值就是責任人字段的長度。參考截圖 api

其中值得一提的就是字段類型的定義，同時能夠指定issue進行驗證，下面也給出代碼。app

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()

配置優化

配置優化的定義是針對管理員在進行設置時，能夠增長或者提高配置能力的一些插件。dom

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

相關標籤/搜索

atlassian

軟件推薦

硬件推薦