工具說明：Jira Automation Rules

有別於 Workflow 比較簡易的自動化，Automation Rules 是功能比較複雜但更具彈性的自動化系統，作為 Jira 的圖形化介面編寫自動化腳本的工具，可以透過拖曳的方式來建立自動化腳本

要新增一個一個自動化腳本，可以先到 Project Setting > Automation 中，點選右上角的 Create rule。

每個自動化腳本在 Jira 稱之為 Rule，而每個 Rules 下面由一個觸發器（trigger）以及三種元件（component）組成。

大致可以分以下條列的觀念去理解：

• 每個 Automation 腳本都是一則 Rules。
• 每則 Rules 下由一個 Trigger 以及一到數個 Component 組成。
• Trigger 為觸發這個 Rules 發生的條件。
  • Trigger 可以依觸發方式分為：
    • 手動觸發：在指定 issue 上，手動觸發。
    • 排程觸發：在指定時間週期性觸發。
    • 事件觸發：因為某些事件發生而觸發。絕大多數都屬於這個。
• Component 分為：
  • THEN (action)
    • 對系統作出改變的動作。
  • FOR-EACH (branch)
    • 會建立一個額外的區塊，用來將 rules 套用在其他的 Items 上。
    • Branch 至多一層分岔，不會有 Branch 中的 Branch。
  • IF (condition)
    • 限定只有符合某些條件才會執行 Action。

先有結構上的概念，接下來就是用數種實例去熟悉 Jira Automation Rules 的應用方式了。

輸入**自動化：**欄位填寫時

接下來說明與展示當工作量故事點被填寫時，也就是 Story point estimate 有數值時，會自動設定 “refined at” 為當下的時間戳的方式。

在這樣的案例中，使用的是 Field value changed 這個 trigger，只要 issue 的指定屬性欄位（field）有任何值得變更，就會觸發此 rule。

這裡指定的欄位是用來填寫工作量估算故事點的欄位 Story point estimate。由於這邊的目的是要紀錄何時完成了第一次的 refine，不用管後面是否因為新發現或者任何原因有再更新，所以在 Change type 中選擇了 Value added，也就是從空值變成某個數值時，才會觸發。這樣也可以避免後面對這個屬性欄位的修改，會覆蓋較貼近意圖的時間戳。

為了避免其他原因覆蓋了已經有數據的 refined at，比如說更新工作量故事點時，是先清掉再填值的情況，這裡會建議多新增一個 condition，去檢查當前的 refined at 是否為空，是空值才繼續執行。

接著就是要新增更新 refined at 屬性欄位的 action，這裡會選擇 Edit issue 的 action。

若是欄位太多時，可以在搜尋欄上面打關鍵字去降低瀏覽範圍。

需要特別注意的是，這邊的屬性欄位是整個空間共用的，所以可能其他專案也會有同名的屬性欄位，所以選擇時要特別注意是不是有這樣的風險。比較保險的是，可以在屬性欄位名稱中，加入這個專案特有的前綴或者後綴字，比如說 📝。這點在前面設定 condition，選擇指定屬性欄位時一樣適用。

在值的部分，直接填寫 {{now}} 即可。這是名為 smart value 的數值樣板，用 {{ 和 }} 包覆起來，並在裡面寫入類似變數名稱的鍵值。而 {{now}} 則代表執行 rule 當下的時間戳。

完成之後就可以點擊右上方的 Turn on Rules，填寫名稱後啟用本 rule。

最後來驗證一下這條 rule 是否成功建立。

先建立一個驗證用的 item，然後檢查原本的 Story point estimate 與 refined at 屬性欄位是否為空值。

接著嘗試在 Story point estimate 屬性欄位輸入任意值。

重新整理時，就會發現 refined at 屬性欄位也自動化更新了時間戳！

理解這樣的方式後，就可以在要紀錄什麼資訊時是可以跟隨欄位變動時，去更新時間戳了。

比如說如果要紀錄 PO 檢視完成這個 item 的時間戳，就可以建立一個簽名欄位，當該欄位被更新，且觸發者是指定的人選時，就更新某個時間戳的屬性欄位。

輸入**自動化：**Sprint 開始時

接下來說明與展示當 item 確定要開始做時，會自動設定 “selected at” 為當下的時間戳的方式。

這裡的自動化設計概念是借用 Jira 的操作介面的儀式感，每次 Sprint 要開始時，都要透過點擊在 Backlog 右上角的 Start sprint 的按鈕去啟動，這時候通常也代表該次 Sprint 的範疇都確定了，那麼就可以認定在 Sprint Backlog 中的 item 都是確定要在這個週期開始做的。

一樣先建立一個新的 automation rule，在這次的案例中，使用的是 Sprint started 這個 trigger，只要如上述說明點擊了「Start sprint」的按鈕，並送出資料去啟動時，就會觸發這個 rule。

在這個觸發器，會要求選擇指定的 board。通常在 team-managed 的專案，只會對應到一個 board，通常會以專案代號去命名，例如這裡要選的是 IM24T board。

但相較於 issue 相關的 trigger，會自動綁定一個 issue 作為 action 的作用範圍，但是 sprint 相關的 trigger 並不會如此，而且這裡的目標是所有在 sprint backlog 的 items，不只一個。

這時候就可以透過 branch 元件達到此目的，這個元件會遍歷指定條件下的所有 item 都去執行指派的 action，就像是其名 FOR EACH 一樣。

這邊選擇「Branch rule / related issues」即可。

這時候就要選擇想要遍歷的 issue 是基於怎樣的條件下去篩選出來的，至時候選擇「Issues in the sprint」就對了！

但透過這個 branch 篩選出來的 issue 其實不只有 item，包括該 item 下面的 subtask 也會在其中，所以為了避免雜訊，這裡會建議新增一個 condition 元件，去限定只有 issue type 是 item 時才會往下執行。

同樣的，為了避免其他原因覆蓋了已經有數據的 selected at，比如說其實這個 item 是上個 sprint 就已經開始做了，這裡會建議多新增一個 condition，去檢查當前的 selected at 是否為空，是空值才繼續執行。

最後就是新增更新 selected at 屬性欄位的 action，一樣去選擇 Edit issue 的 action。

在填寫數值時，一樣是填寫 smart value 作為變數，這裡使用的是 {{sprint.startDate}} ，即代表是 trigger 這個 rule 的 sprint 的開始日期。

更多 smart value 可以點擊輸入框右側的 { } 圖是開啟說明面板。

完成之後就可以點擊右上方的 Turn on Rules，填寫名稱後啟用本 rule。

最後來驗證一下這條 rule 是否成功建立。

先建立一個驗證用的 item 與一個 sprint，並把 item 拉近 sprint 中，然後檢查 item 的 selected at 屬性欄位是否為空值。接著點擊右上角的 Start sprint 按鈕，填寫相關資料後送出。

這時候會被導轉到 board 的介面。接著點開 item，檢查 selected at 是否成功設定時間戳，有的！

理解這樣的方式後，就可以在要紀錄什麼資訊時是需要隨著 sprint 開始去更新資料了。

透過這昨天與今天的三種輸入自動化，就可以讓輸入數據這件事融入團隊平時使用專案管理工具的日常中了。在使用數位化工具時，應當去思考如何發揮他的強項，而自動化與儲存資訊這兩個面向正是其強項之處。如果使用數位化工具，還採取使用紙本的思維，那會增加更多額外的成本。