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