敏捷DoD和DoR的多種形態
關於Definition of Done 完成的定義
DoD在以往的說法中，常見用 退出標準 , 完成條件，成功標準，等等
典型的是迭代的DoD，這也是最初DoD應用的地方。 常見在Scrum中，需要預先定義DoD。
常見的迭代DoD條款
1，所有完成的使用者故事得到PO的驗證
2，所有程式碼得到靜態分析，糾正最高級別的不符合項，靜態分析的規則參見…
3，所有新增程式碼得到人工評審
4，所有完成的使用者故事都有對應的測試用例
早期的迭代成果一般是為了內部或者可控範圍內的展示，相對釋出而言，要求較低，所以適用時間箱方法，當然迭代本身就是時間箱，迭代內的測試本來就有時間限制。採用時間箱來安排迭代內的測試可以獲得時間箱安排的種種好處，在這樣的安排下，迴歸覆蓋率就應當是一個變數，用於觀察，而不應當是一個要求指標。
關於Definition of Ready齊備的定義
敏捷開發發展了幾個年頭之後，人們發現進入迭代開發應當滿足一定條件，否則過於模糊的需求會導致迭代的失敗，在迭代內花費過多的時間去做需求澄清，因此給進入迭代設立門檻，就是Definition of Ready，簡略稱之為“DoR”， 最初的Ready是指準備好可以進入迭代開發。
常見的DoR
1，使用者故事得到澄清
2，使用者故事的故事點估算已經得到
3，使用者故事的驗收條件已經給出
多級DoD的出現
隨著敏捷軟體開發不斷實踐，為了保證不同物件的質量，出現了多級的不同的完成定義。
釋出DoD
而對於釋出，一般就有更加嚴格的要求，釋出DoD的典型條款有：
1，完成釋出規劃所要求的重點內容
2，通過釋出的全量測試，迴歸測試範圍是全範圍，迴歸比率不低於50%
3，修復所有等級為1、2、3的缺陷，4級及4級以下缺陷不超過200個。1、2級缺陷必須修復，3級缺陷經過帶缺陷釋出審批後可以釋出。
在以往，由於釋出需要達到比迭代更高的要求，所以一般很難強制規定釋出測試所需要的時間長度，也就是說敏捷中常用的時間箱方法不適宜用在釋出前的測試上，因為高質量釋出是第1要務，如果到了原計劃測試結束的時間，仍然留有妨礙釋出的缺陷的話，應當修復後才能釋出。因此出現了Water-Scrum-Fall這樣古怪的提法，在DAD裡面，恰恰容忍這樣的做法，DAD把這樣的做法看成是從原瀑布模型轉向敏捷交付的起步階段。
最新為了獲得更快的時效，迭代級別的釋出成為越來越多組織的選擇，也就是說每迭代都要釋出。那麼這樣，就把釋出的高要求帶給了迭代，迭代DoD同時要滿足釋出DoD。這種情形下，也需要對原來的釋出DoD進行修改，主要在迴歸測試策略和通過條件上，一般而言，原來的迴歸測試策略需要過多的時間，無法在迭代內完成，需要新的迴歸測試策略能夠支援迭代節奏。
為了更好的達成迭代DoD，就需要提前注意，所以有些更加細節的DoD得到識別並使用。
每日DoD
最典型的是每日DoD，典型條款有：
1，搭建每日構建環境，晚上自動靜態程式碼檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。
2，下班前必須檢入當天書寫的程式碼
3，當天的程式碼必須在當天或者第2天邀請同伴進行程式碼評審
4，搭建持續整合環境，當天上下午必須至少各檢入程式碼一次（這與第1條可能衝突）
5，凡是檢入的功能程式碼必須要有對應的單元測試
使用者故事的DoD
還有針對使用者故事的DoD，比如
1，使用者故事最終的描述符合INVEST
2，使用者故事得到測試用例的對應覆蓋
3，使用者故事得到對應的自動化測試用例
4，使用者故事得到使用者代表試用並初步認可
每週DoD
有少陣列織考慮到測試集過於龐大，無法在1天之內測試完成，開展每週全量回歸自動化測試，這樣就有每週DoD，典型條款有：
1，上上週發現的缺陷是否解決
2，上週新增功能的自動化測試是否加入到每週測試集。
多級DoR的出現
隨著多級DoD出現，多級DoR也出現了，往往的前一段的DoD就是後一段的DoR。所以有些的DoR其實就是DoD。比如對於整合測試的DoR就是開發聯調的DoD，在使用看板的情況下，就是狀態列的移動條件。典型的從開發聯調到整合測試的條件：
1，開發跑通主成功場景，Demo給到PO，得到PO認可
2，程式碼合併到某某指定分支
3，持續整合通過
從最初只有迭代DoD出發，DoD和DoR的多種形態的出現是越來越高頻交付的必然結果。在既追求質量又追求效率的情況下，值得組合選擇設定恰當的DoD和DoR，並且在執行中根據出現的情況，不斷調整，成為敏捷團隊的約定，進而塑造團隊文化，甚至進而影響組織文化。