l

2012年12月6日 星期四

我在第二次Certified ScrumMaster課程學到的事(1)

Dec. 06 15:51~18:00

螢幕快照 2012-12-06 下午4.18.35

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活動

螢幕快照 2012-12-06 下午3.54.02

上面這張圖是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來解決流程或是技術改善的問題)。

螢幕快照 2012-12-06 下午6.22.22

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

***

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

沒有留言:

張貼留言