Kanban在電信業產品維護團隊的經驗（上）

August 30 09:40~12:50

 

繼《系統管理團隊結合Kanban與Scrum的經驗》、《遊戲團隊結合Agile與Kanban的經驗》、《從Scrum到Scrumban的經驗》這三篇介紹Agile與Kanban的論文之後，今天要介紹一篇發表在2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications研討會的論文，名為：《Kanban Implementation in a Telecom Product Maintenance》。

這篇論文雖然只有九頁，但文中介紹了兩種不同類型維護團隊運用Kanban的方法，內容挺豐富的，所以分成上、下兩集來介紹。

***

背景說明

這篇論文描述Ericsson研發中心運用Kanban的經驗，這個中心在兩個不同的地點（分散式開發）開發一個複雜的行動網路產品。這個產品目前已經很成熟了。在這兩個不同的地點除了研發團隊以外，也有另外也有兩個不同的維護團隊，分別負責處理「客戶支援要求」（Customer Support Request，CSR）與軟體錯誤（Trouble Report，TR）。

Ericsson研發中心已經有使用Scrum的經驗，他們知道維護團隊必須經常處理很多不預期的工作，因此Scrum的sprint--固定時間長度的開發周期--不太合適應用在維護團隊身上。因此他們決定讓CSR維護團隊與TR維護團隊採用Kanban，但會將以前Scrum好的做法和Kanban結合（Teddy內心獨白：已經看到好幾的例子都是採用類似的模式來導入Kanban）。

在上集中Teddy將介紹論文裡面提到的CSR團隊導入Kanban的做法，處理TR的FH（Fault Handling）團隊導入Knaban的作法將在下集介紹。

***

導入策略

團隊結合了Scrum、Kanban、Lean的方法：

• Scrum
• 舉辦daily meeting。
• 舉辦retrospective meeting。
• 讓團隊成員參加兩天的Scrum訓練課程。
• 為了提倡團隊合作，重新安排辦公室空間，把牆給拆了，讓團隊可以坐在一起。無論是導入哪一種敏捷或是精實開發方法，讓團隊坐在一起（廣義的說應該是工作空間的安排）是非常、非常重要的前置條件但卻經常被忽略。Teddy的個人的經驗，在台灣要求修改辦公空間配置以便讓團隊能夠坐在一起並且有足夠的工作空間，是一件非常困難的任務。
• 將工作放在backlog裡面。
• 用一個「Proxy Product Owner（PPO）」代替原本Scrum裡面的Product Owner角色。
• 用Team Coach這個名稱取代Scrum Master。
• Kanban
• 視覺化工作流程。
• 限制WIP（Work In Progress）。
• 測量並最佳化交期（Lead Time/Cycle Time）。
• Lean
• 參考《Lean Software Development》這本書中的做法，作者特別提到了消除浪費這一點。關於透過消除浪費來改善開發流程Teddy在2010年10月在部落格上曾經介紹過六種消除浪費的方法，請參考《消除浪費 (1)：Partially Done Work》、《消除浪費 (2)：Extra Features》、《消除浪費 (3)：Relearning》、《消除浪費 (4)：Handoffs》、《消除浪費 (5)：Task Switching》、《消除浪費 (6)：Delays》。在《笑談軟體工程：敏捷開發法的逆襲》這本書的「Part 3 精實生產，減少不必要的浪費」中，Teddy也完整地介紹這七種浪費以及消除這些浪費的方法，有興趣的鄉民們可以參考一下。

寫到這邊突然覺得這個團隊的作法很像Scrumban，而不是Kanban。不管了，反正知道內涵就好，而且將這一堆Agile與Lean方法混在一起使用本來就是很正常的一件事，請安心服用。

***

Kanban實作

作者從以下幾個面向來探討導入Kanban的作法：

• 團隊運作：作者提一點關於團隊運作的挑戰，維護團隊的成員有時候需要出差到現場去處理問題，而且這種出差的決定都是很突然的通知。又或者是有時候會插入非常緊急的工作，團隊成員便需要放下手中的工作去處理這個急件。由於CSR團隊非常強調「團隊合作」的精神，因此成員們會互相幫助來解決這些計畫之外的突發狀況。
• CSR Backlog：由PPO排定工作優先順序，使用不同顏色的便利貼代表不同嚴重等級的工作。下圖是節錄自論文中的CSR團隊Kanban Board畫面，最左邊的Backlog欄位的上方特別隔了一塊urgent區域，用來存放需要立即處裡的緊急工作。綠色的便利貼表示非CSR（不是客戶提出的工作要求），但是CSR團隊成員需要處理的工作。這些綠色的工作也會放到Backlog裡面和CSR工作項目一起安排優先順序。

 

• Kanban Board：如上圖所示，工作流程切成Ongoing與Waiting for這兩大塊，前者再細分為Analysis、Request for more information、Fault reproduction、Solution ongoing，後者包含了Fault Handling、Platform、Customer。最後一個工作流程則是Done，表示客戶的問題已經被回復且公司資料庫的紀錄也被更新了。這個Kanban Board有兩點比較特別一提：
• 最下方有一列External，用來表示該工作由CSR團隊以外的人所處理。
• 將工作流程切分為Ongoing與Waiting for這兩大塊的原因，是因為當CSR團隊針對問題找出解決方案之後，這個解決方案還需要外部團隊的配合並且要經過客戶驗證通過。牽扯到外部團隊與客戶的工作流程無法控制，所以把它歸類成Waiting for。屬於Waiting for的三個流程階段都沒有設定WIP上限。
• 限制WIP：Ongoing的每個工作階段都有設定WIP上限（上圖中的X）。External這一欄則是沒有設定WIP上限，因為是使用外部人員的資源，而且這些人的人數多少也不一定，所以就沒限制WIP。
• 會議：因為禮拜二、五有一個CSR walkthrough meeting，所以每個禮拜只開三次daily meeting。Retrospective meeting則是約每兩周開一次。另外還有一個沒提到多久開一次的escalation phone meeting，這是在導入Kanban之前就已經存在的會議，參加的人有管理階層的人、PPO、CSR團隊代表。
• 度量與觀察指標：
• 工作等待的時間（queue time）。
• 交期。
• 超過期限的工作百分比。
• Inflow與outflow。
• Kanban board上面每一個column的工作數量百分比。

***

寫到這邊有一個感觸，曾經有人提出Kanban的好處之一就是可以不必像Scrum一樣組織跨職能與通才的團隊。從下圖來看，Production Line Kanban的確是很適合專才團隊，Support Kanban則比較偏向中間一點點，不過對於通才的要求沒有Scrum那麼高。

這篇論文應用Kanban的情況應該算是Support Kanban，但是卻又結合了Scrum與Kanban。團隊的互相合作與通才能力，對於認領工作與處理突發情況，還是非常有幫助的，這一點也許可以作為一個努力的目標。

***

友藏內心獨白：多看一些例子還是很有幫助的。