Ticket 設計完成後才發現職責不清、範圍過大——這時程式碼都已經寫了，修正成本才是真正的問題所在。

我們在專案中建立了一套設計階段品質閘門：在 Ticket 進入 Phase 2 之前強制執行 C1/C2/C3 三項檢測。 問題在文字階段就抓出來，修正只需幾分鐘；等到程式碼都寫好了，才是幾個小時起跳的代價。

三層檢測標準

C1 God Ticket：超過 10 個檔案、跨越超過 2 個架構層、或預估超過 16 小時，判定過大，必須拆分。

C2 Incomplete Ticket：驗收條件少於 3 個可量化項目、缺少測試規劃、未定義工作日誌名稱、無參考文件連結——任一缺失，Ticket 不完整。

C3 Ambiguous Responsibility：標題缺少層級標示（如 [Layer 5]）、目標含複合職責（出現「和」或「或」）、步驟用「相關檔案」而非具體路徑、驗收條件跨層——任一模糊，需重新定義。

檢測順序的設計邏輯

固定執行順序：C1 → C3 → C2。

C1 最先，因為一旦判定 God Ticket，拆分後產生多個新 Ticket，C2/C3 的分析全部作廢要重來。C3 排第二，職責不清的 Ticket，補充驗收條件也會是模糊的。C2 最後，在範圍合理、職責明確的基礎上，確認必要元素齊全。

執行流程

Step 1：C1 God Ticket 檢測

從 Ticket 的步驟章節提取所有檔案路徑，計算檔案數量。接著使用檔案路徑分析法判斷每個檔案所屬的架構層：

  • lib/presentation/widgets/、lib/presentation/pages/ 屬於 Layer 1（UI 層）
  • lib/presentation/controllers/、lib/presentation/view_models/ 屬於 Layer 2（行為層）
  • lib/application/use_cases/、lib/application/services/ 屬於 Layer 3（UseCase 層）
  • lib/domain/repositories/（介面）、lib/domain/events/ 屬於 Layer 4（Domain 介面層）
  • lib/domain/entities/、lib/domain/value_objects/、lib/infrastructure/ 屬於 Layer 5（Domain 實作層）

層級跨度 = 最高層 - 最低層。如果有檔案分佈在 Layer 1 到 Layer 5，層級跨度就是 4，遠超過 2 的上限。

預估工時根據步驟數量與複雜度係數評估：步驟數 × 平均每步時間 × 複雜度係數（1.0 到 2.0）。

檢測失敗時，依序嘗試三種拆分策略：

  1. 按層級拆分（優先）：將跨層的 Ticket 按架構層拆成多個
  2. 按職責拆分（次要）：將工時過長的 Ticket 按職責邊界拆分
  3. 按功能模組拆分（最終）：將職責過多的 Ticket 按功能模組拆分

拆分後的每個子 Ticket 都需要重新執行 C1 檢測。

Step 2：C3 Ambiguous Responsibility 檢測

確認四個要素：

  • 層級標示：標題包含 [Layer X] 標籤
  • 職責描述：目標章節無「和」或「或」的複合描述
  • 檔案範圍：步驟列出具體路徑，而非「相關檔案」
  • 驗收限定：驗收條件不出現跨層項目

任一不符，依序修正：明確層級 → 重寫職責 → 列出具體檔案 → 限定驗收範圍。

Step 3：C2 Incomplete Ticket 檢測

確認四個必要元素都存在：

  • 驗收條件：3 個以上可量化、可驗證的項目（「程式碼品質提升」這種描述不算）
  • 測試規劃：明確的測試檔案路徑和對應的測試項目
  • 工作日誌：定義好工作日誌的檔案名稱（而非「待填寫」）
  • 參考文件：至少 1 個有效的文件連結

缺少哪個就補哪個，沒有例外。

Step 4：提交審查

所有 Ticket 通過 C1/C2/C3 之後，生成品質閘門檢測報告，提交 PM 審查。PM 批准後才能進入 Phase 2。

阻斷機制與執行時機

任何 Ticket 未通過 C1/C2/C3，禁止進入 Phase 2。不是建議，是硬性規定。問題立即修正，所有過程寫入工作日誌。

執行時機有三個：設計完成後立即檢測、PM 分派前確認報告、PM 審查時以報告作依據。三個時機缺一不可——缺了任何一個，閘門就會有漏網之魚。

實際效益

最直接的改變是：開發者接到 Ticket 時就已經有明確範圍、清楚職責、具體驗收標準，不需要反覆確認。

更重要的是，因為修正成本真的很低，團隊才會認真對待每一次品質閘門，而不是當作走形式。一旦修正成本高，就會開始討價還價、局部修正、累積技術債——品質閘門也就形同虛設。