某個深夜追查 Bug，打開 Ticket 系統看到的是：「修復書籍搜尋問題」、「要加那個功能」、「上次說的那個」。沒有驗收條件，沒有步驟，只有模糊標題。Reviewer 不知道該查什麼，開發者不確定自己算不算完成，PM 無法判斷能不能關掉。

這讓我們認真思考：Ticket 不只是一張便利貼，它是任務的完整生命週期。

四個狀態，一條主線

待執行（Pending）：Ticket 準備好但還沒人開始。進入條件是標題格式正確、五個核心欄位填寫完整、前置依賴都已完成。

進行中（In Progress）：核心紀律是即時記錄，遇到問題就寫進日誌，不要等到最後才回憶。我們設的建議上限是 8 小時——超過通常代表 Ticket 太大，需要拆分。

Review 中（In Review）：第三方驗證。重點聚焦在驗收條件：逐項打勾，要麼通過要麼不通過。建議 1-2 小時內完成，避免卡住流程。

已完成（Completed）：不可逆的終態。進入條件：所有驗收條件打勾、Review 通過、測試 100% 通過、靜態分析 0 錯誤、工作日誌更新。缺一不可。

Ticket 標題：動詞加目標

標準格式是「動詞 + 目標」。動詞選擇反映任務類型：「定義」用於介面或規範，「撰寫」用於測試文件，「實作」用於具體功能，「修復」用於 Bug，「重構」用於改善結構。

對比：「做 Repository」和「實作 SQLiteBookRepository」——後者讓人在領取前就知道工作規模。

五個核心欄位

每張 Ticket 必須有這五個欄位：

背景說明為什麼需要這個任務，讓三個月後的自己也能理解來龍去脈，不用去問當初的人。

目標一句話說清楚要達成什麼，建議不超過 30 字。可驗證的目標：「實作 SQLiteBookRepository，符合 IBookRepository 介面，通過所有單元測試」。不可驗證的：「優化資料儲存」。

步驟列 3-5 個具體動作，每個指明操作對象和預期結果。目的是讓人一領取就知道從哪裡開始。

驗收條件是任務的契約，必須客觀可勾選。不是「程式碼品質良好」，而是「dart analyze 0 錯誤」；不是「測試通過」，而是「覆蓋率 100%，通過率 100%」。

參考文件連結設計文件、需求規格、相關 Ticket，讓執行者有完整上下文。

執行的七個步驟

領取前先確認依賴都完成，工作量合理再標記進行中。

閱讀背景和目標，把參考文件看完再動手。

執行時遇到問題即時記進日誌。

自檢時逐項勾選驗收條件，全過才進下一步。

提交時標記為 Review，附上自我檢查結果。

處理 Review 結果，通過則關閉，未通過根據反饋修正再提交。

記錄經驗——這一步最容易省略，也最有長期價值。Ticket 完成時回答：學到了什麼？有什麼可改進的地方？是否需要建立 error-pattern 防止重複？知識沉澱進系統，才不會只留在某個人腦子裡。

阻塞狀態的積極處理

Blocked 最容易被誤用：標記了就等著。我們的原則是阻塞不超過 24 小時，必須採取行動。

行動方式取決於原因：缺前置條件就派發前置任務；技術問題不清楚就建調查任務；需要決策就建評估任務。把「被動等待」轉成「積極解除」，每個阻塞都變成一個有人負責的子任務。

結語

從「修復那個問題」到「修復書籍搜尋在 ISBN 格式不一致時回傳空結果的問題」，這個距離比看起來近。只需要一點紀律，和對「完成」這件事更認真的態度。