Stop starting, Stop Finishing
當Justin 發現有一大堆工作在看板上面, Justin 就詢問團隊成員, “你們同時可以處理多少工作?”
分析師: 我可以處理 3 個
開發人員: 沒問題, 我 5 個.
測試人員: 我只能做 2 個
他們各自把這些數字寫在直行最上面. 並且規定在每個直行內的工作個數, 不會超過上面所寫的數字. 藉由這樣來限制同時在進行的工作量.
|
backlog |
分析 (3) |
開發 (5) |
測試 (2) |
做完 |
|
|
|
|
|
|
他們同意團隊最多可以處理 10 個工作, 但是不代表團隊的處理能力只能做 10 個工作.此外他們也認為需要週期性的聚會, 來討論WIP limit 的影響, 並且依狀況作出調整.
WIP limit 限制開始沒多久, 就因為工作太多, 馬上就超過了 WIP limit的值. 所以討論了一下, 可以有兩種做法
1. 如果新的工作進來要先處理, 就把手頭上的工作停止, 然後擺回 backlog 那個直行
2. 停下手頭上的工作, 但是便利貼仍然停在原先的地方. 對於馬上要處理的工作, 則為它新增便利貼.
他們採用後者的方法. 這樣比較簡單, 並且可以反映現狀: 就是有這麼多事情要處理. 不過他們增加了一條 policy: 已經開始的工作要盡快完成, 否則不要再啟動新的工作. 他們把這個policy 寫在看板上方, 以提醒團隊成員要注意
這個policy 公布後, 團隊成員著重於盡可能先完成手頭上的事情, 而不是像以前一樣一直開始做新的事情, 可是手頭上的事情一直沒有告一個段落.
為了能讓事情盡快做完, 他們每天在站立會議時, 聚在看板面前, 從看板右邊的直行開始檢視到左邊的執行, 對於每張便利貼, 會討論要做甚麼才能讓這個工作早點做完.
漸漸地, Justin 的團隊能夠越快把事情做完, 至少比以前快了點. 他們認為是因為多工的狀況減少, 成員心理的負擔減低, 至少不會認為有一大堆事情要同時處理.
留言列表
