敏捷實踐經(jīng)驗分享，企業(yè)如何在敏捷開發(fā)中實施DoD
一、什么是DoD？
創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、翁源網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場景定制、成都做商城網(wǎng)站、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為翁源等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
當你有兩個或更多的人參與同一個事情的時候，我們的“團隊”就產(chǎn)生了，這時我們最重要的事情，就是要設(shè)定和統(tǒng)一團隊的期望值，在本文中，這就是 “完成標準”。
一個迭代做完后，團隊要進行驗收，來決定本個迭代是否完成。但每個團隊對于是否完成無法達成統(tǒng)一，有的認為編碼完成，就表示任務(wù)完成了；有的認為還需要簡單自測一下，確保功能可以正常使用；還有的認為需要把自動化用例寫完并測試通過才算完成。
為了避免這個問題，在敏捷軟件開發(fā)中，常用 Definition of Done“完成的定義”來表示工作是否已完成，不同的活動有不同的完成定義。首先要知道，所有的DoD都不是一成不變的，在隨著時間的推移、經(jīng)驗的積累、成員的變更、項目的變更，我們的DoD也會有很大的不同，所以，我們也需要定期地檢查和改進。
二、 DoD的分類
有了上面的思想準備，我們再來看下面的DoD定義，就會覺得并沒有那么難了。
一、迭代DoD
最典型的是迭代DoD，這也是最初DoD應(yīng)用的地方。常見的一些規(guī)則有：
1. 所有代碼通過靜態(tài)檢測，嚴重問題都已修改，靜態(tài)分析的規(guī)則參見...
2. 所有新增代碼得到人工評審
3. 所有完成的用戶故事都有對應(yīng)的測試用例
4. 測試用例都已執(zhí)行
5. 所有完成的用戶故事得到Product Owner的驗證
二、發(fā)布DoD
對于發(fā)布，一般就有更加嚴格的要求，發(fā)布DoD的典型條款有：
1. 完成發(fā)布規(guī)劃所要求的重點需求
2. 至少通過一次全量回歸測試
3. 修復(fù)所有等級為1、2的缺陷，3、4級缺陷不超過20個
三、版本DoD
版本DoD就是針對每個版本上線前后的一些規(guī)則，比如：
1. 產(chǎn)品文檔已全部更新
2. 代碼已部署到產(chǎn)品服務(wù)器上
3. 運維在驗收測試環(huán)境上冒煙通過
4. 原始需求提交人對功能已經(jīng)驗收通過
5. 對運維、市場、客服的新功能培訓(xùn)已完成
四、每日DoD
其他典型的DoD有每日DoD，典型條款有：搭建每日構(gòu)建環(huán)境，晚上自動靜態(tài)代碼檢查、編譯、部署和測試，每日修復(fù)前一日構(gòu)建和測試發(fā)現(xiàn)的缺陷和問題。
1. 下班前必須檢入當天編寫的代碼，check in的backlog要填寫清晰
2. 當天的代碼必須在當天或者第2天邀請同伴進行代碼評審
3. 檢入的功能代碼必須要有對應(yīng)的單元測試（嚴格采用TDD）
4. 每天晚上觸發(fā)靜態(tài)代碼檢查、自動化回歸測試
5. 當天持續(xù)集成、構(gòu)建環(huán)境中的問題，請當天解決
五、用戶故事DoD
還有針對用戶故事（或者用例）的DoD，比如：
1. 用戶故事最終的描述符合INVEST
2. 用戶故事得到測試用例的對應(yīng)覆蓋
3. 用戶故事得到對應(yīng)的自動化測試用例
4. 用戶故事得到PO試用并初步認可
當測試集比較大的時候，無法在1天之內(nèi)完成測試，可以開展每周全量回歸自動化測試，這樣就有每周DoD，典型條款有：
1. 上上周發(fā)現(xiàn)的缺陷是否解決
2. 上周新增功能的自動化測試是否加入到每周測試集。
Tips：DoD 必須是團隊在項目啟動時共同討論出來的，團隊愿意共同遵守的原則，一旦確定，團隊就應(yīng)共同遵守。
三、DoD的實用價值
一、DoD是對軟件有價值的活動的清單
DoD是一個簡單的清單，包含了一系列的活動。例如：編碼，加注釋，單元測試，集成測試，發(fā)行聲明，設(shè)計文檔等等。所有這些活動都能夠給產(chǎn)品帶來實際的價值。使用DoD，可以讓團隊集中在那些必須完成的事情上，同時讓那些無用的，僅僅使軟件開發(fā)變得復(fù)雜的活動被消除掉。
二、DoD是團隊成員的主要狀態(tài)參考依據(jù)
對于迭代最簡單形式的匯報就只有一句話：“這個feature完成了”。畢竟，一個feature或者一個product Backlog Item的狀態(tài)只有兩種：完成或未完成 。DoD是對“feature完成了”這句話的最佳補充。使用DoD作為參考標準，團隊成員可以迅速有效地讓其他團隊成員或PO了解狀態(tài)。
三、DoD不是不變的
DoD隨著時間會改變。組織的幫助和團隊能力的增加可以移除掉更多障礙，使得更多的活動可以包含到sprint或者feature的DoD中來。
四、DoD是一個可以被審視的列表
feature/用戶故事在sprint plan meeting和sprint中都可以被拆分成task。DoD可以用來衡量是不是所有的主要工作都被計劃在內(nèi)的（剩余的時間）。而且，在一個feature或者sprint結(jié)束的時候，DoD可以用來考查是不是所有的必須的增值活動都已經(jīng)完成了。
必須引起注意的是，DoD本身也是存在缺陷的。并不是所有的增值活動都可以應(yīng)用到每一個feature上面，而DoD本身是一個大而全的檢查事項的審核制度。團隊需要基于一個feature來審視每項增值活動是否適用于這個feature。
比如說，追求用戶體驗對于web服務(wù)這樣的feature來說可以加分，但是對于其他的一些feature來說就是不必要的了。
最后需要注意的是，對于驗收標準，并不一定是由Product owner決定，要根據(jù)顯示情況而定， 每個團隊都要根據(jù)自己的情況選擇合適的DoD原則。 CORNERSTONE 提供了包括任務(wù)/需求/測試管理、迭代規(guī)劃、缺陷追蹤、報表統(tǒng)計、團隊協(xié)作 、WIKI、共享文件和日歷等功能模塊 ,20人以下團隊可免費使用,點擊即可免費注冊 CORNERSTONE 。
新聞名稱：敏捷實踐經(jīng)驗分享，企業(yè)如何在敏捷開發(fā)中實施DoD
文章地址：http://m.jiaotiyi.com/article/giisio.html