用 Kanban + Scrum 支援大型專案(4)：DoD

Nov. 13 12:57~14:20

 

Teddy之前在介紹Scrum的時候有提到Definition of Done（DoD）的觀念（請參考《功課寫完沒: The definition of done》）。在加入專案看板之後，Henrik Kniberg認為至少有兩個DoD需要被定義：Ready for Development與Ready for System Test。請鄉民們參考《用 Kanban + Scrum 支援大型專案(2)：分組方式》，這兩個DoD剛好分別用來規範需求分析團隊交付需求給功能團隊進行開發的條件，以及功能團隊將開發完成的功能交給系統測試團隊進行測試的條件。

***

Ready for Development

當需求分析團隊將需求寫成story（將epic細切成story），準備交付給功能團隊進行開發時，這些需求就進入「ready for development」階段。要進入此階段的需，必須符合下列條件：

• 有一個ID：因為Henrik Kniberg有使用其他的資訊系統，例如專案的wiki網頁來記錄其他有關需求的資料，因此每一個準備交付開發的需求，都必須要有一個ID。
• 有聯絡人：還記得Teddy在《需求分析書中最重要的資訊是什麼？》提到的答案--寫這本需求分析書的那個人的電話號碼 。由於需求是由需求分析團隊所共同負責，那如果施工的時候有問題要找誰？每一個準備交付開發的需求就必須要有聯絡人的資訊，當開發團隊對這個需求有疑問時，才知道要找誰詢問。
• 對顧客有價值：對客戶有價值的需求才需要實作，這個欄位是用來提醒需求分析團隊，當功能從大需求（epic）切割成story之後，這些細切的story，是否依然對客戶有價值。
• 經過團隊估算：每個需求必須經過團隊估算，Henrik Kniberg採用所謂的T-shirt尺寸（大、中、小）的方式來估算需求。小需求表示「在理想狀況下，這個需求可以被最合適的人，在五個工作天之內做完並且達到ready for system test的狀態」。中需求表示需要10個工作天，而大需求則是超過10個工作天以上，必須被進一步的細切。也就是說，最後交付給開發團隊的需求，只能是小需求或是中需求。這個作法感覺有種想要達到Lean Production所說的「平準化」的目的，又有點類似Scrum，希望每一個story都可以在1個為期兩週的sprint之內開發完成。
• 有描述驗收測試：類似Scrum的Story Card上面的How to Demo欄位，讓開發人員知道這個需求會如何被驗收。

Ready for development的DoD條件其實就跟下圖Story Card的欄位幾乎一模一樣，唯一的差別是Ready for development的條件加了一個聯絡人的資訊。

 

Ready for System Test

當開發人員把功能做完之後，就可以準備交給系統測試團隊進行測試，要進入此階段的需，必須符合下列條件：

• 自動化驗收測試：開發團隊必須要撰寫自動化的驗收測試，而且這些驗收測試必須要通過。例如，使用Selenium來測試瀏覽器應用系統。
• 通過回歸測試：除了專屬於這個功能的測試必須通過之外，原先已經寫好的測試案例也必須全部通過。
• 已經demo過了：做好的功能必須先讓PO或是客戶代表給看過，而且確認功能與操作方式都OK。
• 有清楚的check-in說明：開發團隊把功能做好之後，必須要把程式碼送交到版控系統中，此時必須清楚交代此次送交的程式碼的內容。
• 在開發環境中（例如，持續整合系統）通過測試：除了在開發人員自己的電腦中測試過這個功能以外，還必須要在團隊所建構的測試環境中通過測試才可以。
• 合併至版控系統的主幹（trunk）：一切都沒問題之後，就要把這個功能的程式碼合併到版控系統的主幹之中。

***

以上這些DoD條件只是Henrik Kniberg在《Lean from the Trenches: Managing Large-Scale Projects with Kanban》書中所提到的例子，並非什麼「標準答案」，鄉民們可以依據團隊與專案特性自行增減項目與內容。

***

友藏內心獨白：同一件工作，在不同工作階段也可以有不同的DoD。