道生之，德畜之，物形之，勢成之。 --《道德經》
Jira的道在於構建了整個環境和思維模式，也贏得了市場的認可，成了一種勢。無數的廠家便成了Jira的海洋生態當中的重要組成部分。有些廠家的插件是提升了Jira的體驗，有些則是強化了特定功能。這裏只推薦三個算得上必須使用的插件。
BigPicture
Jira Misc Workflow Extensions
Tempo
圍繞這三個插件，我們能夠搭建起研發管理的整體路線和迭代管控視圖，簡化流程，完善管理制度。接下來就介紹每個插件的場景和使用方式。
BigPicture
我們通過一張圖形成一個大概的印象
我們當時選擇這個插件期望滿足的場景有下面幾個：
能夠直觀的查看人員和迭代的工作安排，進度
能夠了解人員的工作飽和度
我們項目管理常用的軟件就是微軟的Project，所以我們選項目標也是按照這樣的思路來挑選的。最簡化的概念就是甘特圖。
BigPicture特點介紹
管理員管理菜單
當中有設置的必要的應該是Working schedule了
設置放假和週末，這樣在計算任務起止的時候能夠在甘特圖中正確的顯示，其他我沒有做過多的設置。
任務列表
從上圖可以看出甘特圖的組織形式分爲4層。
1. 項目（Project）
2. 版本（fixVersion）：注意是根據父任務的修復版本確定的
3. 父任務（Story/Task）
4. 子任務（Sub-Task）
任務管理
在甘特圖的界面可以進行任務的管理。
可以拖動任務的兩端進行開始和截止日期的調整，也可以直接拖動整個任務進行任務的調整。
任務的進度是通過下面的三角標識進度，這個計算是使用實際投入的工時與預計工時直接的比例。
藍色的線是在日期欄直接左擊，就可以設置一個時間線，默認是設置在選擇日期的開始。可以用於設置迭代里程碑。
設置
顯示內容的設置界面如下：
可以看到有四種方式可以混合使用：
1. 面板
2. 過濾器
3. 項目
4. JQL查詢語句
任務列表界面上元素都是可以根據實際系統中設置的字段進行調整的，如下圖所示：
綠色的是自定義字段，灰色的是系統字段。自定義字段基本都是單純的顯示，系統字段會有一些其他的效果。
最佳實踐
一個甘特圖面板最好值針對一個迭代，使用過濾器來方便的管理迭代邊界。能夠很清晰的看到所有任務的排期與時間裏程碑控制。
任務管理的權限需要控制，可以由SM、職能小組負責人統一管理，因爲一般都涉及前後端測試的配合，進度一旦變化就需要全局調整，而且可能會影響迭代里程碑時間點。
由於迭代任務分配時往往是連續的，前期的任務調整可能會導致後續的任務連鎖調整。在甘特圖面板可以很方便的進行調整，而不用一個一個打開任務進行修正。
如果有縱向職能管理角色（比如前端、後端有專門的部門和管理人員），可以建立部門的甘特圖面板進行部門內的排期管理和調整。
Jira Misc Workflow Extensions
這個插件在前端沒有任何感知，知道Jira系統中存在這個插件的基本也只有管理員了。但是對於管理員來說，這是流程推進、串聯的最重要的工具了。
它的作用是在工作流的流轉過程中可以附加其他的操作，列表如下：
可以看到主要有賦值、分配人員、評論、觸發其他流轉環節、自定義腳本等等，而且可以針對問題本身、父問題、關聯問題。基本能夠涵蓋日常應用的場景了。
最佳實踐
我講一下我實踐過程中，比較常用的幾種場景：
自動分配
使用到 Assign to last role member 或者Assign to role member 。場景例如bug，當測試發現一個bug時，可能並不直接指定具體研發，而是提交給研發管理小組確認之後再分配給具體研發，具體研發人員修改完成後，點擊修改完畢按鈕，轉發給測試。測試若發現bug沒有完全修復，點擊退回研發按鈕，直接退回對應研發（而且可以累積退回次數）。
這裏面的幾個步驟：
- 提交給研發管理小組，可以隨機指定研發管理角色中的某一個人來處理
1. 修改完畢，會追溯到測試角色的最後一個經辦人，並且將問題分配給他
1. 退回研發，會追溯到研發角色的最後一個經辦人，並且將問題分配給他
爲何要追溯某角色的最後一個經辦人？因爲內部可能還存在多次指派，甚至對bug進行分析後發現不是後端bug要指定給前端研發。測試不用自己分析要退回給誰，讓流程來判斷。
自動化流程
使用到 Transition linked issues 和Transition parent issue 。我們最早就講過，整個系統是子任務驅動的，具體人員只用關心和管理自己的子任務（子任務只有開始和結束兩個簡單狀態），但是父任務涉及多人合作和角色含義，狀態和節點可能會有幾十個，無論讓誰來管理都是很困難的。場景，一個父任務需要UI、產品、前端、後端、測試共同完成。其中可能產品先行，完成之後交付給UI，完成就可以前後端介入，研發全部完成後才能交付給測試執行。
這裏面思想其實很簡單，就是子任務工作流+角色。首先對於不同角色要區分出合理的用戶組，當每個人完成任務時，判斷他自身的角色從而觸發父任務的狀態流轉。比如產品完成任務時，轉至方案設計完成，研發完成時可以判斷當前父任務下是否存在測試子任務，若存在轉至研發完成待測，若不存在說明不需要測試轉至研發完成無需測試。
這裏給大家一個小小的建議
當你添加自動化工作流時，這裏時可以選擇名稱或者id的，id就是一串唯一數字，當你需要精確觸發工作流時可以指定。但是像上面描述的那種情況，其實並不能完全判定當前的狀態是什麼。比如需要產品協助時，產品會先完成任務之後研發纔開始，這時候研發介入的上一環節是設計方案完成，但是也存在不需要產品研發直接開始比如研發內部優化，這種情況下研發介入的上一環節是待辦。如果這時候指定的具體的工作流，起始狀態不正確就無法執行。所以建議是使用名稱，而且建議規範是轉至+下一環節名稱，比如到研發這個環節，無論從待辦或者方案涉及完成，甚至測試退回，都成爲轉至研發，這樣我們只要寫一次post function就可以滿足多種情況了。
注意：即使使用名稱流轉，也必須滿足該流轉的起始和中止狀態滿足當前情況。例如如果我方案設計中如果沒有指向研發進行中節點，即使我嘗試觸發該流轉也是無法執行的。
Tempo
研發在質問我，已經9012年了我們還要使用工時這種low爆的形式來做績效管理麼？每天湊滿8小時工作時間對於管理層就這麼重要麼？你們的能力僅僅就是看着這個人工時有沒有記錄好麼？
如果你這麼想，說明你沒有想過研發管理到底該做什麼。研發管理控制三要素：時間、成本、質量。控制的目的是提升，如何提升？必然是發現問題，改進才能提升。最簡單發現問題的地方是工時分配，而不是某個員工8小時工時本身。某個迭代中，那個story投入的工時超出成本，哪些人的bug工時投入超出正常比例、哪些人的線上問題投入工時較高、整體研發部門投入在非研發工作上的比例是多少，要不要優化。這些纔是我們應當去關注並改進的。當所有人員只有3-5個人，可能這個數據受個人影響比較大，但是當人員超過30-50人時，個人少報或者沒有正確填寫的影響就已經比較小了，我們要觀察的是趨勢，大項的時間投入正常都是有記錄的，這樣基本就能夠反應真實情況了。
所以Tempo作爲目前時間管理最好的工具，在研發管理中重要性相信各位管理人員都有認知了。
tempo當前最新是9.4.2版本，我使用的是8.15.3 。我嘗試升級過一次插件，結果大家都不習慣新的界面，我不得不退回老版本。
配置
全局配置中有幾點說明，我們是子任務驅動所以工時不允許記錄在父任務。但是隻有一個任務下有子任務的時候纔是父任務，否則就可以記錄工時。
Work Attributes是設置工時填寫面板的自定義字段
注意：這裏的字段只有通過記錄工時按鈕呼出的界面纔有，比如完成任務時填報工時的界面是沒有自定義字段的。
工時表
v9去掉的就是這個工時表，這個基本上是我們最常用的功能了。所以去掉之後大家都不知道怎麼用了。
用戶這個地方的下拉框可以選擇如下幾種選項。其中比較難理解的是賬戶這個概念，tempo裏面實際上是有成本概念的，就是通過賬戶當中的金額來管理，不過我們沒有使用過。
常用的幾個是用戶（分析單個用戶的工時分佈），團隊（每個小組整體任務工時分佈），高級（指定過濾器查看任務工時分佈），問題（查看單個問題的人員工時分佈）
時間區間可以任意指定，查詢出的結果可以直接導出excel用於做透視圖之類的。
Reports
v9主推的就是Reports操作的內容和界面形式應該是更加優化，上面的時間區間、過濾器設置（可以多選），分組可以多選和排序。
這個我們用的比較少，主要會針對某個具體問題、或者較大的Epic相關的項目站會、總結會時，分析人員工作進度和使用。
總結
上述三個插件加入到Jira之後，我們完成了迭代整體控制、工作流實施、研發管理規範與提升三方面配置，基本已經可以開始組織一個研發團隊爲了同一個既定目標按照統一規範流程進行開發，而且儘量簡化過程降低研發非研發類工作的佔比。但是我們還是可以使用一些其他的插件來提高研發管理整體效率。另外必須說一句，這些插件的儀表盤可用插件沒一個能用的。