關于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，并且在運行中根據出現的情況，不斷調整，成為敏捷團隊的約定，進而塑造團隊文化，甚至進而影響組織文化。

總結

以上是生活随笔為你收集整理的敏捷DoD和DoR的多种形态的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。