完成的定義 (DoD) 驗收標准和准備好的定義 (DoR) 是 Scrum 中的重要概念，而且經常被誤解。讓我們澄清一下它們是什么……
DoD 通常是一份清單形式的簡短文檔，它定義了產品待辦事項（即用戶故事）何時被視為“完成”。它有各種理由和各種解釋方式：
- 您需要對“完成”（=“此用戶故事已完成”）的含義有一個共同的定義。否則，它對團隊中的每個人都意味着其他的東西。
- 你所有的非功能性需求都存在於國防部。
- 要添加到每個故事的特定驗收標准中的通用驗收標准列表。
- 您在回顧中發現的許多改進最終都會出現在國防部。
大多數團隊從沒有或非常簡單的國防部開始。然后他們根據需要在每次沖刺后添加到國防部。提示：不要因為 DoD 過多而麻痹自己！但請記住：敏捷項目中的“完成”意味着“在交付之前不需要做更多的工作”。 因此，如果有人說“該功能已完成，但只需對其進行集成、測試、部署……”，就敏捷而言，它不會被視為“完成”！
檢查某事是否“完成”的最佳方法是簡單地將其發送！如果你能發貨，那就真的完成了；如果您無法發貨，只需在發貨前完成缺少的工作即可“完成”。請注意：您不需要實際運送它，但您需要讓人們相信您可以運送它。
典型的 DoD 可能如下例所示：
- 已編寫自動化測試，所有測試均為綠色
- 代碼被重構和審查
- 代碼與主分支集成
- 部署到暫存環境
- 翻譯成英語和德語
對完成的簡明定義將幫助您提供質量、保持您的計划整潔並靈活應對不斷變化的需求。
DoR: 准備的定義
DoR 是 DoD 的小表弟。它是一個清單，列出了在團隊可以在下一個沖刺中開始實施之前，需要對產品待辦事項做些什么。您可以將就緒的定義視為產品負責人必須完成的“DoD”，以便開發團隊在 Sprint 計划會議上接受這個故事。
請注意，DoR 不是 Scrum 指南的一部分——這是有充分理由的。DoR 不應用作 Sprint 計划的階段門或推卸責任的方式！它應該是團隊在待辦事項細化期間需要做什么的指南。如果您對 DoR 不是 Scrum 指南的一部分的原因感興趣，請參閱為什么Scrum 指南中沒有描述就緒的定義？通過@Barryovereem為更深入的了解。
大多數團隊從一個空的 DoR 開始，然后根據需要添加。再說一遍：不要在這里提出很多要點來麻痹自己！最好從簡單開始，然后根據需要添加到 DoR。
典型的 DoR 可能如下例所示：
- PO 和 Dev Team 需要至少討論一次這個故事
- 故事必須有明確的商業價值
- 需要估計努力
- 故事必須足夠分解以適應一個沖刺
- 故事至少需要一個接受標准
老實說，您可能不需要寫下來。當您在待辦事項細化會話中談論新用戶故事時，您將直觀地將故事推向“為沖刺做好准備”。
如果你想為你的多爾是個好原則，考慮INVEST模式：用戶故事應該是我ndependent，ñ egotiable，V aluable，ē stimable，小號商場和牛逼estable。閱讀@jeremyjarrell 撰寫的關於如何投資您的用戶故事的精彩文章。這是一個簡短的描述：
- 獨立的。用戶故事應該獨立於其他故事。如果您真的編寫“用戶故事”而不是傳統的工作項或任務，那么最終會自動大大減少依賴項。有時，您可能仍然有依賴項——在這種情況下，只需記下依賴項即可。
- 面議。用戶故事應該描述什么客戶需要，而不是如何開發人員應該實現它。開發團隊應該始終能夠提出替代解決方案/實施方案來為客戶提供業務價值。
- 有價值的。必須說明商業價值。這通常是用戶故事格式的“……所以……”部分：“作為一個角色，我想要功能，以便我獲得業務價值”。
- 估計。開發團隊必須能夠粗略估計用戶故事的工作量。這通常意味着開發人員會向產品負責人提出一些澄清問題，並對如何實施提出一個粗略的想法。
- 小。它必須足夠小才能在 sprint 中完成。如果估計比沖刺還大，繼續拆分用戶故事，直到你有小故事。
- 可測試。您需要能夠測試用戶故事是否已完成並實現其目的。這通常意味着您需要一套明確的驗收標准，並將其轉化為測試用例。
再次強調，不要過度理論化 DoR。堅持投資或就開發團隊需要的簡單格式達成一致，然后他們才能明智地開始工作。產品負責人和開發團隊都有責任准備好你的 DoR 意義上的故事。
您什么時候創建 DoD 和 DoR？
DoD 和 DoR 通常在 Scrum 中最重要的會議：回顧會議中進行編輯和擴展。
根據我的經驗，從一個非常簡單（甚至是空的）DoD 而沒有正式的 DoR 開始是值得的。大多數團隊在項目開始前的初次會議期間迅速協作寫下這一點。
隨着項目的進行，您經常會在定期回顧（每次沖刺后舉行的改進工作流程的會議）中找到障礙的解決方案。這些解決方案中的許多最終都屬於 DoD 或 DoR。
DoD vs DoR
DoD 是 Scrum 中一個非常重要的概念。它有助於對在用戶故事被認為“完成”之前需要完成的工作有一個共同的理解，它是流程改進的地方，它包含非功能性需求。你應該盡量減少它，否則你將很難在沖刺中完成任何事情。
DoR 有點像“產品負責人的 DoD”。它有助於 PO 知道如何處理用戶故事，然后才能在下一次 sprint 計划會議上將其交給開發團隊。
DoD 和 DoR 大部分都是在回顧期間形成的——所以讓這些重要的回顧保持高效，永遠不要跳過它們。不要對 DoD 或 DoR 過度理論化——讓它們根據您的真實、實際需求發展。你的目標是在每個沖刺結束時有一個可交付的產品增量——這對你的產品意味着你的國防部。
DoD vs Acceptance Criteria
完成的定義 (DoD) 是用戶故事必須遵守的要求列表，團隊才能稱其為完成。用戶故事 的 驗收標准 由一組測試場景組成，這些場景需要滿足以確認軟件按預期工作。
這兩者之間的區別在於DoD 對所有用戶故事都是通用的，而驗收標准適用於特定的用戶故事。每個用戶故事的驗收標准將根據該用戶故事的要求而有所不同。
換句話說，必須同時滿足國防部和驗收標准才能完成用戶故事。 產品增量不被認為是完整的，除非這兩個列表都完成了。因此，我們需要定義完成定義 (DOD) 的兩個方面——完成標准和驗收標准：
完成與驗收標准的定義
完成的定義
完成的定義被構造為一個項目列表，每個項目都用於驗證故事或 PBI，它的存在是為了確保開發團隊就他們嘗試制作的工作質量達成一致。它用作檢查清單，用於檢查 每個 產品待辦列表項（又名 PBI）或用戶故事的完整性。“完成”定義中的項目旨在適用於產品待辦列表中的所有項目，而不僅僅是單個用戶故事。可以概括如下：
- 該術語更適用於整個產品增量
- 在大多數情況下，該術語意味着產品增量是可交付的
- 該術語在 Scrum 指南中定義
- 用作團隊成員之間溝通的一種方式
- 整體軟件質量
- 增量是否可發貨
完成定義的目標
- 在團隊內部建立關於質量和完整性的共識
- 用作檢查用戶故事（或 PBI）的清單
- 確保在Sprint結束時交付的增量具有高質量，並且所有相關人員都能很好地理解質量。
示例 - 完成的定義
例如，在軟件行業，團隊可能需要提出以下一些問題來提出他們的 DoD：
- 代碼同行評審？
- 代碼完成了嗎？
- 代碼審查？
- 代碼簽入？
- 單元測試通過了嗎？
- 功能測試通過了嗎？
- 驗收測試完成了嗎？
- 產品負責人審核並接受？
驗收標准
用戶故事是敏捷開發的主要開發工件之一，但Scrum沒有明確要求使用用戶故事或驗收標准。如果一個產品待辦事項被認為太大而不能放入沖刺，通常會被分解成用戶故事，然后分解成一組任務，如圖所示：
驗收標准
用戶故事封裝了驗收標准，因此我們經常看到已完成的定義和驗收標准並存於我們的 Scrum 開發過程中。用戶故事提供了團隊應該交付的功能的上下文。驗收標准提供了有關所述功能的細節以及客戶將如何接受它們的指導。他們兩個一起提供了整個可交付成果。
一些驗收標准將在 Sprint 開始之前在 Ongoing Backlog Refinement 事件中發現，而其他一些將在Sprint Planning之后在一個小團隊中坐下來討論用戶故事時立即發現。所以驗收標准是用戶故事或產品待辦列表項獨有的屬性。
- 該術語適用於個人 PBI/故事
- 每個 PBI/故事的驗收標准是不同的
- 術語在 Scrum 指南中沒有定義
- 用作向所有相關人員傳達已滿足特定 PBI/故事要求的方式
- 又名驗收測試、滿意條件，在某些情況下為“測試用例”等
驗收標准的目標
- 在開始工作之前明確團隊應該建立什么
- 確保每個人都對問題有共同的理解
- 幫助團隊成員知道故事何時完成
- 通過自動化測試幫助驗證故事。
示例 – 驗收標准
- 用戶無法在未完成所有必填字段的情況下提交表單
- 表單中的信息存儲在注冊數據庫中
- 可以通過信用卡付款
- 提交表單后，將向用戶發送確認電子郵件
具有驗收標准的用戶故事示例
下圖顯示了用戶故事的驗收標准示例。
完成標准示例
Scrum 工件
Sprint 增量 vs 潛在可交付產品 vs MVP vs MMP