看板方法介紹（10）：產能分配

Sep. 01 16:30~15:42

 

在〈看板方法介紹（9）：工作類型〉中Teddy介紹了五種不同的工作類型，今天談一下如何應用這些工作類型，或稱為服務類別（class of services）來分配團隊的開發人力（產能）。

先談談Scrum的做法。在上Scrum課程的時候，Teddy遇過很多人問過類似的問題：「我的團隊同時要負責開發和維護舊系統的工作，在Sprint Planning Meeting的後要如何規劃？」從Scrum的角度來看，越重要、對客戶價值越高的工作，優先權越高。在此精神加上參考團隊的velocity，Teddy的經驗是Scrum團隊可以處理Fixed Delivery Date、Regular、Intangible、Defect類型的工作，至於Urgent的工作，如果可以延到下個sprint去做，就安排在下個sprint，如果不行，就只能「破戒」當作插件，放入這個sprint處理（Scrum基本上是不允許改變sprint backlog，所以不鼓勵臨時插件，只有在特殊情況下偶一為之）。

在看板方法中，因為有限制WIP，因此團隊可以依據總產能（所有工作流程階段的WIP相加）以及每一種分類工作出現的頻率或是重要性，來決定要各自分配多少產能。以上圖為例，總產能是15，團隊決定各分配20%的產能給Fixed Delivery Date、Intangible、Defect這三類，所以一共用掉60%產能，剩下的40產能分配給Regular工作。因此，Fixed Delivery Date、Intangible、Defect類型的工作可以各獲得3個WIP，Regular可以獲得6個WIP。至於Urgent，由於是緊急狀況，因此突發時可以突破WIP上限，所以沒有預留產能給它（鄉民們也可以預留產能給Urgent，這兩種做法都可以）。

***

依據產能分配工作的好處是，開發團隊和專案經理或是其他利害關係人，可以清楚的知道「產能（人力）」都用到哪裡去。假設一個團隊的產能大部分都用在Defect上面（不用懷疑，真的有這樣的團隊，而且還不少），那專案經理或高層主管就要留意這樣的現象。是不是累積了太多技術債，沒有分配適當的產能給Intangible來處理技術債？

團隊成員、專案經理或利害關係人共同來決定產能的分配，可讓團隊的資源利用透明化，有助於減少誤會協助工作安排。雖然大家都知道要飲食均衡，不可以偏食，但實際上有些人就是喜歡吃肉，有些人堅持吃素。軟體開發的工作類型，功能開發與技術增長、償還技術債，應該要取得平衡。透過kanban board來目視化管理產能，不失為一種簡單有效的方法。

最後提醒一點，上述介紹的方法，其實在Scrum也可以適用。Scrum團隊可以用story point來分配產能。假設團隊的平均velocity是29，在sprint planning meeting的時候，可以依據比例將固定的sprint point分配給user story、technical story或bug fix。Teddy在帶Scrum團隊的時候便嘗試過類似的作法，儘量在開發新功能、修正bug與技術精進、流程改善上取得平衡。

***

友藏內心獨白：生產線的術語越來越多了。