【看板方法】課後心得 之三

圖片來源：www.freepik.com

在上回【看板方法】課後心得 之二，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。

看板方法規定的東西很少，六個實務中，只有頭兩個是真正明確的要求，第三項則是根據問題去管理流程，沒有特定的方法，第一個視覺化流程，通常不太會遭遇到團隊的抗拒，但第二個設定 WIP 限制就不見得了，特別是『限制』這兩個字會讓人聯想到會不會影響到我平常的工作模式？但看板方法很明確地說，不能不設定 WIP 限制，設定 WIP 限制有幾個目的：凸顯瓶頸和避免多工。

凸顯瓶頸

前面提到，切割 task 常會以職能切割，這無可厚非，即使是一個工作項目用多個 check list 項目也是同樣的概念，只是當以 task 做為狀態搬移的單位時，常會出現一種可能：局部優化，什麼意思呢？假設測試資源比開發資源要少，那開發人員在開發完某個 story 中與他職能相符的 task 後，很直覺地就會將下個 story 送進開發中的狀態，然後繼續開發與本人職能相符的 task，這樣確實不會讓工程師閒置，開發的 task 也消化的很快，達成了局部最佳化，但 story 完成了嗎？若測試資源還是稀少，那通常都要等到很後面才會看到 story 完成，這和盡快交付的精神違背。

要如何盡快交付？最簡單的就是 stop starting, start finishing。已經進行到一半的工作項目，就是盡快讓它完成，而不是在開啟新的工作項目，但這跟設定 WIP 限制有什麼關係？假設，測試的 WIP 上限是 1 (這是以一個工作項目有多個測試的 check list item 為例，若是以 task 為單位可以設為實際測試人員的數量作為上限)，當有個工作項目停在測試階段，測試人員拼命側還是來不急測完，此時開發狀態的某工作項目已經完成，要送進下個狀態時就會因為違反 WIP 上限而無法送入，假設開發狀態的 WIP 上限還沒到，那開發人員可以再拉一個工作項目進到開發狀態，但如果也已經達到上限，就會發生卡住的情況。

這種卡住的情況是一種顯性瓶頸，和比較 task burn down 與 story burn down 曲線還更為明顯，由於已經卡住，所以團隊成員就必須想辦法解決問題，當然調高開發狀態的 WIP 上限是一種方法，但是一種笨方法，只是把問題往後延而已，事實上，看板方法就是強迫團隊去解決瓶頸，而不是視而不見，例如，開發人員可能不擅長寫自動化驗收測試腳本，但總可以幫忙手動驗收測試吧，或是就算寫得慢，還是可以停下新工作項目的開發工作，先幫測試人員寫自動化驗收測試腳本，戰鬥力雖弱也是一種資源啊！講義中有一個很有趣的比喻，工作項目是接力棒，團隊最重要的責任是讓接力棒不間斷地傳下去，直到終點，人有沒有閒置不是最重要的。

避免多工

課程中用翻銅板遊戲讓成員體驗多工不見得比較快，但我個人覺得翻銅板遊戲和平常軟體開發的多工其實不太一樣，於是能與現實工作產生的聯想就不明顯。自已的觀察，成員會常常多工，很大的原因是 task 切割得太細 (原因很多，就不在這細談)，但彼此又有強烈的關聯，導致這些 task 一起做反而效率比較好。

當 task 切得異常細時，例如：我曾看過一個 story 切成數十個 task，story 紙卡上的便利貼貼到滿出來，以避免多工的角度出發，WIP 限制會是以 task 為單位去設定，例如：開發狀態的 WIP 限制為：開發團隊人數乘上 1.5，假設開發團隊為 4 人，則開發狀態的 WIP 限制為 6 個 tasks，這時候要小心，由於測試人員一開始可能沒事可做，所以開發人員把開發的 task 領到滿，然後持續這個情況，等到有某些 task 完成時，開發人員要領 task 時，卻無法領，因為已到 WIP 上限。又或者，因為 task 彼此關聯，想一起做時也會因為 WIP 上限出現排擠別的團隊成員能領的 task 數量。這些都是明顯卡住的警示，要團隊自己注意到該如何團隊合作以達到整體最佳化而不是局部最佳化。

另外一個導致多工的原因是，目前正在進行的 task 遇到阻礙，例如：要等其他部門的答覆，因為不想空等，所以領了新的 task 來做，此時這個人身上就會有多個 task ，當原有的 task 又可以進行時，成員又要進行 context switch 回到先前的工作狀態，如前所述，這也是一種浪費要避免。這時候會建議用個特殊的東西，像是磁鐵或是紅色的小便利貼貼在受阻礙的 task 以明顯標示該 task 目前是阻礙的狀態，若因為受阻礙的 task 多到一定的程度，團隊成員會很快達到 WIP 上限，於是團隊就必須思考如何加快排除阻礙，而不是等著它自行排解。

如果以剛剛我提到的喜好，以 story 當作工作項目的形式，每個 story 盡可能小，也許只是一個操作流程中的一個畫面，或是一個步驟。然後，將測試的 WIP 設為一個 story，若有 story 進到測試狀態，會希望團隊盡快將它完成；分析與設計狀態的 WIP 設為二個 stories，可以完成二個 stories 放在完成的子狀態，作為緩衝，開發狀態的 WIP 也是二個 story，保留一些執行上的彈性，但不希望有人同時執行超過二個 tasks。

不過這些設計都要與團隊取得共識，調整亦是如此。

小結

以自己的經驗，WIP Limit 的設置通常反彈是比較大的，特別是團隊成員過去的習慣都是專注在自己擅長的項目時，當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成。下一回，將用一些自己的感想來完結整個系列。