May 29 11:52~13:41
前言
很多剛開始跑看板的鄉民都有一個疑問:「要如何設定每個工作階段的WIP?」今天介紹《Agile Project Management with Kanban》書中提到的方法。
***
準備工作
要決定如何設定WIP,以下資料需要先準備好:
- 視覺化工作流程,例如分析、開發、測試。
- 知道每個工作項目(work item)完成的平均時間,例如分析工作一周完成六個,開發工作一周完成兩個,測試工作一周完成三個。
- 每個工作階段有多少人負責,特別是瓶頸工作階段的人數(詳見下面說明)。
***
開始計算
有了以上資訊,就可以計算初始看板的WIP。參考下表,計算步驟如下:
分析 | 實作 | 測試 |
|
平均每人完成工作速度 | 6/week | 2/week | 3/week |
工作階段人數 | 3 | ||
產能 | 6/week | ||
WIP | 3 * 1.5 = 5 |
- 找出瓶頸,也就是速度最慢的工作階段,在這個例子中實作速度最慢。
- 算出瓶頸的產能:平均每人完成工作速度 * 工作階段人數,2 * 3 = 6,代表實作階段每周可完成6個工作項目。
- 將實作的WIP訂為:工作階段人數 * 1.5 (四捨五入),實作階段的開發人員有3人,3 * 1.5 = 5。乘上1.5的目的是讓每個人手邊有1.5件工作可以做,以免WIP太小任何一件工作卡住就必須等待。但也不會因為WIP太高導致context switch的浪費。這個技巧在《Kanban in Action》書中也有介紹。
- 其他工作階段配合瓶頸速度:由於屬於瓶頸的實作階段每周只可完成6件工作,因此分析只需要1人即可搭配實作階段的消耗工作速度。同理,而測試階段只需要兩人。
分析 | 實作 | 測試 | |
平均每人完成工作速度 | 6/week | 2/week | 3/week |
工作階段人數 | 1 | 3 | 2 |
產能 | 6/week | 6/week | 6/week |
WIP | 3 * 1.5 = 5 |
- 計算其他工作階段WIP:分析工作階段WIP = 1 * 1.5 = 2。測試階段WIP = 2 * 1.5 = 3。
分析 | 實作 | 測試 | |
平均每人完成工作速度 | 6/week | 2/week | 3/week |
工作階段人數 | 1 | 3 | 2 |
產能 | 6/week | 6/week | 6/week |
WIP | 2 | 3 * 1.5 = 5 | 3 |
***
人太多怎麼辦
剛剛的例子是由瓶頸階段的人數與平均每人完成工作的速度,回推其他工作階段需要多少人。但很多情況是團隊人數已經確定,例如分析、實作、測試各2人,請參考下表:
分析 | 實作 | 測試 | |
平均每人完成工作速度 | 6/week | 2/week | 3/week |
工作階段人數 | 2 | 2 | 2 |
產能 | 12/week | 4/week | 6/week |
WIP | 3 | 3 | 3 |
在這種情況下,因為一周完成12件分析工作但卻只能消化4件,因此分析階段的工作會累積在實作之前。而測試會沒有工作可做,導致人員閒置。
但是,幸好有WIP限制,分析工作不可能無限增加。如下圖所示,假設分析與實作階段已達WIP上限,此時分析人員便不可再從待辦事項中拉取工作來分析,只能停下來看看如何幫助工作流動得更順暢。
同理,測試階段可能沒有多餘的工作可以做,一樣需要思考如何幫助工作流動得更順暢。最直接的方式就是所謂的swarming,分析與測試階段的人到實作階段幫忙,提高實作階段,也就是瓶頸階段,的產能。
如果能夠從每個工作階段的產出可以互相匹配的角度來安排人力與設定WIP,會讓工作流動比較順暢。
當然,實務上平均每人完成工作速度的變異性可能很高,受到品質、施工人員的技能與身心靈狀態、工作項目大小、需求不確定性等因素影響,導致需要控制的因素很多,因而需要時時檢討人力、WIP的設置是否恰當,以及透過流程改善來讓工作流動更加順暢,降低交期(lead time)。
***
友藏內心獨白:小批量生產與消除變異性。
沒有留言:
張貼留言