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

圖片來源：www.freepik.com

在上回【看板方法】課後心得 之三，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。

還在學校念書的時候，第一次接觸到《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》書中的 GRASP 方法時，總覺得怎麼這麼麻煩？我的直覺很快就可以畫出 design diagram 了，這方法真的有用嗎？那時課程的助教 Teddy 學長說了一句話：『傻的願意相信』，先相信這套方法是有用的，等到弄清楚整個方法後，變成自己的東西時，那時你就不覺得是礙手礙腳的，反而會變得自然而然地，也不會刻意在用什麼方法，但在這之前要先相信它，願意使用它，不然這東西永遠不會是你自己的東西，就這樣，後來像是 CI、Scrum、SLM (ALM) 等概念都是這樣建立起來的，kanban 也是如此，先別去懷疑，先照著方法試試看。

觀察

看板方法大概都會提到 CFD，但實際上以人工畫 CFD，超累的，一般還是要資訊系統輔助會比較方便，理想的 CFD 是平滑的，什麼！第一次在書上看到這個形容詞時，我完全不知道那是什麼意思，但在玩過一輪看板遊戲後，再回頭看組員紀錄的 CFD，和其他組記錄的 CFD，就比較有感覺，越平滑的 CFD 就是流程跑得越流暢，也更容易預測工作項目所需要的時間。理想的 CFD 會像這樣：

但實際的 CFD 都不太可能是上圖，實際 CFD 會比較像下圖的，若以垂直切割的角度看 CFD，可以看到每個狀態下的 WIP，由於每個狀態都會有 WIP 的限制，所以最多不會超過 WIP 限制，但可以看出哪個狀態的 WIP 低於限制，哪些滿載，如此就可以發現流程哪裡不太順。

若以水平切割的角度看 CFD，可以看到下面兩個數據：

• lead time = work item completed time - work item created time，簡單說就是工作項目整體花的時間
• cycle time = work item completed time - work item started time，是工作項目真正處理的時間

從 CFD 看到的不是各別工作項目的 lead/cycle time，是團隊的平均值，所以當 CFD 越平滑，就越能預測 lead/cycle time，當有一個新工作項目排入時，大概可以猜出幾天後能完成，當然，這兩個數值會動態浮動，預測就只是預測，對我來說，若狀態切割的恰當，更可以看到工作項目在每個狀態的平均時間， CFD 最有用的還是用來分析瓶頸與優化流程的好用工具。

Coach

關於 coach 這個問題，是我在課堂中問柯大哥的，過去在跑 scrum 時，會有位 scrum master，當團隊的牧羊犬 (團隊成員是羊)，除了保護羊不受干擾，也同時驅趕羊維持紀律，但在看板方法中，並沒有定義這樣的角色，所以需要嗎？其實還是需要的，若原本是 scrum team，看板方法只是用來優化流程，所以 scrum master 還是 scrum master，還記得『尊重當前的流程、角色、職責和頭銜』這原則嗎？但如果原本不是 scrum team，還是建議有個人扮演類似 coach 的角色，觀察上述的數字及圖表，協助團隊制訂與調整 WIP 上限。

要當好的 coach 其實並不容易，方法要不柔不剛，要讓團隊成員聽得懂，想得通，還要時時觀察是否走偏了，曾聽過一個說法：『 task 非得要估時數，是因為要給 scrum master 看』，我聽到時有點愣住，scrum master 什麼時候在意一個 task 要花多少時間了？task 的時數只是輔助團隊判斷是否能再拉更多的 story 進到 sprint backlog 中，實際上時數是多少，跟實際上差多少，擔任 scrum master 的我根本不在意，scrum master 觀察的是事情有沒有順利被消化完成，有沒有過度承諾，有沒有火力分散，有沒有過度保守，這些都是看整體的趨勢，而不是看各別 task 的時數，像這種就是一種可能走偏的信號，coach 可能要跟團隊再次溝通估時背後的精神。

自省與行動

如果是 scrum 搭配 kanban (或所謂的 scrumban)，一個 sprint 一次的自省會議是很好的時間點，讓團隊針對該 sprint 出現的瓶頸或問題進行修正行動方案的討論，並在下個 sprint 中執行，若不是 scrumban 也沒關係，有固定的週期或是團隊有默契當什麼警訊發生時，就會召開會議檢討並調整流程就可以，不然實務的第三點就永遠不會發生，只是在討論時，有了視覺化的流程加上 CFD 等圖表與數據，更能清楚地針對對的問題去討論，而不是團隊成員的感覺。

最後，目前還在讓團隊嘗試摸索 kanban 中，也希望團隊能運作得更順暢。