l

2013年8月27日 星期二

遊戲團隊結合Agile與Kanban的經驗

August 26 21:34~23:00

螢幕快照 2013-08-26 下午11.17.20

 

前一陣子讀了一堆有關精實開發、Kanban、Scrumban、Scrum+Kanban的書籍、網路文章和論文,幾天前介紹了《系統管理團隊結合Kanban與Scrum的經驗》,不知道鄉民們讀了之後有何感覺?Teddy自己是覺得蠻有趣的,今天繼續介紹另外一篇發表於2011 Agile Conference的論文:《Agile & Kanban In Coordination》。

這篇論文描述了一個18人遊戲團隊導入敏捷開發的經驗。這個團隊,和很多開發團隊一樣,同時肩負著「開發新功能」與「修改小功能及解bug」這兩種不同類型的工作。他們導入Agile與Kanban的過程,可以分成三個階段:

  1. 敏捷階段(10/1/2009~1/1/2010):作者在文章中並沒有說他們使用的是Scrum方法,但是根據Teddy的理解基本上作者所使用的敏捷方法是參考Scrum而修正的一種方法。這個階段主要的做法有:
    • 將18人分成三個團隊開發同一個產品,團隊人數分別為5人、6人、7人。
    • 估算task
    • 採用iteration
    • 有統計velocity
    • 有PO也有建立product backlog
  2. 敏捷團隊組建(1/1/2010~6/1/2010):在第一階段的嘗試中,作者提到PO經常遇到「不知怎麼把工作分給哪一個團隊比較合適」的這個問題。經過一番嘗試之後,最後他們決定既然三個團隊都共同開發一個產品,那麼乾脆就合併成一個團隊算了,引此導致了第二階段:
    • 將三個團隊合併成一個18人的敏捷團隊。
    • 非正式的組成一個Product Owner團隊。
    • 開始團隊的story planning會議。
    • 使用Scrum的User Story與Task。
  3. Kanban與敏捷團隊組建(6/1/2010~4/1/2011):第二階段的作法,明眼人一看就知道存在團隊人數太多的問題。Scrum建議一個團隊人數最好介於5~9人,18人的團隊真的是太大了。作者在文章中提到,有3~5個人表現得不好,經常無法完成他們所認領的工作,但這些問題卻因為人數太多而被隱藏起來。人數過多也會導致「自我管理」變得十分困難。最後,第三階段的嘗試:
    • 把團隊分成9人的Iteration Team與6人的Kanban Team。
    • Iteration Team負責較大的需求開發,Kanban Team負責小型且較明確的工作。
    • 正式組成一個Product Owner團隊。

***

敏捷與精實

下圖節錄自論文中的內容,作者提到他們的敏捷團隊與Kanban團隊所採用的敏捷與精實作法。基本上Kanban團隊沿用敏捷團隊的大部分做法,只是把固定開發周期與burndown chart拿掉。另外,用Kanban board來取代Story Board。

螢幕快照 2013-08-26 下午10.58.58

 

最後,用一張論文中非常有意思的圖來做為總結。Teddy在剛開始的時候有提到,作者的團隊和很多開發團隊一樣,同時肩負著「開發新功能」與「修改小功能及解bug」這兩種不同類型的工作。最後他們將團隊分成Iteration Team與Kanban Team,剛好用來對付大型工作(開發新功能)與小型工作(修改小功能與解bug)。

螢幕快照 2013-08-26 下午11.03.06

***

結論就是,除了「混在一起做撒尿牛丸」這種選項以外,還可以做成「撒尿蝦與牛丸雙拼挑眉質疑

***

友藏內心獨白:難道做軟體的人也要去學做菜的方法嗎!

沒有留言:

張貼留言