l

2012年1月5日 星期四

Scrum 是什麼(5):初探 Sprint Planning Meeting

January 05 11:23~12:30
螢幕截圖 2015-06-11 23.38.51

前情題要:


今天介紹一下 Sprint Planning Meeting,請參考下圖:




Sprint Planning Meeting

  • 開始時間:每個 sprint 開始的第一天舉辦此會議。Teddy 的經驗是每雙週的週一(Teddy 採用長度為兩週的 sprint)早上 10:00 開始 sprint planning meeting。
  • 參加人員:Product Owner、Scrum Master、Developers。
  • 會議目的會議目的是產生一份 sprint backlog(包含每個 story 細分之後的施工項目)讓 Developers 可以開工。
  • 進行方式(1):由 Product Owner 逐一詳細介紹這個 sprint 要施工的每一個 stories,並且與 Developers 互動,如果 Developers 對於 stories 內容不了解一定要發問。 介紹完之後 Developers 開始估計每一個 story 的 story point(story point 也可能在之前的 product backlog refinement meeting 就已經先估好了,但此時還是可以重估)。此階段通常需要 2-4 小時。
  • 進行方式(2):估算好 story point 之後,接著寫出每一個 story 的施工項目(task)。例如鄉民們要開發一個網路銀行的系統,有一個 story 是 As a user, I can view today's transaction records,那麼要完成這個 story 可能的 tasks 就有設計 UI、實做 UI 程式、寫 DAO(data access object,假設資料庫 schema 已經設計好了)、寫自動化功能測試等等。所有的 tasks 都寫好之後要開始估算完成每一個 task 所需的時間(以小時為單位)。此階段通常需要 2-4 小時。
  • 結尾前:Stories 與 tasks 都估算好之後,可以準備結束會議了。在散會之前 Teddy 會請 Developers 先認領一下要施工的 tasks。以 Teddy 的經驗,如果是 10:00 開始 sprint planning meeting,通常在 15:30~16:30 左右會議就可以結束了(有時候甚至會提早在 15:00 就結束了),所以當天還有幾個小時可以施工。因此會請 Developers 在離開會議適之前先認領準備要施工的 tasks 並且在該 task 上面簽名。
  • 結尾後:Teddy 有使用 ezScrum 這套工具來管理 stories 與 tasks,所以會議結束之後 Teddy(Scrum Master)會把 stories 與 tasks 的資料打到 ezScrum 系統中,大概需要 20-30 分鐘。此外,Teddy 也有使用實體的 task baord,就是在一塊白板上面把 Stories 與 tasks 都貼上去。所以,在把資料打入 ezScrum  之後,Teddy 就會把這些實體的 story cards 與 tasks(寫在 3M 小紙條上)貼到白板上面。附帶說明一下,每一張 story card 與 task 一定要用「小磁鐵」固定在白板上,否則過幾天之後很容易跟秋天的楓葉一樣,掉滿地...Orz。


關於 story points 與 tasks 的估算方法請參考「如何估算 story point?」與「Story point 為何沒有單位:相對論篇」。以下是 ezScrum  軟體以及實體 task board 的參考畫面。



ezScrum 畫面,資料來源:http://scrum.tw/images/ezScrum/TaskBoard.png


實體的 task board,資料來源:http://scrum.tw 網站

***

有的人會把 sprint planning meeting 分成「上半場與下半場」,也就是 Teddy 上面所說得進行方式(1)與進行方式(2)」,然就建議 Product Owner 只需要「上半場」在場就可以了,之後估算 tasks 的活動如果  Product Owner 需要趕場的話就可以離開。不過以 Teddy 的經驗,很多對於需求的問題都是下半場估算 tasks 的時間才會冒出來,所以 Teddy 覺的 Product Owner 最好全程都在會比較好一點。

另外,如果團隊剛開始導入 Scrum,極有可能會覺的很難估算 story points 與 tasks,會有好幾個 sprints 的陣痛期每次 Sprint Planning Meeting 都搞得很痛苦,甚至會覺的時間不夠用無法在一天內完成。(迷之音:此為正常現象,請安心服用)。Teddy 剛開始採用 Scrum 的時候也有類似的困擾,但是時間一久這個問題就消失了。

Sprint Planning Meeting 在 Scrum 中是一個很重要的活動,因為後續的開發活動都仰賴這個會議所產生的 sprint backlog。在傳統的 waterfall  開發方式中,當 Developers 拿到所謂的「分析設計文件」的時候,他們的腦袋中可能對於接下來要如何施工還是一片空白。但在 Scrum 中由於有了Sprint Planning Meeting 這個活動,每個 Developers 去認領 tasks 時其實對於要做什麼事情自己心中多多少少已經有了底(當然在實際施工的時候還是有可能有問題產生),所以相較起來後續的施工問題會少很多。所以 Teddy 覺的 Sprint Planning Meeting 真的是一個很偉大的發明...XD。

***

今天先講到這裡,之後再補充 Sprint Planning Meeting 的其他細節。
 

***
 
友藏內心獨白:有時候選擇太多也是一種困擾。

沒有留言:

張貼留言