你的團(tuán)隊(duì)是不是經(jīng)常會(huì)對(duì)于每次迭代是否完成，無(wú)法達(dá)成一致意見(jiàn)：有的認(rèn)為我編碼完成，就表示我的任務(wù)完成了；有的認(rèn)為還需要簡(jiǎn)單自測(cè)一下，確保功能能跑通；還有的認(rèn)為需要把自動(dòng)化用例寫(xiě)完并測(cè)試通過(guò)。
為了解決這個(gè)常見(jiàn)問(wèn)題，團(tuán)隊(duì)需要對(duì)完成的定義、完成的標(biāo)準(zhǔn)或完成的準(zhǔn)則做統(tǒng)一的要求，這就有了 DoD 的誕生。這也逐漸變成了敏捷開(kāi)發(fā)方法中的一個(gè)重要實(shí)踐。
DoD 定義
DoD 全稱 Definition of Done， 是我們敏捷中常說(shuō)的“完成的定義”
這里需要注意幾點(diǎn)：
1 DoD 就是完成準(zhǔn)則，完成就是不需要再做其他任何事情，可以直接交付了。DoD就是100%完成，而不是99%，95%，90%的完成。
2 DoD定義了達(dá)成目標(biāo)的最小活動(dòng)集，不增值的、無(wú)用的活動(dòng)不在此清單上。
3 DoD就是產(chǎn)品的質(zhì)量活動(dòng)的標(biāo)準(zhǔn)，代表了團(tuán)隊(duì)為保證交付質(zhì)量，對(duì)質(zhì)量投入的共識(shí)與承諾。
DoD 作用
明確對(duì)完成的預(yù)期，確保項(xiàng)目中的內(nèi)外部的干系人對(duì)完成的含義達(dá)成理解一致。
承諾的可視化，隱藏的、內(nèi)部的質(zhì)量投入對(duì)外暴露出來(lái)，增強(qiáng)團(tuán)隊(duì)的透明性。
避免快而臟的開(kāi)發(fā)模式，不留技術(shù)債務(wù)，不遺留問(wèn)題給后續(xù)迭代。
作為迭代策劃的前提與約束條件，幫助我們合理估算工作量，制定切實(shí)可行的計(jì)劃。
聚焦目標(biāo)，減少不必要的活動(dòng)，定義完成任務(wù)的最小活動(dòng)集合 。
在做計(jì)劃時(shí)判斷是否有遺漏的活動(dòng)。
在驗(yàn)收時(shí)檢查是否有遺漏的活動(dòng)，比如作為 Sprint Review的檢查單的一部分。
如何定義
團(tuán)隊(duì)成員協(xié)商一致輸出，并確保所有人都可視。不要讓領(lǐng)導(dǎo)定義DoD。
不同的活動(dòng)有不同的完成定義，要區(qū)別對(duì)待。
隨著迭代的進(jìn)展，逐步完善DoD。保證隨著時(shí)間會(huì)改變。組織的幫助和團(tuán)隊(duì)能力的增加可以移除掉更多障礙，使得更多的活動(dòng)可以包含到 Sprint 或者 Feature 的DoD中來(lái)。
在迭代回顧會(huì)議上是討論對(duì)DoD的優(yōu)化修改。
DoD越弱，欠債越多，后期風(fēng)險(xiǎn)越大。
質(zhì)量投入的活動(dòng)要包含在DoD定義中，如各種測(cè)試、評(píng)審、重構(gòu)活動(dòng)等。
不同活動(dòng)DoD
在敏捷軟件開(kāi)發(fā)中，存在多級(jí)的不同的完成定義。一上來(lái)不需要全部覆蓋，可以共同約定適合團(tuán)隊(duì)的 DoD,然后在過(guò)程中過(guò)不斷完善和修改。
迭代DoD
常見(jiàn)的迭代DoD條款有:
1 所有完成的用戶故事得到PO的驗(yàn)證。
2 所有代碼得到靜態(tài)分析，糾正最高級(jí)別的不符合項(xiàng)。
3 所有新增代碼得到人工評(píng)審。
4 所有完成的用戶故事都有對(duì)應(yīng)的測(cè)試用例。
5 測(cè)試用例都已執(zhí)行。
發(fā)布DoD
1 完成發(fā)布規(guī)劃所要求的重點(diǎn)內(nèi)容。
2 通過(guò)發(fā)布的全量測(cè)試，回歸測(cè)試范圍是全范圍，回歸比率不低于50%。
3 修復(fù)所有等級(jí)為1、2、3的缺陷，4級(jí)及4級(jí)以下缺陷不超過(guò)200個(gè)。1、2級(jí)缺陷必須修復(fù)，3級(jí)缺陷經(jīng)過(guò)缺陷發(fā)布審批后可以發(fā)布。
4 至少通過(guò)一次全量回歸測(cè)試。
區(qū)別：
由于發(fā)布需要達(dá)到比迭代更高的要求，所以一般很難強(qiáng)制規(guī)定發(fā)布測(cè)試所需要的時(shí)間長(zhǎng)度，也就是說(shuō)敏捷中常用的時(shí)間箱方法不適宜用在發(fā)布前的測(cè)試上，因?yàn)楦哔|(zhì)量發(fā)布是第1要?jiǎng)?wù)，如果到了原計(jì)劃測(cè)試結(jié)束的時(shí)間，仍然留有妨礙發(fā)布的缺陷的話，應(yīng)當(dāng)修復(fù)后才能發(fā)布。
而迭代成果一般是為了內(nèi)部或者可控范圍內(nèi)的展示，相對(duì)發(fā)布而言，要求較低，所以適用時(shí)間箱方法，當(dāng)然迭代本身就是時(shí)間箱，迭代內(nèi)的測(cè)試本來(lái)就有時(shí)間限制。采用時(shí)間箱來(lái)安排迭代內(nèi)的測(cè)試可以獲得時(shí)間箱安排的種種好處，在這樣的安排下，回歸覆蓋率就應(yīng)當(dāng)是一個(gè)變量，用于觀察，而不應(yīng)當(dāng)是一個(gè)要求指標(biāo)。
版本DoD
版本DoD就是針對(duì)每個(gè)版本上線前后的一些規(guī)則，比如：
1 產(chǎn)品文檔已全部更新
2 代碼已部署到產(chǎn)品服務(wù)器上
3 運(yùn)維在驗(yàn)收測(cè)試環(huán)境上冒煙通過(guò)
4 原始需求提交人對(duì)功能已經(jīng)驗(yàn)收通過(guò)
5 對(duì)運(yùn)維、市場(chǎng)、客服的新功能培訓(xùn)已完成
每日DoD
1 搭建每日構(gòu)建環(huán)境，晚上自動(dòng)靜態(tài)代碼檢查、編譯、部署和測(cè)試，每日修復(fù)前一日構(gòu)建和測(cè)試發(fā)現(xiàn)的缺陷和問(wèn)題。
2 下班前必須檢入當(dāng)天書(shū)寫(xiě)的代碼，check in的backlog要填寫(xiě)清晰。
3 當(dāng)天的代碼必須在當(dāng)天或者第2天邀請(qǐng)同伴進(jìn)行代碼評(píng)審。
4 搭建持續(xù)集成環(huán)境，當(dāng)天上下午必須至少各檢入代碼一次（這與第1條可能沖突）。
5 采用TDD，凡是檢入的功能代碼必須要有對(duì)應(yīng)的單元測(cè)試（嚴(yán)格采用TDD）。
6 每天晚上觸發(fā)靜態(tài)代碼檢查、自動(dòng)化回歸測(cè)試。
7 當(dāng)天持續(xù)集成、構(gòu)建環(huán)境中的問(wèn)題，請(qǐng)當(dāng)天解決。
用戶故事DoD
1 用戶故事最終的描述符合INVEST
2 用戶故事得到測(cè)試用例的對(duì)應(yīng)覆蓋
3 用戶故事得到對(duì)應(yīng)的自動(dòng)化測(cè)試用例
4 用戶故事得到用戶代表試用并初步認(rèn)可
[image:5434D691-9A15-4D2D-9AB8-11431D82E8D0-82946-0002A9EE64E13EB9/640.png]
每周DoD
1 上上周發(fā)現(xiàn)的缺陷是否解決。
2 上周新增功能的自動(dòng)化測(cè)試是否加入到每周測(cè)試集。
AC vs DoD
最后記得，不要將 AC(Accept criteria )與 DoD 混淆了，它們都是敏捷開(kāi)發(fā)中實(shí)踐，不可相互取代。AC 是針對(duì)每個(gè)需求定義的。DoD是針對(duì)所有需求，任務(wù)，迭代，交付定義的。
滿足了AC確保我們做了正確的事情，AC是站在最終用戶的角度定義的，定義了產(chǎn)品的外部質(zhì)量。
滿足了DoD確保我們采用了正確的方法做事，DoD是站在利益相關(guān)者的角度定義，未必一定是最終用戶的角度，它定義了產(chǎn)品的內(nèi)部質(zhì)量，保證了產(chǎn)品的長(zhǎng)久的適應(yīng)性。
最終用戶驗(yàn)收時(shí)只關(guān)注了AC，而沒(méi)有關(guān)注DoD。
微信公眾號(hào)：Cindynan77
