5.3 度量的邊界——DoD（Definition of Done）

我們經常在開發過程中看到類似于這樣的現象，一個開發人員對項目經理說，這個功能快做完了，己經80％了，第二天說還差一點，一周過去了，沒做完，又一周過去了，還是沒完。

出現這種情況可能有以下兩個主要原因。

●一個原因是這個開發人員和項目經理討論的這個交付對象，也就是這個功能，可能過于復雜而存在太多不確定的因素，說白了，其實就是太大了。我們希望通過前面提到不同粒度的端到端的劃分來解決這個問題，使開發人員和管理人員應該都知道討論的對象是在什么樣一個粒度，其中包含的風險在什么樣的一個量級上。

●另一個可能的原因是，基本功能雖然實現了，但是在自測的時候，或者是在跟其他功能進行聯調，又或是測試人員測試的時候，發現了各種各樣的問題，所以一直不能完成。開發人員在計劃時間和匯報進度的時候，經常不會太注意功能編碼完成后的工作環節，低估其中的不確定性對時間產生的影響；而管理人員其實更加關心的是距離軟件可用的時間和工作量，不是編碼完成了百分之多少。要解決這個問題，我們需要對完成做出清晰的定義，使開發人員和管理人員對完成所表達的意義上有了統一的認識。

這里我們需要使用一個重要的概念——DoD（Definition of Done）。根據Dhaval Panchal在Scrum聯盟發表的一篇文章上的說法，DoD（Definition of Done）是軟件生產所需活動的一個檢查列表。這些活動可能包括：需求澄清、功能設計、編碼、單元測試、功能測試、聯調、集成測試，還有一些我們暫時在這里沒有考慮的活動，在生命周期中靠前的有需求的發現、體驗的設計，往后靠還有部署、線上反饋等相關的活動。DoD引導開發行為示意如圖5-3所示。

DoD的計劃分成以下3個層面。

（1）特性/用戶故事DoD。

（2）迭代DoD。

（3）發布DoD。

Dhaval Panchal在他的文章里提到決定各個層面DoD的策略的因素如下。

●我們是否能在特性層面完成這項活動？如果不能，那么……

●我們是否能在迭代層面上完成這項活動？如果不能，那么……

●我們需要在發布層面上完成這項活動。

對于一個軟件開發組織而言，定義不同層面的DoD分別包含什么活動取決于多項因素，例如產品本身的復雜度、業界適用的開發和測試手段，以及團隊和組織本身的復雜度。相對來說，如果交付周期非常短，比如互聯網產品，可能需要在特性級別完成所有的質量保障活動，包括性能和負載測試，真正做到精益里的單件流；而對于一個產品復雜度高、自動化測試工具不具備，或是由于硬件和環境等條件的限制導致自動化成本很高，可能就需要在拓展特性和迭代DoD的范圍時，合理權衡成本收益。

我們在幫助一個電信設備供應商的軟件團隊采納敏捷實踐的時候，評估的結果大致如下。

●產品本身生命周期很長，已有近10年的歷史。

●軟件的復雜度相當高，團隊工作在數百萬行的遺留代碼上。

●單元測試基本不存在。

●功能層面的自動化測試有限，只覆蓋少數關鍵功能，主要目的是冒煙測試。

●各個模塊之間的聯調需要數周，通常會發現大量問題。

●系統層面的自動化測試有一定的覆蓋。

●各級持續集成設施都暫時還不具備，模塊間和團隊間的接口調試依賴全部編碼完成后的集中調試階段，這個階段通常占據開發周期的20％～30％的時間（通常長達2個月）。

根據上述情況，我們推薦這個團隊起步于：

●以單元測試作為用戶故事級別的DoD；

●以功能測試作為迭代級別的DoD；

●其他質量保障活動，只能暫時在發布級別做。

對于DoD的定義并不是一成不變的。因為隨著團隊技能的擴展，更有效的工具和框架的引入，測試、構建基礎設施的完善，提前完成更多質量保障活動的投資收益平衡點是在移動的。我們對上面的這個團隊制定了下一步的目標，那就是在當前版本結束之前（6個月），通過完善各級自動化測試體系，搭建覆蓋個人構建、團隊級、版本級，以及產品級的持續集成設施，在當前版本嘗試將用戶故事的DoD拓展到功能測試，如圖5-4所示，并在下個版本實現把迭代DoD拓展到聯調和系統測試。

團隊應該對DoD的定義達成共識，并將其明確地記錄下來，嚴格執行。隨著團隊交付能力的提升，DoD應該逐漸演進。在這個演進過程中，度量體系起到的作用是牽引團隊。

（1）拓展DoD的范圍：提高用戶故事、迭代的驗證級別。

（2）提高流程和質量可靠性：減少聯調、系統測試周期的不確定性對交付時間點的影響。

（3）降低缺陷的修復成本：提前發現和去除潛在問題和缺陷。