有一段時間，我們的開發流程有個裂縫。

TDD 走得好好的：Phase 1 設計介面，Phase 2 寫測試規格，Phase 3 實作，Phase 4 重構評估。Ticket 系統也運作正常：建立、認領、完成、歸檔。但這兩套系統各走各的路。結果是開發者在 Phase 3 開始實作時，才發現手上的任務其實包含三件事。或者更糟：沒發現，就這樣把三件事塞進一個 Ticket 完成了。

問題根源很清楚：Ticket 設計決策沒有固定時間點，也沒有固定標準。有人在需求進來時就設計 Ticket，有人在 Phase 1 結束後，有人在開始實作前隨手建一個。技術債務藏在職責混亂的 Ticket 裡，等到 Phase 4 才浮出水面，代價已經翻了好幾倍。

解決方案不複雜，但需要紀律：把 Ticket 設計決策集中到 Phase 3a，只用一套固定標準來判斷。

Phase 3a 是唯一的決策點

第一條規則：Ticket 設計決策只在 Phase 3a 進行。

Phase 1 專注功能設計，Phase 2 專注測試設計，這時候分心去設計 Ticket 結構反而干擾品質。等到 Phase 3a，手上已經有完整的測試規格，此時問「這個任務需不需要拆分」才有足夠資訊，而且判斷結果會直接影響 Phase 3b 的執行方式——決策和執行緊密相連。

Phase 3b 按 Phase 3a 的評估結果執行，Phase 4 做跨 Ticket 的重構評估，但不新增 Ticket。

丟掉量化指標

用什麼標準判斷要不要拆分？

過去常見做法是量化估計：修改幾個檔案？幾個測試案例？這些數字看起來有根據，用起來卻不可靠。

一個修改 10 個檔案的任務，如果全都是針對同一件事（把某個 API 改名，所有用到它的地方跟著更新），那就是原子任務，不需要拆分。反過來，只改 2 個檔案，如果同時做「驗證邏輯」和「效能最佳化」，就該拆成兩個。

工作量大小和職責數量不是同一件事。

四大檢查：唯一的評估標準

四個問題，確認同一件事：這個任務是不是只做一件事？

語義檢查：能用「動詞 + 單一目標」描述嗎？「實作 startScan() 方法」通過，「實作掃描功能和離線支援」不通過。有時候任務的問題在名字上就看得出來。

修改原因檢查：這個任務只有一個修改原因嗎？來自 SRP 的概念，搬到 Ticket 層次：如果這個 Ticket 將來需要修改，觸發修改的原因只有一個嗎？同時受到「API 規格變更」和「離線儲存格式變更」影響的，就是兩個修改原因，應該拆開。這樣 API 改變時，只需要動一個 Ticket。

驗收一致性檢查：所有驗收條件都指向同一個目標嗎？驗收清單同時包含「startScan() 通過測試」、「stopScan() 通過測試」、「離線快取功能正常」，這個 Ticket 在追求三個目標，需要拆分。

依賴獨立性檢查：拆分後的部分之間會不會產生循環依賴？有時候兩件事看起來應該分開，但 Ticket A 的實作需要 Ticket B 完成，Ticket B 又需要 Ticket A 完成——這種情況保持為同一個 Ticket 才對。

決策邏輯直接：四項全部通過就繼續執行，任何一項未通過就拆分。不確定的預設為未通過。過度拆分的代價，遠低於讓職責混亂的任務進入實作。

不確定時，選擇拆分

這條原則違反一些人的直覺：任務感覺稍微大了一點，但四大檢查又沒有明確說要拆，這時候怎麼辦？

拆。

原因是非對稱性。拆了但其實不需要拆，代價是多幾個 Ticket、多一些追蹤開銷。沒拆但其實應該拆，代價是職責混亂的實作、測試難以隔離、Phase 4 牽一髮動全身。後者的代價明顯更高。

拆分之後

判定需要拆分，Phase 3a 的工作是把任務分解成多個各自通過四大檢查的 Atomic Ticket，並建立它們之間的依賴關係（哪個必須先完成，哪些可以並行）。

規劃結果記錄到工作日誌，PM 審核確認後按 Wave 順序執行——有依賴的先完成，無依賴的並行。每個 Ticket 完成後立即 Review，不等全部完成再回頭看。

一個細節：拆分出來的每個 Ticket 本身也要通過四大檢查。如果某個拆出來的 Ticket 還是不通過，繼續拆。

在實作中發現需要拆分

有時 Phase 3a 評估沒問題，但 Phase 3b 實作途中才發現任務包含多個職責——這表示 Phase 3a 有遺漏。

正確做法：停下來，回到 Phase 3a 重新評估，拆分，從拆分後的第一個 Ticket 重新開始。

這聽起來很傷，但繼續實作一個已知職責混亂的任務，只是在未來製造更大的麻煩。

積極派發子任務

實作中遇到預期外的情況：發現新問題需要調查、範圍比預期大、需要做技術決策——原則是積極建立子任務，不要在一個 Ticket 裡處理所有事情。

目的是保持可追蹤性。每個被處理的問題都有對應的 Ticket，日後審查開發歷程時，能清楚看到每個決策的前因後果。

整合之後

整合後得到的不只是更整齊的任務管理。Phase 3b 的開發者拿到手的每個任務都是職責明確的，不需要在實作途中自己判斷「這個應不應該一起做」。Phase 4 的重構評估也更聚焦，每個 Ticket 邊界清晰，影響範圍好估計。

這套整合需要紀律——Phase 3a 的四大檢查不是走過場，決策如果散落在各個階段，整合就失去意義。

但兩套系統會相互強化：好的 Ticket 設計讓 TDD 執行更流暢，嚴格的 TDD 流程讓 Ticket 的職責判斷更有依據。