在 Kanban 中, 第一件事情, 是要將工作流程視覺化, 也就是將工作流程畫出來. 每個步驟會變成一個欄位, 你的便利貼 (工作) 便會在這些欄位 (步驟) 中移動.
此外, Kanban 還會引進拉式系統觀念, 也就是生產是由需求驅動的. 當下游還沒有完成, 或是沒有需求時, 上游不能一直生產東西往下遊送. 為了實踐這樣的觀念, 你流程中的某些步驟, 可能會有兩個子步驟, 並且會有兩種表示方式:
1. ready/doing
1-1. ready: 在這個子步驟中, 有些工作正等待被處理, 這些工作是從上個步驟放入的
1-2. doning: 處理從上個子步驟中(1-1) 拿來的工作
範例:
分析 開發 測試 發佈
ready doing ready doing
2. doing/done
2-1 doing: 處理從上個步驟中拿來的工作
2-2. done: 當 2-1 子步驟的工作處理完後, 會放到這個子步驟中
範例:
分析 開發 測試 發佈
doing done doing done
那到底兩一個比較好呢?
這裡有幾個想法:
1. WIP 通常是針對個人來設定
分析 開發 測試 發佈
[ WIP = 3 ]
ready doing ready doing
在第一種方式, WIP limit 的設定會跨 "開發-doing” 到 "測試-ready” 兩個欄位, 因為能不能將工作移到那邊, 都是開發人員控制. 當開發人員發現 "測試-ready" 太多事情時, 他就不能拿東西到 "開發-doing”.
可是這樣的 WIP limit 寫起來就很奇怪, 因為會需要跨不同階段(開發和測試). 如果是第二種方式, WIP limit 的寫法就比較正常
分析 開發 測試 發佈
[ WIP = 3 ]
doing done doing done
因為開發人員發現 "開發-done” 堆太多東西時, 他自然就無法在 "開發-doing” 放工作來做. 這樣工作板上, WIP limit 寫起來比較不奇怪.
2. 做完的條件會設定在哪個步驟上
當要把某個項目移到下個步驟時, 我們會檢查是否是真的做完, 因此我們會對這個欄位, 設定一些 policy, 也就是做完的條件. 可是在第一種方式中, 沒一個欄位或是子欄位合適, 因為欄位名稱和做完搭不起來.
分析 開發 測試 發佈
ready doing ready doing
如果是在第二種方式, 很直覺地你會擺在 “done" 這個子欄位上面
分析 開發 測試 發佈
doing done doing done
另外還有一個問題, WIP limit 要設在哪個層次上, 這可以有兩種設定的方式:
設定方法 1
[ WIP = 3 ]
分析 開發 測試 發佈
doing done doing done
設定方法 2
分析 開發 測試 發佈
[ WIP=2 ][ WIP=1]
doing done doing done
那差別是什麼?
如果在設定方法 2 中, 發生以下狀況: 當 T3 被完成時, 那會發生什麼事情呢?
分析 開發 測試 發佈
[ WIP=2 ][ WIP=1]
doing done doing done
T2 T1
T3
T3 一定要移到 done, 但是會超過 done 的 WIP limit, 可是不移過去又和 doing 的定義不合. 這會變成很囧的狀況.
嗯, 這中間學問還真多 ….
資料來源:
http://blog.equinox.co.nz/blog/Lists/Posts/Post.aspx?ID=290
留言列表
