David Ko的學習之旅

上次在網路上看到一個例子(sorry, 我忘記出處), 來描述為什麼要用 WIP limit (Work in Progress), 想來跟大家分享:

Kanban 最主要的是看 flow 的流動是否順暢, 任何會影響 task 在工作流程上的移動, 都可能會是問題. 但是你要如何及早找出有問題的地方呢? 

你可以把這件事情想像成實體的河流流動, 你要如何觀察這個河流是否流動順暢? 是否有淤積? 在台灣常聽到的做法, 是在冬天水量較少的時候, 安排清淤泥的工程.  

為什麼會是選水少的時候呢? 因為水少的時候, 你就可以看到哪裡有淤積, 哪裡有垃圾, 或是哪裡有石堆, 接下來你就可以知道要怎麼處理. 怎樣把這些東西清理掉. 

所以同樣地, 在 Kanban 也是一樣, 利用 WIP limit 來降低水位, 來幫助你很快找出問題. 

以前 waterfall 的時程比較長, 一個 stage 接一個 stage, 也就是批次處理: 每個 stage 一次要處理大量的工作(水位很高), 因此不會很快讓這些問題跑出來. 

可是當你設定了 WIP limit 後, 因為限制了同時能處理工作數目, 每個 stage 只能處理一些工作, 因此在某個 stage 流動的不順利, 你就可以看到哪個地方有淤積, 也就是你的開發過程哪裡是有問題的. 像是測試工作會卡住, 需求分析會很慢, 後面找到一堆 bug 解不完, 無法快速 deploy等等這些問題, 都可以因而找出來. 所以這就是我們要設定 WIP 的原因, 就是希望能幫助團隊早點發現問題.

 

(嗯, 可是也是有那種看到淤積, 卻是一點都不想清的人. 所以有 WIP limit 只是第一步而已....)