2. 限制同時處理的項目數量
看板實施的第二步, 就是要限制同時處理的項目數量(WIP, Work in progress). 老闆以為你同時處理多件事情, 就能讓時程縮短, 但事實上多工並不能讓你較快.
例如: 有三件事情: A, B,C. 你分開單獨去做他們, 各自要花 10 分鐘. 因此你需要 30 分鐘完成
A (10 分鐘 ) + B (10 分鐘 ) + C (10 分鐘 ) = 30 分鐘.
平均每件事情 (10 + 20 + 30) / 3 = 20 分鐘完成.
註: A 在第 10 分鐘完成, B 在第 20 分鐘完成, C 在第 30 分鐘完成.
可是如果同時去做三件事情, 其實, 應該說沒所謂同時, 你只是先做 A 一下, 然後再做 B 一下, 接著再做 C 一下, 就這樣一直循環處理.
例如: 我們把每件事情分成兩個階段做完
A1 (5 分鐘) + B1 (5 分鐘) + C1 (5 分鐘) + A2 (5 分鐘) + B2 (5 分鐘) + C2 (5 分鐘) = 30 分鐘
平均每件事情 (20 + 25 + 30) / 3 = 25 分鐘完成.
註: A 在第 20 分鐘完成, B 在第 25 分鐘完成, C 在第 30 分鐘完成.
也就是說雖然總完成時間看起來一樣, 但是其實他們是在比較後面時間才被完成.
此外, 如果你還加上 context switch 的代價, 那可能會花更長的時間才完成.
在提到 WIP, 通常會提到 Little’s Law, 在這個公式中, 描述了為什麼 WIP 高, 會造成工作時間變長, 有興趣的人大家可以自己去瞧瞧. 今天要跟大家介紹一些不一樣的東西: 束水攻沙.
西漢末賈讓上治河三策, 認為上策是讓河流改道, 中策是分流河水, 下策是築高堤防. 後來朝廷選擇了他的下策. 東漢王景主持修築沿河大堤, 固定河道, 同時對局部河道進行改造, 使水流更通暢, 其成效很顯著.
不過由於後世黃河河口段日漸淤高, 泄水不暢, 單純修築堤防已經無能為力. 明代潘季馴遂改變思路, 採取"築堤束水, 以水攻沙"之法: 以堤防束緊河水, 增加流速, 提高河流挾沙能力.
同理在軟體開發上面, 因為 legacy system 或是技術債的關係, 導致於專案要交付新的故事速度緩慢, 單純增加人力也無法加快腳步.
因此, Kanban 改變思路, 採取每次不要做太多東西, 讓你在這過程中, 很快能發現本身做事方法中有哪些問題, 進而把問題解決, 使得你的開發速度慢慢變快, 整個做事流程漸漸變順暢.
到這裡, 大家對於為什麼要限制 WIP 的理由, 應該有所了解了吧!!
至於要如何設定 WIP 呢? 我想大家可以問自己這幾個問題:
(1) 是否能減少整個系統 WIP 的數目
我們期待同時不要處理太多事情, 並且不要只是局部最佳化, 希望能夠考量整體的優化. 例如: 不能只看開發部分的 WIP, 然後測試那邊卻很多工作要處理, 這樣其實只是開發工作做完, 但是還是沒交給客戶, 也就是沒有交付價值, 這樣對客戶來說還是沒有用的.
(2) 是否能讓問題及時暴露
是否設定 WIP 之後, 能讓專案的問題能盡快被顯示出來. 例如: 有時候團隊不會把 bug 資訊放在 kanban 上面, 因此無法讓品質不好這件事情呈現出來, 也會讓上面的人誤會天下太平.
(3) 是否能激發團隊協同合作解決問題
事情遇到困難時, WIP 的機制能不能讓團隊成員互相幫忙. 例如: 有些團隊的 WIP 是限制在每個人最多只能做一件事情, 所以有人遇到困難時, 別人是不會來幫忙的, 如果他的事情可以一直繼續做下去. 如果你的 WIP 條件是設成團隊成員 - 1, 這時候先天有件事情可能就是兩個人互相合作, 這時候對於某些困難的階段, 或者是比較資淺的團隊, 這樣的設定就幫助很大.
所以 WIP 在設定時, 不是套公式, 而是根據你的環境, 思考如何回答上面三個問題, 進而訂出你 WIP 的規則.
參考資料: 2015 AHA conference, 精益產品開發實踐分享, 張震, 何勉
全站熱搜
留言列表
