起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識什么是DoD原則？
在之前文章中我們提到了，每個Sprint都要驗收才能算結束，而驗收標準遵循DoD原則。那么究竟什么是DoD原則呢？我們將在本文為您詳細講解。
一、什么是DoD？
當你有兩個或更多的人參與同一個事情的時候，我們的“團隊”就產生了，這時我們最重要的事情，就是要設定和統一團隊的期望值；在本文中，這就是“完成標準”。
一個迭代做完后，團隊要進行驗收，來決定本個迭代是否完成。
但每個團隊對于是否完成無法達成統一，有的認為編碼完成，就表示任務完成了；有的認為還需要簡單自測一下，確保功能可以正常使用；還有的認為需要把自動化用例寫完并測試通過才算完成。
為了避免這個問題，在敏捷軟件開發中，常用Definition of Done“完成的定義”來表示工作是否已完成，不同的活動有不同的完成定義。
首先要知道：所有的DoD都不是一成不變的，在隨著時間的推移、經驗的積累、成員的變更、項目的變更，我們的DoD也會有很大的不同，所以我們也需要定期地檢查和改進。
二、DoD的分類
有了上面的思想準備，我們再來看下面的DoD定義，就會覺得并沒有那么難了。
1. 迭代DoD
最典型的是迭代DoD，這也是最初DoD應用的地方。
常見的一些規則有：
- 所有代碼通過靜態檢測，嚴重問題都已修改，靜態分析的規則參見……
- 所有新增代碼得到人工評審；
- 所有完成的用戶故事都有對應的測試用例；
- 測試用例都已執行；
- 所有完成的用戶故事得到Product Owner的驗證。
2. 發布DoD
對于發布，一般就有更加嚴格的要求，發布DoD的典型條款有：
- 完成發布規劃所要求的重點需求；
- 至少通過一次全量回歸測試；
- 修復所有等級為1、2的缺陷；3、4級缺陷不超過20個。
3. 版本DoD
版本DoD就是針對每個版本上線前后的一些規則，比如：
- 產品文檔已全部更新；
- 代碼已部署到產品服務器上；
- 運維在驗收測試環境上冒煙通過；
- 原始需求提交人對功能已經驗收通過；
- 對運維、市場、客服的新功能培訓已完成。
4. 每日DoD
其他典型的DoD有每日DoD，典型條款有：搭建每日構建環境，晚上自動靜態代碼檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。
- 下班前必須檢入當天編寫的代碼，check in的backlog要填寫清晰；
- 當天的代碼必須在當天或者第2天邀請同伴進行代碼評審；
- 檢入的功能代碼必須要有對應的單元測試（嚴格采用TDD）；
- 每天晚上觸發靜態代碼檢查、自動化回歸測試；
- 當天持續集成、構建環境中的問題，請當天解決。
5. 用戶故事DoD
還有針對用戶故事（或者用例）的DoD，比如：
- 用戶故事最終的描述符合INVEST
- 用戶故事得到測試用例的對應覆蓋
- 用戶故事得到對應的自動化測試用例
- 用戶故事得到PO試用并初步認可
當測試集比較大的時候，無法在1天之內完成測試，可以開展每周全量回歸自動化測試，這樣就有每周DoD，典型條款有：
- 上上周發現的缺陷是否解決；
- 上周新增功能的自動化測試是否加入到每周測試集。
Tips：DoD 必須是團隊在項目啟動時共同討論出來的，團隊愿意共同遵守的原則，一旦確定，團隊就應共同遵守。
三、DoD的實用價值
1. DoD是對軟件有價值的活動的清單
DoD是一個簡單的清單，包含了一系列的活動。
例如：編碼、加注釋、單元測試、集成測試、發行聲明、設計文檔等等，所有這些活動都能夠給產品帶來實際的價值。使用DoD，可以讓團隊集中在那些必須完成的事情上，同時讓那些無用的，僅僅使軟件開發變得復雜的活動被消除掉。
3. DoD是團隊成員的主要狀態參考依據
對于迭代最簡單形式的匯報就只有一句話：“這個feature完成了”。
畢竟，一個feature或者一個product Backlog Item的狀態只有兩種：完成或未完成 。
DoD是對“feature完成了”這句話的最佳補充。使用DoD作為參考標準，團隊成員可以迅速有效地讓其他團隊成員或PO了解狀態。
3. DoD不是不變的
DoD隨著時間會改變。
組織的幫助和團隊能力的增加可以移除掉更多障礙，使得更多的活動可以包含到sprint或者feature的DoD中來。
4. DoD是一個可以被審視的列表
feature/用戶故事在sprint plan meeting和sprint中都可以被拆分成task。
DoD可以用來衡量是不是所有的主要工作都被計劃在內的（剩余的時間），而且，在一個feature或者sprint結束的時候，DoD可以用來考查是不是所有的必須的增值活動都已經完成了。
必須引起注意的是：DoD本身也是存在缺陷的。并不是所有的增值活動都可以應用到每一個feature上面，而DoD本身是一個大而全的檢查事項的審核制度。團隊需要基于一個feature來審視每項增值活動是否適用于這個feature。
比如說：追求用戶體驗對于web服務這樣的feature來說可以加分，但是對于其他的一些feature來說就是不必要的了。
最后需要注意的是：對于驗收標準，并不一定是由Product owner決定，要根據顯示情況而定，每個團隊都要根據自己的情況選擇合適的DoD原則。
#專欄作家#
袁林，人人都是產品經理專欄作家。分享SaaS運營和企業管理／協作／辦公的相關知識
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
文章寫得很好，很多小伙伴不是缺乏動力，而是對驗收標準（目標）理解不一致
不錯