敏捷實踐經驗分享，企業如何在敏捷開發中實施DoD

一、什么是DoD？

當你有兩個或更多的人參與同一個事情的時候，我們的“團隊”就產生了，這時我們最重要的事情，就是要設定和統一團隊的期望值，在本文中，這就是 “完成標準”。

一個迭代做完后，團隊要進行驗收，來決定本個迭代是否完成。但每個團隊對于是否完成無法達成統一，有的認為編碼完成，就表示任務完成了；有的認為還需要簡單自測一下，確保功能可以正常使用；還有的認為需要把自動化用例寫完并測試通過才算完成。

為了避免這個問題，在敏捷軟件開發中，常用 Definition of Done“完成的定義”來表示工作是否已完成，不同的活動有不同的完成定義。首先要知道，所有的DoD都不是一成不變的，在隨著時間的推移、經驗的積累、成員的變更、項目的變更，我們的DoD也會有很大的不同，所以，我們也需要定期地檢查和改進。

二、 DoD的分類

有了上面的思想準備，我們再來看下面的DoD定義，就會覺得并沒有那么難了。

一、迭代DoD

最典型的是迭代DoD，這也是最初DoD應用的地方。常見的一些規則有：

1.  所有代碼通過靜態檢測，嚴重問題都已修改，靜態分析的規則參見...

2.  所有新增代碼得到人工評審

3.  所有完成的用戶故事都有對應的測試用例

4.  測試用例都已執行

5.  所有完成的用戶故事得到Product Owner的驗證

二、發布DoD

對于發布，一般就有更加嚴格的要求，發布DoD的典型條款有：

1.  完成發布規劃所要求的重點需求

2.  至少通過一次全量回歸測試

3. 修復所有等級為1、2的缺陷，3、4級缺陷不超過20個

三、版本DoD

版本DoD就是針對每個版本上線前后的一些規則，比如：

1.  產品文檔已全部更新

2.  代碼已部署到產品服務器上

3.  運維在驗收測試環境上冒煙通過

4.  原始需求提交人對功能已經驗收通過

5.  對運維、市場、客服的新功能培訓已完成

四、每日DoD

其他典型的DoD有每日DoD，典型條款有：搭建每日構建環境，晚上自動靜態代碼檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。

1.  下班前必須檢入當天編寫的代碼，check in的backlog要填寫清晰

2.  當天的代碼必須在當天或者第2天邀請同伴進行代碼評審

3.  檢入的功能代碼必須要有對應的單元測試（嚴格采用TDD）

4.  每天晚上觸發靜態代碼檢查、自動化回歸測試

5.  當天持續集成、構建環境中的問題，請當天解決

五、用戶故事DoD

還有針對用戶故事（或者用例）的DoD，比如：

1.  用戶故事最終的描述符合INVEST

2.  用戶故事得到測試用例的對應覆蓋

3.  用戶故事得到對應的自動化測試用例

4.  用戶故事得到PO試用并初步認可

當測試集比較大的時候，無法在1天之內完成測試，可以開展每周全量回歸自動化測試，這樣就有每周DoD，典型條款有：

1.  上上周發現的缺陷是否解決

2.  上周新增功能的自動化測試是否加入到每周測試集。

Tips：DoD 必須是團隊在項目啟動時共同討論出來的，團隊愿意共同遵守的原則，一旦確定，團隊就應共同遵守。

三、DoD的實用價值

一、DoD是對軟件有價值的活動的清單

DoD是一個簡單的清單，包含了一系列的活動。例如：編碼，加注釋，單元測試，集成測試，發行聲明，設計文檔等等。所有這些活動都能夠給產品帶來實際的價值。使用DoD，可以讓團隊集中在那些必須完成的事情上，同時讓那些無用的，僅僅使軟件開發變得復雜的活動被消除掉。

二、DoD是團隊成員的主要狀態參考依據

對于迭代最簡單形式的匯報就只有一句話：“這個feature完成了”。畢竟，一個feature或者一個product Backlog Item的狀態只有兩種：完成或未完成 。DoD是對“feature完成了”這句話的最佳補充。使用DoD作為參考標準，團隊成員可以迅速有效地讓其他團隊成員或PO了解狀態。

三、DoD不是不變的

DoD隨著時間會改變。組織的幫助和團隊能力的增加可以移除掉更多障礙，使得更多的活動可以包含到sprint或者feature的DoD中來。

四、DoD是一個可以被審視的列表

feature/用戶故事在sprint plan meeting和sprint中都可以被拆分成task。DoD可以用來衡量是不是所有的主要工作都被計劃在內的（剩余的時間）。而且，在一個feature或者sprint結束的時候，DoD可以用來考查是不是所有的必須的增值活動都已經完成了。

必須引起注意的是，DoD本身也是存在缺陷的。并不是所有的增值活動都可以應用到每一個feature上面，而DoD本身是一個大而全的檢查事項的審核制度。團隊需要基于一個feature來審視每項增值活動是否適用于這個feature。

比如說，追求用戶體驗對于web服務這樣的feature來說可以加分，但是對于其他的一些feature來說就是不必要的了。

最后需要注意的是，對于驗收標準，并不一定是由Product owner決定，要根據顯示情況而定， 每個團隊都要根據自己的情況選擇合適的DoD原則。 CORNERSTONE  提供了包括任務/需求/測試管理、迭代規劃、缺陷追蹤、報表統計、團隊協作 、WIKI、共享文件和日歷等功能模塊 ,20人以下團隊可免費使用,點擊即可免費注冊 CORNERSTONE 。