我在第二次Certified ScrumMaster課程學到的事（3）

Dec. 10 10:54~11:44

Definition of Done (DoD)

採用Scrum的團隊，在每一個sprint結束的時候，「理想上」應該能夠完成一個「潛在可交付產品」（potentially shippable product）。問題是怎樣的產品才叫做「可交付」呢？如何才能確定團隊是否有真正把需求給做完？為了因應這個問題，Scrum團隊要針對「做完」這件事情下一個定義。上圖就是Emerson在課程中與學員互動討論出來的DoD項目。這裡有兩篇DoD的文章鄉民們可以參考一下：《功課寫完沒: The definition of done》、《用 Kanban + Scrum 支援大型專案(4)：DoD》。

沒做完會怎樣?

如果每個sprint結束時，都有事情沒做完怎麼辦？舉個例子，假設團隊把「撰寫單元測試」列為DoD項目，但是在sprint結束時都沒有時間把單元測試寫完，如此一來便會留下一些undone work（未完成的工作）或是「半成品」（請參考《消除浪費 (1)：Partially Done Work》）。請參考下圖上半部，隨著時間過去，這些遺留下來的undone work越來越多，就好像雪球一樣越滾愈大。假設到了某一天公司決定要把產品上市（老闆以為團隊把產品功能都做好了），由於還有一堆undone work還沒完成，因此團隊就需要規劃好幾個「release sprint」來把這些undone work做完。這些undone work就會造成專案延遲必且提高專案的風險，例如，如果平時都沒有做測試，等到產品準備上市前才來測，很可能會造成測試時間很長，或是在專案後期才發現非常嚴重的bug，而修復這些bug再加上之後的測試，又不知道要花多少時間。

 

上圖下半部則是希望每次sprint結束時，undone work都可以被控制在很小的一個範圍之內，例如，只有少數bug需要修正，或是只有一些文件需要撰寫。如果可以做到這樣的境界，那麼當公司準備釋出產品的時候，團隊只需要很短的時間，也許1~2個sprint，就可以將產品推出上市。如果能夠做到每個sprint結束時所產生的產品都達到production水準，那就可以依據客戶的需要，隨時釋出產品，而且可以保證產品具備一定的水準與品質。

***

友藏內心獨白：短期可以朝向縮短「release sprint」的個數作為目標。