圖片來源：www.freepik.com
在上一回【看板方法】課後心得 之一 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
要使用看板方法，要先進行看板的設計，雖然說看板方法四個原則的第一則：從既有的流程開始，但既有的流程卻有很多解釋的空間，例如，可能已經有 Scrum 經驗的團隊，很直覺地就以 scrum board 的 planned、in progress、done 作為既有流程，若以 task 為工作項目的單位來看，這當然沒問題，但一個 task 進到 done 時，能為產品帶來什麼價值？當然有價值，但若整體的 story 沒有完成，就無法出貨，就是一種浪費。因此，設計看板時，要以系統性的角度 (著重整體) 去想：(1) 範圍、(2) 工作項目的顆粒度、(3) 狀態。但重點是，要與團隊取得共識。
範圍
範圍決定看板的輸入與輸出。就軟體開發來說，最簡單的是需求作為輸入，實際可動的產品做為輸出。說是這麼簡單沒錯，但通常在考慮範圍時，會多考慮一件事：團隊是否能掌控。舉例來說，最近很紅的 DevOps，從開發、測試到部署以及營運，一條龍式 (最近這個詞好像變成貶意了) 整合在一起，那是不是能在設計看板時，就把部署放進去呢？那要看團隊是否在測試完成後，有權利決定立即部署，若可以，就適合放進去，若部屬需要層層的管理，或是有其他的流程決定，那就建議將部署另外獨立一個看板，不然，一堆工作項目放在 ready to deploy 的狀態也沒什麼意義。
同樣的，在考慮輸入時，也要考慮到是否能控制，或說得更清楚點，是需求的明確性有多高，一個客戶的 idea 在沒有進行任何討論或分析就放進來，那看板上在開發之前可能就要放一個分析的狀態，讓團隊有機會去討論與分析，但討論完若太大，可能又要切成若干個工作項目，此時，原始 idea 這個工作項目的角色就有點尷尬，要從看板上移除呢？還是保留呢？因此，一般建議是不適合放概念層級的工作項目到真正開發的看板中，也許可以有另一個看板用來進行分析與討論。狀態
工作項目的顆粒度與狀態會彼此相依，例如剛剛所提的，若一個 story 依前端、後端與測試分拆成不同的 task，那 planned、in progress 和 done也許就可以當作狀態，但不見得能看出瓶頸所在，這也是為什麼上課時，柯大哥問大家一句話：你想從流程中看出什麼問題？
問題因團隊而異，有可能是前端與後端的資源不匹配，也可能是開發與測試資源的不匹配，也可能是分析與開發的資源不匹配，之所以都用資源不匹配稱為問題，是因為大多數團隊成員還是有各自的專長，即便是 T 型人才，也還是有特別精的部分與較不熟的部分，因此一個工作項目不太會是一個人從頭做到完 (假設是工作項目不是依職能切割)，就會有交接的現象發生，當資源不匹配時，就不太可能很順地，一個人做完，馬上下一個人就接著做。
流程上的每個節點都需要消耗資源，沒有資源就只好等待，有資源完成後才會進到下個階段，因此看板方法想做的是用視覺化的方式去找出資源不匹配的地方，也就是瓶頸，然後才能解決問題，但解決問題不是靠看板方法，而是去調整流程、資源、開發方法，看板方法只是找出瓶頸，透過不斷地找出瓶頸，然後進行改變來優化流程。所以，在每個可能需要等待的狀態欄通常會建議再切成兩個子欄：進行中與完成 (作為緩衝)。好處是可以看到有哪些工作項目是處於『等待』的狀態，等待是我們試著要消除的浪費，若不凸顯出來，團隊就不會知道等待的狀況有多嚴重。
如果團隊的問題是開發與測試資源的不匹配，那可能較合適的狀態會是將『測試』這個狀態獨立出來，讓開發與測試在流程尚能被凸顯出來，相對地工作項目就不太合適是以前端、後端與測試的方式切割，而是一個可操作的項目，當前端與後端在開發時，工作項目進到『開發』的狀態，當開發完成後進到『測試』的狀態，因此可能的看板狀態會像下圖(但團隊可自行調整)：
另外，由於累積流程圖 (CFD) 能協助觀察流程的順暢度，合適的狀態也是讓 CFD 能顯示出更有用的資訊的一種方式。
工作項目的顆粒度
看板方法沒有限定工作項目的大小形式，所以可以沿用既有的工作項目，例如 ticket、story 和 task 都是可以的，但剛有提到工作項目的顆粒度和狀態的切法有關聯，其實也會跟流程跑得順不順會有關聯，工作項目大小不一，設定 WIP 限制有時會出現產能下降或是多出盈餘時間，理論上工作項目的顆粒度相近，流程就會跑得越流暢，但不可避免，不可能永遠都可以把工作項目切得很相近，所以 WIP 限制是一個實驗值，要隨著執行成果調整。
上完課後，我個人比較喜歡的工作項目形式是 story，在流程每個狀態之間移動的單位也是 story，但實際執行時還是會切成更細的 task，但 task 怎麼辦？就變成 story 卡片上的 check list，check list 也分狀態，例如設計狀態的 task、開發狀態的 task、及測試狀態的 task，每個狀態下的 task 都滿足了該狀態定義 DoD (等等會提到)才能稱作完成，等到該階段的所有 task 都完成了，才會將 story 移到下個狀態，所以一張 story 卡片看起來可能像這樣：
Definition of Done
其實還真的蠻多人搞混 definition of done (DoD) 和 acceptance criteria 的，至少上課時就有不少人搞混，簡單說，DoD 適用在所有工作項目上，可以根據狀態有不同的項目，也就是滿足了規定的 DoD 才能移到下個狀態，而 acceptance criteria 是針對特定工作項目所制定的，更簡單的說法是這個工作項目的規格，通過 acceptance criteria 才能跟客戶收錢。
會提到 DoD，是因為若看板空間夠的話，是可以將 DoD 直接條列在每個狀態的下方，例如，在分析與設計的狀態下可能的 DoD：
- UI 流程圖已經完成並和 PO 或客戶代表確認過
- 開發與測試的 tasks 已經切割完成
開發狀態下方可能的 DoD：
- 都有單元測試，model 的 class/method coverage 到 100%
- 程式碼至少由一個同儕 code review 過
- 程式碼已 commit 到版控系統
而測試狀態的下方可能的 DoD：
- 自動化測試腳本至少包含正常流程
- 無法自動化測試的部分都有手動執行一次以上
當然，隨著團隊成熟，DoD 是可以一直增加的。最後，加上 DoD 的看板會像這樣：
急件
能插入急件，應該是許多團隊或管理層喜歡採用看板方法的一個原因，但要先說一下，雖然原則上 scrum 建議盡量不要在 sprint 進行中插件或調整 user story，但若因為市場因素 (例如，目前進行中的 story 已經不再需要) 或其他緊急因素 (營運中的服務發生問題)，還是能將既有的 sprint baclog 做調整，注意，是做調整，不是僅僅把急件插入就好，sprint 週期就是固定這麼長，插件會排擠原有 story 的資源，所以就是用 story 換插件，插進急件就要把 story 移除 sprint backlog，不過有時候比較討厭的是，有些 story 已經進行到一半，要移除去就很討厭了，這即使是 scrum 加上 kanban 一起使用也是一樣的。
不論既有流程不是像 scrum 這種有固定時間周期的，在看板方法中讓將急件有獨立的渠道，而渠道上每個狀態的 WIP 限制都為 1，通常會避免設定很大，避免將所有的工作項目都設為急件，而濫用急件渠道。一但有急件，團隊就必須將該工作項目就當成急件，就像課堂中玩的看板遊戲中，講師偷偷提醒急件的定義，但有些組分配給該工作項目的資源甚至比普通件還少，有一組還因為有急件無法在指定時間內完成被扣 (遊戲中虛擬的) 錢，那就失去急件的意義了。
通常團隊要同時負責開發與營運的話，急件是需要的，因此，看板方法透過視覺化的方式，凸顯急件在每個階段是否都能順暢地被處理。加上急件後的看板會像這樣：
小結
到這邊，我們已經把工作視覺化，有了看板了，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，下一回就來看 WIP 限制的設置。
