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

August 30 14:15~16:40

 

這一集談的是FH團隊（Fault Handling）導入Kanban的過程。FH團隊處理的是軟體裡面的設計缺陷或是bug，在導入Kanban之前，原本這些維護的工作是交由開發團隊來負責。也就是說，開發團隊同時肩負著開發新需求以及修正軟體bug的工作。這造成了團隊必須要經常討論到底是開發新需求比較重要，還是修正bug比較重要的問題。有時候客戶回報了很多bug，為了忙著解決這些問題導致都沒有時間開發新需求，導致無法趕上原本規劃的開發時程。

為了讓採用Scrum的開發團隊可以專注於新功能，因此成立了新的FH團隊來處理軟體的bug。

***

Kanban實作

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

• 團隊運作：要能夠排除問題其實是需要武功高強的高手，因此公司讓原本的設計團隊自己決定哪些人要進入FH團隊。團隊大小維持在Scrum建議的6~8人（Teddy備註：5~9人應該也是可以），而且成員的知識與能力儘量要還蓋軟體系統的每一部分，這樣子才能處理問題啊。

在成立FH團隊之前，原本的開發團隊中是沒有專屬的驗證或是測試人員，因此問題解好之後需要丟給CSR團隊或是另外一個PT（Packet Testing）團隊來驗證。為了加速解決問題的速度，FH團隊增加了具備驗證能力的成員。也就是說，FH團隊是一個跨職能的團隊（cross-functional team）。

另外，開發團隊與FH團隊也是先講好，人員會在這兩個團隊輪流調動（原本就是同一批人，只是切個成兩個團隊）。這樣一來可以讓所有的開發人員更緊密的合作一起處理客戶所回報的問題。同樣的作法Teddy以前也建議過某個開發團隊採用，但是最後並沒有被對方接受，因為團隊成員不願意做出任何的改變。

FH團隊剛開始導入Kanban的時候舉辦了一整天的kick-off會議，包含了請PPO來說明待辦事項、舉辦Kanban訓練（這些人原本就在使用Scrum，所以不需像CSR團隊一樣先再安排兩天的Scrum訓練）、協調工作模式、以及定義DoD。

• Backlog：由FH PPO依據商業價值排定工作優先順序，FH PPO並且從客戶的觀點提議建議來協助FH團隊解決問題。FH PPO人數有好幾個，每一位負責一個版本的軟體，例如2.0版有一位FH PPO 、3.0版則是另一位FH PPO負責。但是因為所有的需求都要放在同一個Backlog裡面一起安排優先順序，所以FH PPO們要自己先協調好優先順序，到底哪一個版本的問題要先解，那些問題可以稍晚再處理。
• Kanban Board：下圖節錄自論文中FH團隊的Kanban Board，工作流程包含了Analysis&Fixing、Pending、Delivered to packaging、White verification、Map、Done。這個Kanban Board有三個狀態需要特別說明一下：
• Pending：如果有很緊急的事情需要立即處理，則PPO與團隊成員討論之後，團隊成員可以將手邊正在進行的工作移到Pending這個階段以便處理緊急的工作。
• White verification：驗證修正後的結果整合到系統之後是否有問題。
• Map：這個階段要做兩件事，forward mapping與backward mapping。前者確定軟體更新之後所有的修正都有被更新到，後者會產生一個新的TR，要求在舊的版本之中也要來修正這個問題。

 

• 限制WIP：只有Analysis&Fixing與Pending這兩個階段有設定WIP上限（上圖中的X）。根據作者的說法其餘的工作階段是交由其他團隊來負責，所以就沒限制WIP。
• 會議：舉辦daily meeting與每周一次walkthrough meeting。Retrospective meeting則是依需要不定期召開。由於FH團隊也是開發團隊的一員，因此也要參加開發團隊的Scrum of Scrum會議，還有一個作者沒提到目的，但顧名思義看起來可能是定義組織層面實務做法的Community of Practice（CoP）會議。
• 度量與觀察指標：
• 交期。
• Inflow與outflow。

***

改善與挑戰

作者提到了以下幾點改善：

• 團隊合作與自我管理（付於團隊權力並且讓團隊擔負起責任）。
• 用pull的工作模式取代push。
• 挑戰團隊成員的舒適區（comfort zone）。
• 提升FH團隊與CSR團隊之間的跨團隊的合作。
• 營造跨職能團隊。
• 深化持續改善的態度。
• 提高能見度。

 

以及挑戰：

• 需要處理許多不可預期的工作。
• 與另一個platform maintenance團隊的溝通是一個瓶頸，因為該團隊並未採用敏捷開發方式。
• 分散式開發。
• 團隊的建立需要很長的時間來培養。
• 工具並不支援團隊合作。
• 改變測試流程。
• 持續學習。

***

這一篇論文很詳細的說明兩種不同的維護團隊導入Kanban與敏捷開發的方法，寫完這兩篇部落格文章之後Teddy自己也覺得獲益不少。原本論文之中還有特別提到在另一個地點（論文中提到的Ericsson研發中心有兩個不同地點的辦公室）的FH團隊導入Kanban的作法，除了沒有強調組成跨職能團隊以外，其餘做法和第一個FH團隊大同小異，Teddy就沒有特別加以說明。

***

友藏內心獨白：範例，跟飯粒一樣，都要吃乾淨才行。