敏捷實踐經驗分享，企業如何在敏捷開發中實施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 。