前面在了解了 Lead Time、WIP 等相關指標與圖表後，現在就該來嘗試搭配工具去建立這些產出物了。前面談到要降低紀錄成本的對應方案就是透過自動化，筆者這個過程分為三種自動化：輸入、資料、圖表。
而在這篇，會以 Jira 為核心建立起一套解決方案：
這邊會以 Jira 的 team-managed 類型的專案進行展示，如果你使用的是 company-managed 類型的專案，可能會需要貴組織擁有權限的同事協助處理。會選擇 team-managed 類型的專案作為展示，也是因為該專案對團隊來說比較彈性，能不透過他人客製化的面向比較多，但缺點就是缺少了不少功能。而本主題正是希望傳達「當使用的工具受到局限時，仍能夠想辦法獲得自己想要的指標」的概念，所以卻也剛好。
建議在閱讀本篇時，可以先在 Jira 建立一個 team-managed 類型的專案一起練習。這邊會建立一個名為 iThome Ironman 2024 Team 的專案作為示範。
今天要產出的圖表有：
這時候就要分析需要哪些指標去建立圖表，這些指標可以用哪些數據計算得出。
Lead Time Run Chart 會需要的有每個產品待辦項目（PBI）的 Lead Time (天數) 以及其何時交付的時間戳，這樣才可以知道順序或是收斂成日期；Lead Time Distribution Chart 則是 Lead Time (天數) ；Cumulative Flow Diagram 需要知道每天在各階段的 PBI 有幾張；Delivery Rate / Throughput 是需要何時交付的時間戳，如果是 Velocity 還會需要知道工作量的故事點多少。
所需指標一覽：
其中各階段需要的 PBI 張數會比較複雜，先定義有幾個階段是想關注的，一個階段的定義就是從可以開始做，與正在做的，當做完就會移動到下一個階段。也就是 To-Do 和 Doing 兩種狀態，當 Done 時，也就代表另一個階段的 To-Do。所以要知道 PBI 是哪幾天停留在在某個階段，通常只要紀錄 PBI 進入這個階段的時間戳即可，等同於上個階段完成的時間戳。
這邊以 Scrum 的情境去考慮，大概會分為以下幾個階段：
對應的時間戳為
created at ~ refined at
refined at ~ selected at
selected at ~ began to develop at
began to develop at ~ developed at
developed at ~ tested at
tested at ~ reviewed at
reviewed at ~ deployed at
為了知道某天某階段的張數，就可以直接統計擁有該階段開始的時間戳，但沒有結束時間戳的 PBI 數量。例如我要知道某天處於 Testing 階段的 PBI 有幾張，我可以統計所有 Item 中，擁有 developed at 時間戳，但沒有 tested at 時間戳的 PBI 有幾張即可。
而前面所需的另外兩個指標，也剛好可以在這裡找到對應的時間戳數據：
selected at ~ deployed at
deployed at
到此就釐清要建立基於指標的圖表，會需要在 PBI 中搜集以下數據：
created at
refined at
selected at
began to develop at
developed at
tested at
reviewed at
deployed at
effort
來到 Project settings 中的 Issue types，選擇主要要追蹤的 issue type，如果要追蹤多個 issue types，就重複本小結的步驟即可。
為了較好截圖展示，以及聚焦，本篇會先將無關的欄位都去除。
其中各時間戳類型的數據，會使用右邊側邊欄的 Time stamp 欄位型別進行建立相關欄位。而 created at 本身已經內建類似的欄位了，就不用另外建立了。 effort 也對應到內建的 Story point estimate 欄位。
建立完成大致如此：
好，接下來就讓團隊成員每到一個狀態後，就幫忙更新一下時間戳吧！真是太好了呢～ 才怪！！！
接下來正是最困難的地方，如何讓輸入這些數據的過程更加簡便，甚至是不用刻意去做，就像自動化一樣呢？如果每此都讓成員像上小結尾的動畫一樣輸入，筆者能想像永遠不會有數據搜集是完整的一天。
這時候可以重新檢視每個時間戳應當被記錄的時機點：
created at ：當 Item 被建立時，系統就會自動記錄refined at ：當工作量故事點被填寫時，也就是 Story point estimate 有數值時selected at ：被納入 Sprint Backlog 時，通常確定時間點是按下 Backlog 介面的 Start sprint 按鈕開始當前 sprint 的時間時。began to develop at ：當這個 Item 開始開發時developed at ：開發完時tested at ：測試完時reviewed at ：檢視完時deployed at ：部署完時所以大致分三種情況：
這時候就可以善用 Jira 的自動化相關欄位的填寫了！咱就先從簡單的自動化方式講到相對複雜的吧！
自動化：更換狀態時
筆者假設在 Jira 的使用情境中，在 Board 中，會有數個欄位，並對應到上述的狀態。分別是：
如果沒有的話，可以仿效下面的動畫去建立。
做完大致如此：
接著就要進行自動化的設定，先到 Board 右上方的 ⋯ 欄位選擇 Manage workflow
這時候會進入 workflow 的編輯介面，一開始圖中的元件可能會點混亂，可以透過拖曳去讓佈局好讀一點。
這時候點擊每個階段的 Any，到右邊側邊欄新增一個 Rules，然後選擇「Update an issue field」，選擇對應要更新的欄位，並在賦值的單選項目中選擇「Use date and time of transition」即可。這代表當 PBI 被拖曳到對應 Board 欄位（Column）時，會更新指定的屬性欄位（Field），這兩者的對應關係分別為：
began to develop at
developed at
tested at
reviewed at
deployed at
若是透過文字敘述仍不知道如何新增 Rules，可以參考下方動畫：
敏銳的讀者可能會發現，每一個規則都會有一則警告訊息，那是因為這個 workflow 是針對所有 issue types，而 Epic 和 Subtask 並沒有包含是才新增的屬性欄位導致。為了簡化這次的示範，先忽略這樣的訊息。
這時候點擊右上方「Update workflow」按鈕，在點擊「Save」就可以了。
來驗證一下是否有成功，回到 Board 介面。如果讀者的介面沒有任何欄位，記得先建立一個 Item 並且先 Start sprint。
點開 Item，先確認右下角的屬性欄位都是空值。
這時候試著將 Item 一個個拖曳到個欄位，每次拖曳時都可以檢查是否對應的屬性欄位有更新當時拖曳時的時間戳。
最後驗證，所有屬性欄位都成功自動化了！這樣當團隊在更新 PBI 的狀態時，就會自動當時的時間戳，不再需要自行輸入了，如此便完成了更換狀態時的自動化了。
明天會說明剩下的自動化該如何實踐！我們明天見～
iThome鐵人賽
看影片追技術