l

2014年9月5日 星期五

看板方法介紹(10):產能分配

Sep. 01 16:30~15:42

螢幕截圖 2014-09-03 13.31.48

 

在〈看板方法介紹(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與技術精進、流程改善上取得平衡。

***

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

沒有留言:

張貼留言