l

2013年8月28日 星期三

Scrum 與 Kanban應用環境

August 27 13:50~15:40

image

 

昨天在《遊戲團隊結合Agile與Kanban的經驗》裡面Teddy引用了《Agile & Kanban In Coordination》這篇論文中的一張圖(如下圖所示),圖中用需求大小分類來決定需求要交給Iteration Team或是Kanban Team開發。

image

這種作法,讓Iteration Team與Kanban Team的工作輸入(需求)大小差異性不至於太大,這一點對於Iteration Team與Kanban Team來說都很重要。

  • Iteration Team:如果Iteration Team在每個sprint裡面需要處理的工作包含很大的story以及許多很小的story或是bug fix的工作,非常有可能發生有些開發人員忙著處理大型的story,而有些開發人員只處理小的工作。依據Teddy的親身經驗,這麼做可能會導致開發人員依據自己的「喜好」來決定施工的順序,而不是依據PO排定story優先順序來施工。有些人偏好處理小型且定義清楚的工作(比較沒挑戰性),或是處理一些需要花時間但不一定需要花腦筋且比較簡單的bug。長期以往,不利於團隊的知識交流與合作。此外,在sprint進行中如果發生突發狀況,臨時要處理一些緊急但是比較瑣碎或是小型的工作,例如解bug,如果要緊急插入到已經排定的工作項目之中,也是會打亂Iteration Team的開發步調(嚴格來講,以標準的Scrum團隊而言,sprint進行中最好不要安插新的工作)。
  • Kanban Team:工作大小不一對於Kanban Team可能造成更大的問題。由於Kanban Team沒有iteration的限制,所有的工作只測量lead time(交期,或稱為cycle time)。大小不一個工作,會讓Kanban Team的平均交期變得沒有意義,也很難觀察出團隊的進度或是生產力。

***

因材施教

鄉民們應該知道,軟體開發沒有銀子彈、萬靈丹這種東西,不同的專案屬性與團隊組成,需要不同的開發方式來配合。Michael Sahota寫了一篇名為《A model for understanding Scrum and Kanban》的文章,提到Scrum與Kanban的應用時機。文中有一張圖以「重複 VS. 創新」與「專注 VS. 中斷」的角度來探討Scrum與Kanban的使用時間,Teddy把它簡化之後如下圖所示。

螢幕快照 2013-08-27 下午1.57.36

 

把上圖分成五種不同的應用時機:

  • 專注-創新:這種類型的專案可以採用Scrum方法,包含產品開發、研究團隊等工作內容需要創新或是創作思維,也需要專注的時間來進行專案開發。因此套用iteration的步驟(固定的需求規劃、每日會議、成果檢視、自省會議)可以協助團隊在維持專注與創新的同時,也顧慮到是否持續交付對客戶有價值的需求。
  • 專注-重複:這種類似的專案最著名的例子就是遊戲開發專案執行到「production phase(量產階段)」。取名為Production Line Kanban,就是說這種專案開發需要專注的時間,但是處理的問題屬於比較重複性的工作。用生產線作為比方,生產線上的操作員,相對來說不太較需要創新與動太多腦筋。關於遊戲開發專案的不同開發階段,請參考《Scrum框架下的跨界開發(3):遊戲開發的四個階段》這一篇。
  • 中斷-創新:這種類型的專案,可以混用Scrum與Kanban。例子包括《遊戲團隊結合Agile與Kanban的經驗》這一篇所提到的做法,用Iteration Team(Scrum Team)來應付專注與創新的工作,用Kanban Team來處理「中斷、事件驅動、多樣化」的工作。《系統管理團隊結合Kanban與Scrum的經驗》則是提到另一種混用Scrum與Kanban的做法,這種作法為了應付大量「中斷、事件驅動、多樣化」的工作而拿掉了iteration,改用Kanban,但維持了許多Scrum所建議的會議以及Product Owner和ScrumMaster角色。
  • 中斷-重複:這種類型的專案稱作Support Kanban,顧名思義就是適合用在扮演支援角色的專案。例如,客服中心的運作,或是公司內部的資訊系統,上線之後都需要一個團隊來維持系統正常運作。這種支援型的專案,工作被中斷的比例更高,工作內容的重複性也比較高。
  • 中間點:Michael Sahota把標準Kanban畫在中間這一個區域,也就是說專注、中斷、重複、創新這四個面向,都牽涉到一點點的這種專案,可以使用Kanban。這個,有點不好解釋,廣義的來說,就是什麼專案都可以用Kanban挑眉質疑

***

Lean Startup適合哪一種

最後一個問題,Lean Startup適合哪一種開發方式?會問這個問題,因為Teddy有個朋友原本正在嘗試導入Scrum,試了1、2個sprint之後,可能是讀了《Kanban and Scrum - making the most of both》與《The Lean Startup》這兩本書,朋友後來覺得拿掉iteration的Kanban比Scrum更適合Lean Startup。不過,後來Teddy私底下問他:「你們真的改用Kanban嗎?」得到的回應是:「沒有,其實是混用Scrum與Kanban的一些作法」。

如果從「重複 VS. 創新」與「專注 VS. 中斷」來做為選擇開發方式的依據,就比較容易理解朋友的處境與選擇依據。畢竟Lean Startup,或是廣義的來說,Startup(新創公司),所面臨的問題或是工作並非全部都動態到非得把iteration拿掉才行。就算是把iteration拿掉,許多Kanban團隊其實也混用了很多敏捷實務作法,不僅僅只是標準Kanban所要求的「視覺化工作流程」、「限制WIP」、與「測量及最佳化Lead Time」這三點而已。

***

友藏內心獨白:弄清楚context並且練好基本功是很重要的。

1 則留言: