將預期結果轉成 initiative

先描述結果，再描述步驟

虛構設備服務需要員工自助功能。有用請求會說明結果：「已通過身分驗證的員工，可以建立申請，而且只能查看自己的申請。」

解釋原因：目前管理者必須代員工輸入申請。定義範圍：建立申請、顯示狀態、存取檢查，以及這些行為的證據。排除自動採購與管理者核准規則的變更。

檢查儲存庫前，不要先指定檔案修改方式。Initiative 記錄意圖，詳細規劃再將意圖轉成實作步驟。

審查請求產生的內容

Taiga 使用請求與產品上下文，建立一個 initiative 或一組有順序的 initiatives。新工作進入 Backlog。較大請求可能需要數個能獨立審查的變更。

閱讀生成的最終狀態、Why 和 Scope。確認必要行為保留，且遵守排除項目。如果既有 initiative 已涵蓋請求，Taiga 可以指出它，而不另建重複工作。

請求若被已發布政策阻擋，就要使用該政策定義的決策途徑。閱讀說明，透過該途徑解決衝突。不要只為隱藏禁止操作，就改寫請求。

將看板視為執行順序

每個產品一次只處理一個 initiative，包括規劃。Taiga 在目前 PR 合併後，才開始下一個排隊項目。它不會自動將 Backlog 或 Todo 項目移到 Queue。

放入 Queue 的決定很重要，因為它會覆寫對未完成相依工作的等待。排入員工自助服務前，確認身分基礎已存在，或所選範圍會正確建立該基礎。

檢查詳細計畫

規劃器讀取儲存庫、產品文件、政策、指令和部署上下文。依實際使用者結果與環境檢查計畫。

對設備服務，驗證三種存取情況：員工能看到自己的申請、另一位員工無法看到，以及管理者保有所需審查權。實作若改變資料移轉或維運行為，也要納入。

Build on its own by default 若關閉，完成的計畫會等待你的決定。Approve 以核准者身分開始建置，並受其權限限制。Reject 根據回饋重新規劃。個別 initiative 可以有自己的設定。

用正確紀錄做下一個決定

計畫有版本。每次執行（run）記錄所用計畫。預定方法改變時，檢視 initiative 與適當的重新規劃操作。用執行紀錄檢查先前嘗試。

建置、已合併 PR 和正式環境發布，是不同狀態。工作推進時，持續清楚呈現驗收證據與部署責任。繼續閱讀自主性設定。