l

2015年12月7日 星期一

Sprint planning meeting的四種方式

Dec. 06 10:38~11:46

螢幕截圖 2015-12-06 11.44.37

 

今天談一個基本的問題:Sprint planning meeting(衝刺計畫會議)進行的方式。

區分Part 1、Part 2

Sprint planning meeting可以區分為part 1(上半場)、part 2(下半場),前者討論需求內容(what to do),後者討論實作方法(how to do)。常見的進行方式為:

  1. 在part 1由Product Owner解釋這個sprint所預計要完成的story內容,團隊成員可以透過planning poker對story進行估算(估算相對大小或是T-Shirt size)。在此估算的主要目的是溝通團隊成員對於需求的理解,拉近彼此對於需求範圍的共識。
  2. 在part 2由團隊成員將每一個story切割成若干個task,例如設計UI、設計資料庫表格、撰寫stored procedure、撰寫若干個classes等。接著團隊成員利用planning poker來估算完成每一個task所需的工時。與估算story類似,這裡的估算其主要目的也是溝通團隊成員對於task的理解,拉近彼此對於task範圍的共識,而不是要獲得一個精準不可動搖的「工時估計」。

Sprint planning meeting進行方式在概念上就是如此。看到這裡鄉民們可能會有一個問題:「怎麼知道這個sprint可以做多少story?」有兩種常用的方式:

  • Velocity based:依據之前每個sprint所完成的story point為參考基準來決定這個sprint可以做多少事情。
  • Commitment based:一次挑一個story,直到團隊認為無法完成更多的story為止 。

***

Part 1、Part 2交錯進行

概念上sprint planning meeting可以區分為part 1、part2,但實際進行方式並不一定要part 1執行完畢才進行part 2,也可能估算完一個story之後,馬上就對這個story進行切割task,也就是part1、part 2交錯進行。

有些團隊會使用團隊成員這個sprint可以投入到專案的工作時數來作為挑選story數量的依據,將part 1、part 2交錯進行,可以避免part 1 討論太多story而在part 2估算工時之後才發現根本做不了那麼多功能。

***

Part 2採用Just In Time方式進行

還有一種方式是團隊在part 1決定這個sprint可以做多少story之後sprint planning meeting會議就結束了,等到每一個story要被施工的時候才即時切割task。這麼做的好處是,可以讓團隊聚焦在同一個高優先權的story一起完成(因為優先權比較低的story還沒被切割成task),也可以減少事先切割所有story的task但最後有些story沒做完所造成的切割task時間浪費。

這種方式的缺點,因為每次只看一個story,如果story之間有比較緊密的關係或相依性,可能造成見樹不見林的現象,在實作後面的story的時候才發現需要回頭修改原本已經完成的story。

***

根本沒有Part 2

有些團隊把story直接綁定在團隊成員身上,由一個或是一對成員完成一個story。只管團隊成員是否了解story要做什麼(what to do),而不管怎麼做(how to do),因此也就不需要part 2來切割task的團體活動。認領每一個story的團隊成員自己決定要如何完成這個story,要切不切task都可以(就算切了task也沒人會來幫你做,因為別人都在忙自己手上的story)。

***

依據專案與團隊成員的特性,以上四種方式都有人使用。什麼,你問除了以上四種還有沒有其他方式?等鄉民們跟Teddy分享。

***

友藏內心獨白:可以沒有part 1嗎?

沒有留言:

張貼留言