作者：張克強??? 作者微博：張克強-敏捷307

關于Definition of Done 完成的定義 在以往的說法中，常見用 退出標準 , 完成條件，成功標準，等等 在敏捷軟件開發中，存在多級的不同的完成定義。 典型的是迭代的DoD，這也是最初DoD應用的地方。 常見在Scrum中，需要預先定義DoD，常見的迭代DoD條款有: 1，所有完成的用戶故事得到PO的驗證 2，所有代碼得到靜態分析，糾正最高級別的不符合項，靜態分析的規則參見... 3，所有新增代碼得到人工評審 4，所有完成的用戶故事都有對應的測試用例
而對于發布，一般就有更加嚴格的要求，發布DoD的典型條款有： 1，完成發布規劃所要求的重點內容 2，通過發布的全量測試，回歸測試范圍是全范圍，回歸比率不低于50% 3，修復所有等級為1、2、3的缺陷，4級及4級以下缺陷不超過200個。1、2級缺陷必須修復，3級缺陷經過帶缺陷發布審批后可以發布。
由于發布需要達到比迭代更高的要求，所以一般很難強制規定發布測試所需要的時間長度，也就是說敏捷中常用的時間箱方法不適宜用在發布前的測試上，因為高質量發布是第1要務，如果到了原計劃測試結束的時間，仍然留有妨礙發布的缺陷的話，應當修復后才能發布。 而迭代成果一般是為了內部或者可控范圍內的展示，相對發布而言，要求較低，所以適用時間箱方法，當然迭代本身就是時間箱，迭代內的測試本來就有時間限制。采用時間箱來安排迭代內的測試可以獲得時間箱安排的種種好處，在這樣的安排下，回歸覆蓋率就應當是一個變量，用于觀察，而不應當是一個要求指標。
為了更好的達成迭代DoD，就需要提前注意，所以有些更加細節的DoD得到識別并使用。 最典型的是每日DoD，典型條款有： 1，搭建每日構建環境，晚上自動靜態代碼檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。 2，下班前必須檢入當天書寫的代碼 3，當天的代碼必須在當天或者第2天邀請同伴進行代碼評審 4，搭建持續集成環境，當天上下午必須至少各檢入代碼一次（這與第1條可能沖突） 5，采用TDD，凡是檢入的功能代碼必須要有對應的單元測試（嚴格采用TDD）
還有針對用戶故事（或者用例）的DoD，比如 1，用戶故事最終的描述符合INVEST 2，用戶故事得到測試用例的對應覆蓋 3，用戶故事得到對應的自動化測試用例 4，用戶故事得到用戶代表試用并初步認可
有少數組織考慮到測試集過于龐大，無法在1天之內測試完成，開展每周全量回歸自動化測試，這樣就有每周DoD，典型條款有： 1，上上周發現的缺陷是否解決 2，上周新增功能的自動化測試是否加入到每周測試集。

總結

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

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