當Pattern遇到Scrum（6）：Definition of Done

June 20 13:28~14:57

Definition of Done Pattern

今天談Definition of Done，簡稱DoD。該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：有幾位團隊成員展示「已完成」的Product Backlog Item給Product Owner看。Product Owner詢問Development Team何時可以使用這個功能，團隊成員表示該功能還需要額外的測試與系統遷移工作，而這些工作又相依於另外一件工作，所以現在還不能上線。經過進一步討論，另一位團隊成員表示由於這個功能是系統的核心功能，因此上線之前還需要經過審核。「那到底何時才可以完成呢？」Product Owner感到很困擾，團隊成員剛剛展示了這個功能，但還有更多的工作需要完成這個功能才算做完。

Problem：如何確保Scrum團隊對於開發團隊所交付完成的工作有相同的認知？

Forces：

• 在Sprint Review的時候Product Owner需要知道實際的開發進度才可根據此回饋做出相對應的決策。
• 團隊在Sprint結束時應該交付Potentially Shippable Product Increment（潛在可交付產品增量），如果它的品質低於利害關係人的要求，該次增量就無法釋出，需要額外的時間來讓產品變得更穩定。
• 不佳的品質與不預期的延遲最終可能會怪罪於團隊而造成團隊的緊張與壓力。為了真正成為一個團隊，團隊成員必須共同努力在品質上保持一致。
• 對於完成的認知不是只有針對外部看得到的東西，任何對於利害關係人與開發團隊有價值的東西都應該包含在內。例如，依循編程規範的所撰寫的程式碼讓開發人員在日後的開發活動中更加順利。
• 團隊成員很容易有意無意地隱藏他們跳過編程規範或品質要求的事實，因此產生了技術債。產品的外部品質可以在Sprint Review討論，即使你很信任團隊會努力把產品做到做好，也需要一個機制來規範產品內部品質。

Solution：所有Scrum團隊完成的工作都必須遵循開發團隊與Product Owner所同意的標準，此標準稱為Definition of Done（DoD）。「做完」表示開發團隊確認依據DoD的標準沒有任何已知未完成的工作，如果工作沒有符合DoD的要求，依據定義該工作就是沒有做完，而該工作所對應的Product Backlog Item也不能交付。

***

討論

Scrum並沒有規範團隊要採用何種敏捷實務做法，例如要不要做pair programming、BDD/TDD、CI等，只是從「黑箱」的角度要求每一個sprint結束要產生Potentially Shippable Product Increment（潛在可交付產品增量）。怎麼產生？不知道。每個sprint要能夠產生潛在可交付產品增量是一個很大的挑戰，在Scrum的框架之下透過調整DoD來增進產品品質因而達到在sprint結束有能力產出潛在可交付產品增量是最直接的做法。

DoD並不是要求團隊做出「完美無瑕」的產品，因為為了達到完美無瑕可能需要付出不合理的過高成本。因此DoD需要開發團隊與Product Owner一起定義，在追求量與追求品質之間獲得平衡。

DoD可以隨著團隊對於Scrum的理解度、敏捷力與技術能力增加而逐次加強。實務上有時候Product Owner可能會要求累積一點技術債以縮短開發時間（例如趕著參加展覽），但要記得如果產品要持續開發，短時間欠下的技術債越早還越好，以免最後被技術債所造成的利息壓到喘不過氣來，導致軟體變成硬體就敏捷不起來了啊。

***

友藏內心獨白：累積技術債除了經濟上的利息還有團隊心理上的利息。