Scrum 中的完成定義與接受標準 – 完整指南

完成定義（DoD） 是一項要求清單，團隊必須確保使用者故事符合這些要求，才會認為該故事已完成。雖然接受標準 一個使用者故事的接受標準包括一組必須達成的測試案例，以確認軟體能按預期運作。

關鍵差異在於DoD 對所有使用者故事都適用，而接受標準則針對單一使用者故事而定。每個使用者故事的接受標準會根據該故事的具體需求而有所不同。

換句話說，要讓一個使用者故事被視為完成，必須同時滿足完成定義和接受標準。除非這兩個清單都完全達成，否則產品增量不被視為完成。因此，我們需要定義完成定義的兩個方面：DoD 和接受標準：

完成定義與接受標準

完成定義：

完成定義以清單形式構建，每一項都作為故事或產品待辦事項（PBI）的驗證點。其目的是確保開發團隊對所交付工作的品質達成共識。它作為一項清單，用來驗證每一個 產品待辦事項項目（也稱為 PBI 或使用者故事）。完成定義中的項目旨在適用於產品待辦事項中的所有項目，而不僅僅是單一的使用者故事。其要點可總結如下：

• 適用於整個產品增量
• 表示在大多數情況下，產品增量具有可發行的潛力
• 在 Scrum 指南中定義
• 作為團隊成員之間的溝通工具：
  • 整體軟體品質
  • 增量是否可發行

完成定義的目標

• 在團隊中建立對品質與完整性的共識
• 作為驗證使用者故事（或 PBI）的清單
• 確保在 Sprint 結束時產生的增量具有高品質，且所有參與者都清楚了解品質標準

範例 – 完成定義

例如，在軟體產業中，團隊可能會提出以下問題來定義其 DoD：

• 程式碼是否經過同儕審查？
• 程式碼已完成嗎？
• 程式碼已審查嗎？
• 程式碼已提交嗎？
• 單元測試通過嗎？
• 功能測試通過嗎？
• 驗收測試已完成嗎？
• 產品負責人已審查並接受

驗收標準

使用者故事是敏捷開發中的關鍵產出物之一，敏捷開發，但Scrum並未明確要求使用使用者故事或驗收標準。如果產品待辦事項過大而無法納入一次 Sprint，通常會被拆解成使用者故事，再進一步細分為一組任務，如下所示：

驗收標準

使用者故事包含驗收標準，因此我們經常在 Scrum 流程中看到「完成定義」與驗收標準並存。使用者故事為團隊應交付的功能提供背景。驗收標準則提供詳細指引，說明功能應如何運作，以及客戶將如何接受該功能。兩者共同定義完整的交付成果。

有些驗收標準是在 Sprint 開始前持續進行的待辦事項精煉會議中發現的，而另一些則是在Sprint 規劃之後立即確認，以便團隊能與使用者故事進行討論。因此，驗收標準是使用者故事或產品待辦事項的獨特屬性。

• 適用於單一 PBI/故事
• 每項 PBI/故事的驗收標準各不相同
• 未在 Scrum 指南中定義
• 作為溝通工具，以滿足特定 PBI/故事的需求
• 也稱為驗收測試、滿意條件，或在某些情況下稱為「測試案例」

驗收標準的目標

• 明確團隊在開始工作前應建立的事項
• 確保所有人對需求有共同的理解
• 幫助團隊成員理解故事何時才算完成
• 透過自動化測試協助驗證故事

範例 – 驗收標準

• 使用者必須填寫所有必要欄位才能提交表單
• 表單中的資訊會儲存在註冊資料庫中
• 訪客可以使用信用卡付款
• 表單提交後，會向使用者發送電子郵件確認

使用者故事與接受標準的範例

下圖顯示使用者故事的接受標準範例。

完成定義的範例