24. 設定第一次的WIP限制
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我們第一次正在處理的工作項目(WIP)限制是寬鬆的. 我們的理由是因為藉由視覺化的流程, 我們可以查看並體會到有什麼問題發生. 此外不可能一開始, 我們就能夠猜出最正確的限制. 隨著時間的推移, 每當我們發現好的理由時, 我們就可以調整WIP的限制值(我們要做的只是在白板上指明出來).
我們使用的第一個WIP限制是用2n-1(n=團隊成員的個數, -1則是鼓勵要做合作事宜的工作). 為什麼是這樣呢? 簡單地說, 我們沒有更好的主意. 並且這樣開始看起來也沒有爭議. 對於任何想把工作丟給團隊的人, 這個公式提供了一個簡單, 並且合乎邏輯的解釋: "...當我們考慮到每個團隊成員最多可以同時處理兩件工作: 一件正在處理, 一件在等待. 那為什麼你會期待他們能夠承擔更多呢?" 回過頭來看, 任何寬鬆的限制在一開始都會可行. 但藉由監控Kanban白板, 在沿路上可以很容易指出正確的限制為何.
圖4. 我們如何應用WIP到DBA和系統管理的團隊, 所有工作種類只有一種限制.
我們觀察到, 對故事點數定義WIP的限制是沒有用的, 因為這太難去追蹤. 唯一夠簡單去追蹤的作法, 就是單純地計算項目的個數(=同時執行的任務).
全站熱搜
留言列表
