你的團隊是不是經(jīng)常會對于每次迭代是否完成塌忽，無法達成一致意見：有的認為我編碼完成葱绒，就表示我的任務完成了谬以；有的認為還需要簡單自測一下，確保功能能跑通圆雁；還有的認為需要把自動化用例寫完并測試通過忍级。
為了解決這個常見問題，團隊需要對完成的定義伪朽、完成的標準或完成的準則做統(tǒng)一的要求轴咱，這就有了 DoD 的誕生。這也逐漸變成了敏捷開發(fā)方法中的一個重要實踐烈涮。
DoD 定義
DoD 全稱 Definition of Done朴肺， 是我們敏捷中常說的“完成的定義”
這里需要注意幾點：
1 DoD 就是完成準則，完成就是不需要再做其他任何事情坚洽，可以直接交付了戈稿。DoD就是100%完成，而不是99%讶舰，95%器瘪，90%的完成。
2 DoD定義了達成目標的最小活動集绘雁，不增值的橡疼、無用的活動不在此清單上。
3 DoD就是產(chǎn)品的質量活動的標準庐舟，代表了團隊為保證交付質量欣除，對質量投入的共識與承諾。
DoD 作用
明確對完成的預期挪略，確保項目中的內外部的干系人對完成的含義達成理解一致历帚。
承諾的可視化，隱藏的杠娱、內部的質量投入對外暴露出來挽牢，增強團隊的透明性。
避免快而臟的開發(fā)模式摊求，不留技術債務禽拔，不遺留問題給后續(xù)迭代。
作為迭代策劃的前提與約束條件，幫助我們合理估算工作量睹栖，制定切實可行的計劃硫惕。
聚焦目標，減少不必要的活動野来，定義完成任務的最小活動集合 恼除。
在做計劃時判斷是否有遺漏的活動。
在驗收時檢查是否有遺漏的活動曼氛，比如作為 Sprint Review的檢查單的一部分豁辉。
如何定義
團隊成員協(xié)商一致輸出，并確保所有人都可視舀患。不要讓領導定義DoD秋忙。
不同的活動有不同的完成定義，要區(qū)別對待构舟。
隨著迭代的進展灰追，逐步完善DoD。保證隨著時間會改變狗超。組織的幫助和團隊能力的增加可以移除掉更多障礙弹澎，使得更多的活動可以包含到 Sprint 或者 Feature 的DoD中來。
在迭代回顧會議上是討論對DoD的優(yōu)化修改努咐。
DoD越弱苦蒿，欠債越多，后期風險越大渗稍。
質量投入的活動要包含在DoD定義中佩迟，如各種測試、評審竿屹、重構活動等报强。
不同活動DoD
在敏捷軟件開發(fā)中，存在多級的不同的完成定義拱燃。一上來不需要全部覆蓋秉溉，可以共同約定適合團隊的 DoD,然后在過程中過不斷完善和修改。
迭代DoD
常見的迭代DoD條款有:
1 所有完成的用戶故事得到PO的驗證碗誉。
2 所有代碼得到靜態(tài)分析召嘶，糾正最高級別的不符合項。
3 所有新增代碼得到人工評審哮缺。
4 所有完成的用戶故事都有對應的測試用例弄跌。
5 測試用例都已執(zhí)行。
發(fā)布DoD
1 完成發(fā)布規(guī)劃所要求的重點內容尝苇。
2 通過發(fā)布的全量測試铛只，回歸測試范圍是全范圍埠胖，回歸比率不低于50%。
3 修復所有等級為1格仲、2押袍、3的缺陷诵冒，4級及4級以下缺陷不超過200個凯肋。1、2級缺陷必須修復汽馋，3級缺陷經(jīng)過缺陷發(fā)布審批后可以發(fā)布侮东。
4 至少通過一次全量回歸測試。
區(qū)別：
由于發(fā)布需要達到比迭代更高的要求豹芯，所以一般很難強制規(guī)定發(fā)布測試所需要的時間長度悄雅，也就是說敏捷中常用的時間箱方法不適宜用在發(fā)布前的測試上，因為高質量發(fā)布是第1要務铁蹈，如果到了原計劃測試結束的時間宽闲，仍然留有妨礙發(fā)布的缺陷的話，應當修復后才能發(fā)布握牧。
而迭代成果一般是為了內部或者可控范圍內的展示容诬，相對發(fā)布而言，要求較低沿腰，所以適用時間箱方法览徒，當然迭代本身就是時間箱，迭代內的測試本來就有時間限制颂龙。采用時間箱來安排迭代內的測試可以獲得時間箱安排的種種好處习蓬，在這樣的安排下，回歸覆蓋率就應當是一個變量措嵌，用于觀察躲叼，而不應當是一個要求指標。
版本DoD
版本DoD就是針對每個版本上線前后的一些規(guī)則企巢，比如：
1 產(chǎn)品文檔已全部更新
2 代碼已部署到產(chǎn)品服務器上
3 運維在驗收測試環(huán)境上冒煙通過
4 原始需求提交人對功能已經(jīng)驗收通過
5 對運維押赊、市場、客服的新功能培訓已完成
每日DoD
1 搭建每日構建環(huán)境包斑，晚上自動靜態(tài)代碼檢查流礁、編譯、部署和測試罗丰，每日修復前一日構建和測試發(fā)現(xiàn)的缺陷和問題神帅。
2 下班前必須檢入當天書寫的代碼，check in的backlog要填寫清晰萌抵。
3 當天的代碼必須在當天或者第2天邀請同伴進行代碼評審找御。
4 搭建持續(xù)集成環(huán)境元镀，當天上下午必須至少各檢入代碼一次（這與第1條可能沖突）。
5 采用TDD霎桅，凡是檢入的功能代碼必須要有對應的單元測試（嚴格采用TDD）栖疑。
6 每天晚上觸發(fā)靜態(tài)代碼檢查、自動化回歸測試滔驶。
7 當天持續(xù)集成遇革、構建環(huán)境中的問題，請當天解決揭糕。
用戶故事DoD
1 用戶故事最終的描述符合INVEST
2 用戶故事得到測試用例的對應覆蓋
3 用戶故事得到對應的自動化測試用例
4 用戶故事得到用戶代表試用并初步認可
[image:5434D691-9A15-4D2D-9AB8-11431D82E8D0-82946-0002A9EE64E13EB9/640.png]
每周DoD
1 上上周發(fā)現(xiàn)的缺陷是否解決萝快。
2 上周新增功能的自動化測試是否加入到每周測試集。
AC vs DoD
最后記得著角，不要將 AC(Accept criteria )與 DoD 混淆了揪漩，它們都是敏捷開發(fā)中實踐，不可相互取代吏口。AC 是針對每個需求定義的奄容。DoD是針對所有需求，任務产徊，迭代昂勒，交付定義的。
滿足了AC確保我們做了正確的事情囚痴，AC是站在最終用戶的角度定義的叁怪，定義了產(chǎn)品的外部質量。
滿足了DoD確保我們采用了正確的方法做事深滚，DoD是站在利益相關者的角度定義奕谭，未必一定是最終用戶的角度，它定義了產(chǎn)品的內部質量痴荐，保證了產(chǎn)品的長久的適應性血柳。
最終用戶驗收時只關注了AC，而沒有關注DoD生兆。
微信公眾號：Cindynan77
