l

2012年1月11日 星期三

Scrum 是什麼(6):Sprint Planning Meeting 眉角

January 11 09:51~11:22

螢幕截圖 2015-06-11 21.24.46

前情題要:


對於一個剛開始導入 Scrum 的團隊,sprint planning meeting 最頭大的問題應該是「如何決定每一個 story 的 story point 以及 task 所需的時間」。關於 story points 與 tasks 的估算方法請參考「如何估算 story point?」與「Story point 為何沒有單位:相對論篇」。今天 Teddy 要講的是,假設團隊有 5 個人,現在要估算某個 story 的 story point,結果 5 個人出的牌(假設團隊用 Scrum Planning Poker 的方式用來估算點數)點數分別是:

  • A:13
  • B:2
  • C:20
  • D:?(問號)
  • E:5

那麼這個 story 的 story point 要算多少?會出現這種估算結果,通常有幾個原因:

  • 團隊成員對於 Product Owner 所解釋的需求內容產生了「一個 story 各自表述」的現象,所以才會出現 B 認為只需要 2 點而 C 認為需要 20 點這麼大的差距。遇到這樣的情況可以請每個人說明一下他們估算點數的依據,如果時間不夠也可以請差距最大的兩方(B 和 C)說明就好。經過一番說明與討論之後(Product Owner 和團隊成員要互相討論)Scrum Master 請大家再重新估算一次,通常這個時候估算的結果差異會比較小。重複這個過程一直到得到一個大家都認可的點數為止。有人會問如果一直都沒有得到一個大家認可的點數該怎麼辦?重估的過程 Teddy 最多大概只會進行兩次(包含第一次的估算,最多一共估算三次),如果此時還是無法得到共識,Teddy 會自行決定一個「合理」的點數,通常團隊成員也 不敢 不會有太大的意見(因為一直重估太多次大家也是會累的...XD)。
  • 完全不了解這個 story (或是 task)是要做什麼的。例如,D 出了?(問號)這張牌,表示他對於這個 story (或是 task)完全不了解。此時就要請 Product Owner 針對 D 不了解的地方再次說明。如果估算的是 task 的話,則可以請對於實做該 task 有經驗的團隊成員說明一下。之後,回到上一點所說得,再次重估。
  • 團隊成員不合作。剛開始實施 Scrum 時可能會有那種打死不合作的「刀民」,就是不想了解也不想認真參與估算,總是會在旁邊講一些有的沒的風涼話。如果是這樣的情況,Scrum Master 可以選擇先把該刀民當成隱形人(小時候玩捉迷藏不是有一種人叫做「烏鴉」的嗎?),告訴他先看看別人如何估算,等他了解之後再加入估算的活動(迷之音:如果團隊成員全部都是刀民...Orz)。
有一件很重要的事情 Scrum 團隊要銘記於心,Scrum 所設計的各種活動其目的是要強調「溝通」,尤其是「面對面的溝通」。如果只是想從 Product Owner 所寫出來 不清不楚 ... 嗯嗯,那一句短短的 story(As a user, I can...)就可以知道程式要怎麼寫,那是不可能的。所以在 sprint planning meeting 的過程中,團隊成員對於 story 與 task 有任何不了解的地方,一定要立即發問,主動參與。Teddy 最怕那種在 sprint planning meeting 中都不開口的團隊成員,看起來好像都沒問題,但是等真正開工之後,這種人通常問題最多。

***

開 sprint planning meeting 是一件很累人的活動,但對於日後 sprint 的進行是否順利有著決定性的影響。對於剛開始實施 Scrum 的團隊,sprint planning meeting 很可能會佔據一整天(6-7 小時)的時間,而且開完會之後對於接下來要做的事情可能還是會有一種「毛毛的感覺」。這種現象可能會持續一段時間,例如半年以上。等團隊成員默契慢慢培養起來之後,sprint planning meeting 就會進行的比較順利至少大部分的時間都可以花在「討論真正的問題上面」,而不是花在處理「刁民」與「派大星(拒絕動腦筋的人)」身上。
 
最後一個重點,如果快到下班時間而 sprint planning meeting 還沒開完怎麼辦?要明天繼續嗎?No, no, no, 千萬不要。請記得 agile 的核心精神就是 time boxing(編列固定預算的概念),任何活動都是有一定的時間,如果真的發生快到下班時間而 sprint planning meeting 還沒開完,那就「草草結束這次的 sprint planning meeting 吧。蛤,蝦米,草草結束,這是什麼態度?
 
沒錯,就是草草結束,因為如果把 sprint planning meeting 一直延長下去很可能會出現 big up-front design 的症狀。對於新的 Scrum 團隊,很可能團隊成員大多還是抱持著傳統那種「先好好地分析設計一番,然後再開工」的習慣。所以,如果真的無法在預定的時間開完會議,就草草結束,反正有問題 sprint 進行的過程中隨時都可以問 Product Owner。如此一來才可以:
 
  • 強迫 循循善誘團隊成員慢慢接受 time boxing 的工作模式。
  • 這次 sprint planning meeting 花太多時間討論一些可能不是很重要的細節,導致於最後落得草草結束的下場。團隊學得此次經驗之後,下一次的 sprint planning meeting 會儘量避免同樣的問題發生。

***

下一集:〈Scrum 是什麼(7):Daily Scrum

***
 
友藏內心獨白:難道每天寫一篇對於鄉民來說會看的太累嗎?

沒有留言:

張貼留言