延續昨天的話題，我來簡單講一下 Jira Workdlow 的一些術語

Jira Workflow

• Issue 的流動，即從某 Status 轉移到另一個 Status 的過程，稱為 Workflow。
• 每種 Issue Type 可以有不同的 Workflow，也可以共用一種
• 在 Workflow 中有三種元件，包含
  • Status (狀態) x 3
  • Transition (轉移)
  • Rule (規則)
• Status 轉移到另一個 Status 的過程，即為 Transition (轉移)。
• 在 Transition 發生時，可以設定觸發 Rule (規則)，包括：
  • 改變 assignee
  • 更新 issue field
  • 驗證 transition 的觸發者
  • 驗證 transition 需要經過的 Path
  • 驗證 issue field 是否屬於某值

在暸解這些術語與概念後，就可以再更聚焦於 transition 與 rules 的概念，我們可以善用 rules 為我們建立一些簡單的限制與自動化。

比如說，在敏捷開發的環境裡，我們從過往的被指派工作，更多強調的是在於自我去認領——我們完成手頭上的一個任務後，會再去 Kanban 上拿取下一個待辦的項目。

在紙本環境下，我們的任務可能是一張便利貼，我們在拿取時會順手在便利貼上用奇異筆在右下角寫上自己的名字，代表這張是我認領的。但在任何數位化工具裡，做這件事就會變得比較麻煩，像在 Jira 裡，我們就要自己點開 subtask，然後將 Assignee 更新成自己的名字。

又因為只有 Assignee 可以顯性化在 Board 上，所以我們會很仰賴它做為當個階段正在處理的認領者。所以可能在開發階段會是 A 當 Assignee，A 開發完後，將他移到測試階段，為了表示還沒認領，要將自己從 Assignee 移除，然後 B 想要認領測試時，又要在上面更新自己為 Assignee。這些繁瑣的小細節，通常會讓人覺得麻煩、難以落實，進而導致無法將實地的優點待到數位化工具中。

所以我們可以設定當 task 從 Backlog/ToDO 拉到 In Progress 時，自動將拖曳的人設定成 Assignee，當他拉到下個階段時，會自動清空，等待下一個認領的人手動更新，作為認領的儀式感。

如此一來就可以降低使用成本，又保留在現場的一些優點與儀式。