在敏捷開發的領域中，清晰度是成功的貨幣。當團隊開始開發新功能時，基礎在於使用者故事。然而，使用者故事僅僅是對話的佔位符。要將這場對話轉化為可運作的產品，需要兩個關鍵的產物：驗收標準與完成定義。這些概念如同護欄，確保品質、一致性和可預測性。
許多團隊在這兩個概念之間的區別上感到困擾。有時它們被視為相同的事物，導致測試或部署期間產生混淆。有時則完全被忽略，導致範圍蔓延或未完成的功能進入生產環境。本指南探討驗收標準與完成定義的運作機制、目的與實踐方法，幫助你的團隊持續交付價值。
什麼是使用者故事？ 📝
在拆解故事的各個組件之前，必須先回想使用者故事實際上是什麼。在敏捷框架中，使用者故事是從渴望新功能的人的角度出發，對功能所做的簡短且簡單的描述。它通常遵循以下格式：
- 作為 [使用者類型]，
- 我想要 [某個目標]，
- 以便 [某種好處]。
此格式著重於價值提供給使用者的價值，而非技術實現。然而，僅僅這個格式不足以引導開發。它並未明確界定工作的範圍或完成所需的標準。這正是驗收標準與完成定義介入之處。
驗收標準（AC）：完成的條件 ✅
驗收標準是一組條件，使用者故事必須滿足這些條件，才能從產品負責人的角度被視為完成。它們定義了故事的範圍，並清楚說明最終產品應呈現的樣貌。
驗收標準的目的
驗收標準在開發週期中扮演多種角色：
- 釐清： 它能消除模糊性。如果開發人員問：「懸停時按鈕應該變綠還是變藍？」，驗收標準應能明確回答。
- 測試： 它們作為測試案例。品質保證工程師利用這些條件來驗證功能。
- 共識： 它們確保產品負責人與開發團隊對此特定故事的「完成」狀態達成共識。
優良驗收標準的特徵
有效的驗收標準應具備明確性、可衡量性與無歧義性。避免使用如「使用者友善」或「快速」等未定義指標的模糊詞語。應明確指定具體行為。
- 原子性： 每個標準應僅針對單一需求。
- 可測試性： 必須能夠以通過或失敗的結果來驗證該標準。
- 獨立： 條件不應依賴外部故事來驗證。
- 相關： 聚焦於使用者價值，而非內部程式碼結構。
接受標準的範例
考慮一個關於新增「忘記密碼」功能的故事。以下是接受標準可能的樣貌：
- 當使用者位於登入頁面時，
當他們點擊「忘記密碼」連結時，
則他們會被導向密碼恢復頁面。 - 當使用者輸入有效的電子郵件時，
當他們提交表單時，
則會顯示確認訊息。 - 當使用者輸入無效的電子郵件時，
當他們提交表單時，
則會顯示錯誤訊息，指出電子郵件格式不正確。
這些範例遵循 Given/When/Then 結構（通常與 Gherkin 語法相關），能促進清晰度，並與自動化測試框架一致。
完成定義（DoD）：品質門檻 🚧
雖然接受標準是針對單一使用者故事的，但完成定義是一項適用於整個 sprint 或發行版本中所有工作的全球標準。所有工作。它代表了任何工作增量被視為可能可發行時，必須滿足的檢查清單要求。
完成定義的目的
完成定義扮演著品質門檻的角色。它確保技術負債不會累積，且產品始終處於可發行狀態。如果一個故事符合其接受標準，但未符合完成定義，則無法標記為完成。
完成定義中常見的元素包括：
- 程式碼審查： 所有程式碼必須至少由一位同儕審查。
- 單元測試： 自動化測試必須針對新邏輯達成 100% 覆蓋率並通過。
- 文件： API 文件或使用者指南已更新。
- 效能： 該功能符合最低載入時間要求。
- 可及性： 該功能遵循 WCAG 指南。
- 安全性： 未引入已知的漏洞。
為什麼「完成定義」很重要
若沒有「完成定義」，團隊經常會陷入「技術上已完成，但實際上尚未準備好」的陷阱。一個功能可能根據驗收標準運作如預期，但可能破壞了系統的其他部分，缺乏適當的文件，或引入安全風險。完成定義透過在整個待辦事項清單中強制執行品質基線，來防止此類情況發生。
驗收標準 vs. 完成定義：關鍵差異 🆚
混淆經常產生，因為這兩個概念都涉及「完整性」。然而，它們的範圍與主責權不同。理解這項區別可避免開發人員、測試人員與產品經理之間的誤解。
| 功能 | 驗收標準 | 完成定義 |
|---|---|---|
| 範圍 | 僅針對單一使用者故事 | 對整個團隊或專案而言皆適用 |
| 主責權 | 產品經理與開發團隊 | 整個開發團隊 |
| 彈性 | 根據需求，每則故事可調整 | 穩定，但可隨時間更新 |
| 目的 | 定義功能需求 | 定義品質與非功能標準 |
| 驗證 | 根據使用者需求進行功能測試 | 技術與流程驗證 |
將驗收標準視為特定旅程的目的地，而完成定義則是所有道路上車輛都必須遵守的安全檢查清單。
如何撰寫有效的接受標準 📝
撰寫接受標準是一項合作性的工作。不應由產品負責人單獨完成。最佳實踐包括「三友」概念，即產品負責人、開發人員和測試人員在優化流程的早期階段共同合作。
步驟 1：識別使用者目標
首先重述價值主張。使用者正在解決什麼問題？這能確保標準始終聚焦於使用者體驗，而非技術細節。
步驟 2：定義正面與負面情境
不要只撰寫順利的流程。也要考慮事情出錯時會發生什麼。
- 順利流程： 使用者執行操作的方式完全符合預期。
- 边界情況： 特殊字元、資料遺失或連線緩慢時會發生什麼？
- 負面路徑： 系統如何妥善處理無效輸入？
步驟 3：使用清晰的語言
盡可能避免使用行話。若必須使用技術術語，請確保其已明確定義。使用主動語態。例如，“系統應驗證……”不如“使用者收到錯誤訊息……”來得清楚。
步驟 4：優先排序
若故事規模過大，應予以拆分。接受標準應能在一次迭代內完成。若標準所暗示的工作無法在迭代內完成，則需將故事拆分。
如何建立穩健的完成定義 🛠️
完成定義並非一成不變的文件。隨著團隊的成熟與技術的演變，它也會持續進化。應讓所有人可見，通常會顯示在實體或數位看板上。
步驟 1：徵詢團隊意見
完成定義由實際執行工作的團隊負責。開發人員、測試人員和設計師都應參與清單的制定。若開發人員提出要求，他們更可能遵守該要求。
步驟 2：分類需求
將完成定義的項目歸類為邏輯性分類，以使檢查清單更易於管理。
- 程式碼品質： 程式碼檢查通過，無警告訊息，同行審查已完成。
- 測試： 单元測試已撰寫，整合測試通過，手動測試已驗證。
- 部署： 已部署至預發環境，冒煙測試通過。
- 文件： Readme 已更新，API 文件已同步。
步驟 3：使其成為硬性停止
如果一個故事未達到完成定義（DoD），就無法關閉。這需要紀律。雖然很容易說：『我們稍後再修補文件』，但這樣會產生技術債務。故事必須一直停留在『進行中』狀態，直到達成 DoD。
步驟 4：審查與優化
在回顧會議期間，詢問團隊：『我們的 DoD 是否發現了任何問題？』或『我們是否一直忽略某項需求？』根據這些洞察更新 DoD。
應避免的常見錯誤 ⚠️
即使經驗豐富的團隊在實施這些實務時也會犯錯。意識到常見的陷阱可以節省大量時間與煩惱。
1. 模糊的接受標準
撰寫如『系統應具備安全性』之類的標準毫無用處，因為無法測試。應明確指出：『系統必須為管理員帳戶要求多重身份驗證。』
2. 將 DoD 視為填格子的儀式
如果團隊僅勾選 DoD 欄位卻未真正執行工作（例如跳過程式碼審查），DoD 就失去了意義。DoD 必須受到尊重，而不僅僅是被閱讀。
3. 將 DoD 設定得過於複雜
一個包含 50 項內容的 DoD 會讓人不堪重負。應專注於關鍵品質門檻。若某項需求很少被違反，它可能僅是指導原則，而非硬性 DoD 項目。
4. 忽視非功能需求
團隊經常過度關注 AC（功能需求），卻忽略 DoD（非功能需求）。效能、安全性與可及性都屬於 DoD 的一部分，而非 AC。忽略這些會導致功能雖能運作，卻又慢又不安全。
5. 在缺乏團隊共識的情況下制定 DoD
如果產品經理在未徵詢開發人員意見的情況下制定 DoD，團隊可能會抵制。DoD 必須是團隊共同達成的協議。
整合至工作流程 🔄
接受標準與完成定義應融入開發生命週期的每個階段，而不僅僅是在最後階段。
優化階段
在待辦事項優化期間，產品經理草擬接受標準。團隊會審查這些標準，確保其可測試且可行。問題在此階段提出並解答，而非在 Sprint 中。
Sprint 規劃
在承諾故事時，團隊需確認接受標準是否清晰。若不清晰，該故事就不適合進入 Sprint。
開發階段
開發人員撰寫程式碼以達成 AC。同時，他們也確保遵守 DoD（例如撰寫測試、請求審查）。
測試階段
品質保證工程師會根據已建構的功能驗證 AC。他們也驗證 DoD（例如檢查程式碼覆蓋率報告、可及性掃描）。
審查與結案
在故事移至『完成』之前，團隊需確認 AC 與 DoD 均已達成。若未達成，則需退回待辦事項佇列。
衡量成功 📊
你如何知道你的接受標準與完成定義是否有效？需持續追蹤相關指標。
- 缺陷率：生產環境中發現的錯誤是否在減少？強大的完成定義應能在發布前發現問題。
- 拒絕率：故事是否經常被產品負責人拒絕？這表示接受標準定義不夠清晰。
- 速度穩定性：團隊的速度是否保持穩定？如果故事因缺少完成定義的項目而頻繁被退回，速度將會波動。
- 部署頻率：清晰的完成定義是否能讓部署更順暢、更頻繁？
常見問題 ❓
以下是團隊在實施這些標準時常會提出的问题。
問：接受標準可以在迭代期間變更嗎？
答：理想情況下，不應該。如果接受標準有重大變更，可能表示在精煉階段對故事理解不夠清楚。小幅度澄清是可以接受的，但重大範圍變更應導致新故事的產生或調整迭代範圍。
問：每個故事都需要獨特的完成定義嗎？
答：不需要。完成定義是全局性的。然而，特定的技術故事可能需要為該項目額外增加要求到檢查清單中，但基礎的完成定義適用於所有故事。
問：如果團隊對完成定義有不同意見該怎麼辦？
答：促進討論。目標是達成共識。如果開發人員堅持某項要求，而測試人員不同意，則討論風險。若風險低，可刪除該要求；若風險高，則保留。
問：接受標準應該詳細到什麼程度？
答：詳細到足以測試為止。如果品質保證工程師能直接根據接受標準撰寫測試案例，則已足夠詳細。如果他們仍需提問，則需要更多細節。
問：自動化測試能否取代完成定義中的手動測試？
答：取決於情況。對於關鍵邏輯，可以。對於使用者體驗或視覺元素，可能仍需手動驗證。完成定義應反映品質保證的最佳實務。
關於品質與對齊的最後想法 🌟
實施接受標準與完成定義並非官僚作業；而是尊重的體現。這是對期待功能正常運作的使用者的尊重，對希望有明確需求的開發人員的尊重，以及對需要交付信心的產品負責人的尊重。
當這兩個概念被正確使用時，它們為團隊創造了一種共通語言。它們減少對不斷澄清會議的需求，防止技術債務的累積，最重要的是，確保每完成一個故事都為產品帶來真正的價值。
從小處著手。定義一個基本的完成定義。為下一個故事撰寫清晰的接受標準。在下一次回顧會議中審查它們。隨著時間推移，這些實務將變得自然而然，融入團隊的文化中。結果是持續產生符合使用者需求的高品質軟體。