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

閱讀時間約 5 分鐘
圖片來源:www.freepik.com

圖片來源: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 會像這樣:

raw-image

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

raw-image

若以水平切割的角度看 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 中,也希望團隊能運作得更順暢。

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
書摘《原來你才是絆腳石》
閱讀時間約 9 分鐘
【看板方法】課後心得 之一
閱讀時間約 4 分鐘
《鳳凰專案》讀後感
閱讀時間約 6 分鐘
【看板方法】課後心得 之二
閱讀時間約 8 分鐘
【看板方法】課後心得 之三
閱讀時間約 5 分鐘