August 27 13:50~15:40
昨天在《遊戲團隊結合Agile與Kanban的經驗》裡面Teddy引用了《Agile & Kanban In Coordination》這篇論文中的一張圖（如下圖所示），圖中用需求大小分類來決定需求要交給Iteration Team或是Kanban Team開發。
這種作法，讓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把它簡化之後如下圖所示。
把上圖分成五種不同的應用時機：
- 專注-創新：這種類型的專案可以採用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並且練好基本功是很重要的。
「大小不一個工作」 => 可能是錯字?
回覆刪除