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 的其他細節。
 

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

4 則留言:

  1. 你好,依照貴司的經驗, User Story 對應的 Wireframe 是在 Sprint Planning Meeting 前就已經繪製好的嗎?
    還是說會列在每個 Story 對應的 Task 裡,後續由產品繪製呢?

    回覆刪除
    回覆
    1. Wireframe 要在 Sprint Planning之前還是之後繪製,要看你們的需求與工作模式。如果你把繪製Wireframe當作需求探索的一部分,你可以在Sprint Planning之前繪製。反之,繪製Wireframe變成某個Story的工作項目之一。

      刪除
    2. 感謝答覆!
      感覺Wireframe 先畫完似乎比較好
      因為這樣開發、UI在估算 User Story 的工時會更加準確

      又聯想到幾個問題:
      1. 如果Wireframe 沒有先準備好,單就 User Story 來估算,是不是會常常遇到工時估計不準確的狀況呢?(畢竟還不是很確定會有多少欄位或功能邏輯)

      2. 若 Sprint 過程中,發現需要 Charge 工時,進而擠壓到其他 User Story 開發的時間,這樣的話,未完成的User Story 是不是就該回到 Product backlog 裡面?

      3. Sprint backlog 裡的 User Story 應該要拆解成多個 Task,但在 Wireframe 還未完成的裝況下,感覺就很容易拆解成:
      (1) Wireframe 繪製
      (2) UI 設計
      (3) 開發實作
      (4) 測試
      (5) 驗收
      感覺突然又有瀑布式的影子出現了XD
      不太清楚 Task 的範圍、細度

      4. 如果User Story 相互依附的關係很高,是不是就乾脆整合成一個就好呢?

      舉例有個 User Story 是:
      「身為交易用戶,我需要可以自由的新增/修改/查詢/刪除投資筆記,才能幫助我覆盤。」

      而另個依附性很高的 User Story 是:
      「身為交易用戶,我需要可以在投資筆記上傳圖片,才能幫助我在覆盤過程對照線圖。」

      不太清楚在敏捷的概念下 User Story 顆粒要多細 QQ

      5. 請問新導入敏捷的初期若不用 story point 估算 story 大小,而單用小時估算 story 底下的 task ,會違背敏捷的精神嗎?

      刪除