1. 程式人生 > >Atlassian In Action-Jira之推薦外掛(四)

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