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

Dec. 06 15:51~18:00

Teddy小時候，記得好像是華視有一部八點檔的連續劇，叫做「藍與黑」，其中有一句對白：「一個人一生只愛一次是幸福的，很不幸的是，我卻比一次又多了一次」。12月3~4號Teddy去上了Emerson Mills的Certified ScrumMaster（CSM）課程，不知為什麼想到「藍與黑」裡面的這句對白。

Teddy內心獨白：一個人一生只上一次CSM課程是幸福的，很 不幸 幸運的是，我比一次又多了一次 。

***

話說Teddy在2009年10月22~23第一次上Certified ScrumMaster課程（請參考《Certified Scrum Master, Day 1》、《Certified Scrum Master, Day 2》），當時Teddy大約有一年半導入Scrum的經驗。在上課之前自我感覺良好的Teddy，其實內心很不願意要花四萬塊台幣來上這兩天的CSM課程。

Teddy內心獨白：我都導入Scrum一年半，也看了那麼多書，就為了這張薄薄的Certified ScrumMaster證書要花四萬元來上課，好像沒必要啊。

三年過去了，在2012年的12月初，Emerson Mills第一次在台北舉辦CSM課程。這次Teddy非去不可，因為自己是主辦單位之一 。但是在上課之前，Teddy心中還是有相同的疑問：

Teddy內心獨白：我都有導入Scrum四年半的經驗，這幾年看了更多的書，Emerson要講的東西我應該都知道了吧。

事實證明，其實不然。在這系列的文章中，Teddy想談一下在這次CSM課程中學到的經驗。

Scrum活動

上面這張圖是Emerson在上課的時候所畫的Scrum概念圖，其中包含幾個重要的Scrum活動與角色：

• 角色：Product Owner（PO）、Team（Developer）ScrumMaster（SM，圖中沒畫出來 ）、stakeholder。
• 活動：Sprint planning meeting（part 1與part 2）、daily Scrum、sprint review、retrospective、product backlog refinement。
• 產出：Product backlog、sprint backlog、potentially shippable product increment
  

以上沒什麼特別的，知道Scrum的鄉民們都聽過這些名詞。但是透過Emerson的說明，Teddy釐清，或是說瞭解到兩個新的觀點：

• Product backlog refinement進行方式：Scrum的書上告訴我們：「Scrum團隊每個sprint花大約5%的時間整理product backlog」。最常見的做法就是開一個product backlog refinement workshop。例如，一個兩週的sprint，可以在第二個禮拜的禮拜一舉辦product backlog refinement workshop。Emerson在圖中則是把product backlog refinement畫成一個連續發生的活動。Teddy自己以前在當任PO的時候，也只有開過大概2次的product backlog refinement workshop，之後都是利用平常的時間來耕耘product backlog 的內容。這次看到Emerson把圖畫成這個樣子，就頗有感受。
• Retrospective meeting回饋到sprint planning meeting part 2：自省會議討論開發流程與方法的改善，改善結果回饋到sprint planning meeting part 2（因為在part 2會議中，團隊成員產生這個sprint所需要完成的task。如果有需要改善的事項，則需要在此階段建立新的task）以往Teddy的做法是，如果有需要改善的項目，例如團隊覺得需要安排時間來架設持續整合系統，則Teddy會在product backlog中寫一個架設持續整合系統的technical story，這樣子才能夠跟PO爭取時間做這個改善工作。但是Emerson自己是很少在product backlog中寫technical story，他認為改善工作應該直接回饋到sprint planning meeting part 2。概念上的確是如此，因為PO對technical story要做什麼事情基本上是完全都不知道的，所以在sprint planning meeting part 1的時候，PO也無法幫團隊解釋technical story的內容，所以概念上改善工作只有在sprint planning meeting part 2的時候由開發團隊自己討論決定。但Teddy還是習慣把technical story放入product backlog裡面，不然PO會覺得很奇怪，為什麼某一個sprint裡面，他提出來的story沒有辦法被做完（因為團隊在sprint planning meeting part 2安排太多的task來解決流程或是技術改善的問題）。
  

整個教室貼滿了Emerson畫的圖。

***

友藏內心獨白：很充實的兩天啊。