道生一，一生二，二生三，三生萬物。 --《道德經》

如果說第一節的指導思想是管理之“道“，那我們本節的核心配置就是Jira系統之”道“了。有了核心配置，才有後續的各種管理方法的實施可能。
本節的核心配置包括下面幾點：

• 專案
• 使用者組
• 問題型別
• 欄位配置
• 工作流

專案（Project）

專案的主要用途是作為資料的隔離。但實際上專案做到的資料隔離還是通過邏輯隔離，根本來講還都是儲存在同一張表中的資料。

上圖拆分出了三個專案，分別用於產研中心，支援中心（外部），管理中心（高層）
為了達到資料隔離的目的，需要配置的就是

配置了許可權的使用者才能訪問指定的專案

下面還有針對問題、評論等許可權設定，細化到操作比如：分配問題、關閉問題、建立問題、刪除問題等。

使用者組（UserGroup）

這裡主要講的還是組的部分，我理解的使用者組的用法主要還是行政組織架構+角色職能多級組合。你也可以根據你希望管理的維度設定多級使用者組。
Jira原本實際上並沒有多級概念，所以我的實現方式實際上就是“字首法”，上圖：

第一級：org代表是一個組織架構，還有其他如：jira（jira系統角色）、auth（許可權角色）
第二級：pd代表行政架構，大部門或者中心：product&develop
第三級：代表角色或者職能，比如：leader（管理崗），coder（編碼人員），前端（frontside），後端（serverside）
第四級：代表二級部門，比如前端分為h5（h5）和原生（native）

問題型別

問題型別區分為下面幾大類：

• 異常：內部BUG、線上異常
  • 內部BUG是在測試環境產生的異常。
  • 線上異常是在生產環境產生的異常。
• 職能任務：Epic、Story、Task、新功能、子任務、測試
  • Story、新功能是用於產品的可實施需求與過程中需求區分。
  • Task是研發內部發起的優化或者改進需求。
  • Epic是大型任務的集合。
  • 子任務是普通研發人員正常的拆分任務項。
  • 測試是測試人員編寫的測試用例和測試執行。
• 非職能任務：日常綜合事務
  • 日常綜合事務是請假、周月會等事務性工作。
• 外部任務：服務工單
  • 服務工單是外部客戶服務、銷售、技術支援統一支援格式。

總結：

1. 外部資料來源多樣，情況也很多，儘量保證單一規格有利於資訊收集和反饋。
2. 異常區分環境，有利於確認品質，以及不同的工作流程。

欄位配置

自定義欄位是Jira一定會使用的功能，針對不同的環境和業務流程我們一定會新增其他資訊。本節針對我們自己的生產流程介紹幾個我們感覺比較有代表意義的欄位。

affectedVersion 與 fixVersion

影響版本與修復版本是系統提供的自定義欄位，欄位含義也是比較清楚的，影響版本能夠明確某個BUG可能影響到哪些版本，修復版本是指會在哪個版本修復問題或者新增特性。
在我們的使用過程中，放棄了影響版本直接隱藏了這個欄位，因為會造成大家的困惑和工作量。你需要追溯程式碼去明確影響，使用者也需要了解兩個版本欄位的意義，造成某些歧義。
所以在迭代過程中，唯一意味著問題歸屬版本的欄位就是fixVersion。
另外，我們除了常規的迭代版本，還設定了一個長期版本號 hotfix 用於修正的釋出標記，並且設定了修正的狀態【修正待發布/修正已釋出】和修正釋出的日期來構建修正釋出的流程。

開始日

Jira的系統欄位中有duedate（到期日）這個欄位，卻沒有開始日，可能開發者認為所有的任務新建了就是要開始，所以只需要關注結束時間。但是我們很多工都是要事先安排計劃，需要明確開始結束時間，所以我們建立了開始日這個欄位，用於完整的規劃。

責任人

Jira預設有報告人和經辦人兩個使用者欄位，但是實際生產過程中常常涉及多流程環節多人同時進行，所以我們添加了一個多使用者欄位稱之為責任人。在常規迭代任務中，會自動新增新建了子任務的使用者，也可以事先指定需要參與的前後端研發、測試、產品等人員。在BUG中，會在工作流中在解決問題時自動添加當前操作的使用者作為責任人。

任務持續時間（需要外掛）

這個欄位是計算某個任務開始結束時間之間的差值，用於我們觀察發現某些延期了比較久的任務或者持續時間很長的遺留BUG。這種計算欄位的型別是ScriptField需要ScriptRunner這個外掛提供支援。

工作流

工作流與任務型別

針對工作流的設定，我們的建議是不同的問題型別，不同的工作流。

可以看到我們的系統中設定了多套工作流，這樣能夠根據不同的需求設定不同的工作流節點和其他設定。

工作流設定實踐

以一個例子說明工作流狀態與命名的設計建議

狀態是分為三種顏色，藍色：待辦，黃色：進行中，綠色：完成。某個問題一定只會處於某一個確定的狀態，會在問題的介面上直接顯示。
除去一開始的待辦和最終的完成，中間所有的環節，都分為進行中和完成兩步。正常的工作流程完成之後還要等待下一環節的人員繼續處理，所以單環節的完成狀態顏色設定為藍色。測試比較特殊，測試完成之後是可釋出狀態，所以可以設定為綠色。
這就是狀態的設定建議。
命名就是針對狀態和轉換：
狀態的命名建議是 XX中：進行中，XX完成：階段性完成。
轉換是連線源頭狀態和目標狀態的線，在問題的介面上，實際上就是一個一個的按鈕。建議的命名是以轉換到某個階段進行中狀態時以轉向+目標階段，轉換到某個階段完成狀態時以完成+目標階段。
轉換這麼命名的好處有兩個：

1. 不用特別考慮，利用統一規則命名，整體系統風格延續。
2. 當其他工作流需要驅動工作流時，不同的狀態都可以以名稱方式來驅動到目標狀態。（比如：圖示的工作流中，待辦、UI設計完成、測試中都是可以轉向研發中狀態的，當命名都是轉向研發的時候，我們子任務驅動主任務流程變化的時候，只要建一個驅動規則，呼叫“轉向研發”轉換，在上述的多個狀態都可以直接轉到研發中狀態）。

工作流轉換設定選項

轉換這邊會有一些高階選項，我們就實際有應用到的場景做一些介紹：

條件

場景：我們控制了新增版本的許可權，只允許管理人員才能修改修復版本，避免版本控制的混亂。
方法：

1. 刪除了修復版本，這樣就不能在問題新建/修改介面操作修復版本欄位，但是Jira的特性是隻要對應的欄位有值，就會出現在介面上，所以不影響使用。
2. 設定了一個單獨的介面“確認版本介面”，上面展示修復版本欄位
3. 在“確定修復版本”轉換中引用這個介面
4. 設定條件
   

指定某個使用者組
結果：這樣就能夠保證只有某個許可權組的使用者能夠看到這個轉換按鈕，從而修改對應欄位

介面配置

介面配置是一個單獨的模組，但是目前似乎只有在工作流的轉換時引用，所以歸屬到這裡。
下面就是一個常見的介面配置：

這裡說幾個注意點：

1. 任何一個介面中都會預設包含備註（評論）這個欄位
2. 如果你使用了Tempo外掛，在工作日誌中的自定義欄位無法在介面的工作日誌中展示。
3. 當前問題型別的欄位方案中沒有的欄位也可以在這裡展示與操作。

後處理功能

下面是我們系統中設定後處理功能的介面

如果你的介面看起來比較不一樣，應該是因為你沒有安裝JMWE這個外掛，新增之後工作流的能力大大提高，才能達到我們不同工作流相互影響相互驅動的效果。
舉例：

這個後處理工作會將當前操作的使用者設定為經辦人（若當前經辦人為空），並且新增到責任人當中去。

總結

經過上面的配置，我們的Jira已經可以投入實際生產使用，但是我們管理系統只是完成了基礎的工作，要把整個系統變得真正“好用”，我們就要把眼光投向Atlassian Marketplace，完成我們系統配置的下半場