DoR、DoD，定義的是什麼？技术頭條網

本文部分內容，節選自——《敏捷無敵之DevOps時代》第18章 ”DoD，真正把事做完“

本文部分內容，經授權，節選自“儂家鋪子“的文章：DevOps成長路線——DoR vs DoD

上文翻譯自：https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will

一、DoD 與 DoR

一個迭代是固定時間的循環，依次把迭代backlog上高優先級的任務變成產品增量。但是，要把事項順利拉到當前的迭代中，如何定義用戶故事“已經準備好”是很重要的——把沒有完成或沒有細化的用戶故事放到迭代中，會在開發階段產生問題，因為它遵循一個古老的原則：“進去的是垃圾，出來的也是垃圾”。如果開發基於沒有充分細化或定義的用戶故事來開發，他們不太可能產出高質量的代碼。

一個“準備好”的backlog事項應該是清晰的，可行的，可測試的：

“清晰的”意味著所有的Scrum團隊成員對該條目達成了共識。通過協同編寫用戶故事，對高優先級事項添加驗收標準，有利於需求的澄清。
“可測試的”意味著能通過有效的辦法決定該條目是否符合期望。驗收標準可確保每個故事都能被測試。
“可行的”意味著根據DoD，該條目能夠在一個迭代中完成。否則，條目需要進一步的分解。

簡單的講，DoR定義了一些標準，用戶故事在開始估算或者進入迭代前，必須先符合這些標準。

“DoR”關注用戶故事級別的特性，“DoD”的關注點則在迭代或者發佈層面。本質上，“DoD”代表著迭代或者發佈的驗收標準。它清楚的列出了為完成產品增量，開發團隊必須要達到的要求。

二、DoR是什麼

DoR是一個待辦（backlog）是否能夠被團隊接受，認為可以作為開發候選所需要達到的最小要求，是團隊針對PO的要求。

一個DoR的例子：

Clear，用戶故事描述清晰；
Feasible，用戶故事可以放入一個迭代；
Testable，驗收條件得到定義。

需要注意的是，DoR只需要針對產品待辦列表PBL中高優先級的需求進行，通常是準備能夠滿足兩個迭代的即可。PBL越是近期會做的，需求越清晰，越是符合INVEST原則；越是暫時不會做的，越不需要花太多精力去澄清和拆解。

而DoD則相反，是PO針對團隊的產出進行驗收的最低驗收標準，文中已經給出了樣例。

最初DoD只有一級，即研發迭代完成，用戶故事可以被視為完成的標準。逐漸出現了多級的DoD，針對每一個研發階段，出現了這一階段的DoD標準，例如從Henrik Kniberg的Kanban kick-start example圖中，分析階段的DoD、開發階段的DoD、驗收測試階段的DoD等；典型的Kanban是拉動的過程，後一階段拉取上一階段完成（Done）的工作時，會檢查相應的DoD是否完成，因此上一階段的DoD事實上就是下一階段的DoR。

越往前的DoD越偏業務，然後是偏技術實現，越往後的越要加入運維和非功能性要求。

2.1 DoR的一些例子

用戶故事是清晰的
用戶故事是可測試的
用戶故事是可行的
用戶故事已定義
用戶故事驗收標準已定義
用戶故事依賴已明確
用戶故事已由開發團隊做過粒度劃分
Scrum團隊已接受UI原型設計
指定場景下的性能指標已明確
指定場景下的可擴展性指標已明確
指定場景下的安全指標已明確
驗收用戶故事的人已明確
團隊都清楚用戶故事所表達的意思

三、DoD是什麼

“DoD”是開發團隊和PO對每個用戶故事需要做什麼的協定 – 通常在公司層面統一標準，以保證交付質量一致。

“DoD”通常會說明：

用戶故事所處的系統環境（哪個版本的Linux、Android、iOS或者瀏覽器）？
需要輸出什麼樣的文檔（自動生成的Javadoc，還是完整的終端用戶手冊）？
有什麼質量要求（用於演示的基本功能，還是一個功能完整，健壯的APP）？
有什麼安全要求（無安全要求，還是從代碼評審、代碼掃描到網絡安全配等各方面都要求做安全審查）？
有什麼擴展性要求（10個併發，還是10萬個併發）？

本質上說，“DoD”是基於驗收標準的協議，PO在迭代結束時同它來驗收產品增量。

請注意，針對迭代和發佈階段，DoD標準可能會不一樣。中間迭代的DoD，比起臨近發佈的幾個迭代，要求不會那麼嚴格。

3.1 DoD的一些例子

代碼已完成（所有代辦事項已經完成編碼）
代碼已註釋、已提交。版本庫當前版本能正常運行
結對檢視已完成（或者採用結對編程），代碼符合開發標準
構建沒有錯誤
單元測試全部通過
部署到測試環境並通過系統測試

通過UAT（用戶驗收測試）並簽字確認符合需求。
任何編譯/部署/配置變化都已實現/記錄/溝通。
相關文檔/圖表已完成或已更新
任務剩餘的小時數已設置為0，任務已關閉

3.2 DoD，通常需要從幾個維度考慮

為Sprint中任務給出明確的“Done”定義是非常重要的，但即使你遵循這個最佳實踐，最終仍然會有集成問題，會存在Bug，以及晚期的需求變更。所以，對於大型複雜產品，在正式發佈前，單獨計劃1～2個Sprint，專門做Bug修復，也是合理的。

關於DoD的例子，通常需要從幾個維度考慮。

1）需求/用戶故事DoD

用戶故事的描述及拆解符合INVEST；
用戶故事有驗收標準AC(Acceptance Criteria)。

2）開發任務DoD

代碼已經提交到Git;
代碼通過單元測試；
代碼經過Code Review;
代碼通過集成測試。

3）迭代DoD

所有代碼通過靜態檢測，嚴重問題都已修改；
所有新增代碼都經過Code Review；
所有完成的用戶故事都通過測試；
所有完成的用戶故事得到Product Owner的驗證。

4）發佈DoD

完成發佈規劃所要求的必須具備的需求；
至少完成一次全量回歸測試；
符合質量標準(Quality Gate)，譬如所有等級為1、2的缺陷均已修復；3、4級缺陷不超過10個；
有Release Notes；
有用戶手冊；
產品相關文檔已全部更新；
代碼已部署到發佈服務器上，並冒煙通過；
原始需求提交人完成UAT；
對運維、市場、客服的新功能培訓已完成。

Tips：DoD及WA必須是團隊共同討論出來的，團隊願意共同遵守的原則，一旦確定，團隊就應共同遵守。

四、DoD和DoR應該上牆

無論是用物理的Kanban、TaskBoard，還是電子的，建議將定義清晰的DOD，顯式的張貼出來。下圖就是很好的例子，便於所有人對齊想法，並且在板子上進行挪動時，無論是挪到Done的專題，還是拉到下一個狀態，都可以隨時看到DoD的標準，提醒所有人遵守並檢查。保證每個人對一件工作是否完成有一個統一的認識，交付和接納時時也保持清晰的交接界面。