昨天分享了 Kanban 最基本的樣子，今天來聊聊 Kanban 牆上的板子應該要能夠呈現哪些訊息？
這就要回到 TPS（Toyota Production System，豐田生產系統） 當中提到的七種浪費，Mary & Tom Poppendieck 將其對應到了軟體開發工作上。可參照 Ruddy 老師的《精實開發與看板方法》中有更完整的描述。
| 製造業 | 軟體開發 | |
| 1. | 庫存 | Partially Done Work |
| 2. | 額外過程 | Extra Processes |
| 3. | 生產過剩 | Extra Features |
| 4. | 運輸 | Task Switching |
| 5. | 等待 | Waiting |
| 6. | 移動 | Motion |
| 7. | 缺陷 | Defects |
我個人認為這很不侷限於軟體開發，各種團隊合作的情況，這些浪費的狀況都很常見，以下做一些我個人的白話解釋：
1. Partially Done Work
半成品，做一半的東西是沒有價值的。
2. Extra Processes
不必要的流程，我第一直覺想到就是莫名的簽核流程...。
3. Extra Features
多餘的功能。over design，這是工程師很常幹的事，追求自以為的完美，刻劃出一堆市場根本不需要的功能...。除了浪費開發時間，也增加系統複雜度，提高維護困難。
4. Task Switching
單人多工。在工作切換時，腦袋需要重新適應以取得相對應的資訊。太多的工作切換會降低效率。
5. Waiting
就等待...。這很常見，但我想要特別 highlight 的是很多團隊的 waiting 中的工作件數是一個相當具有指標性的資訊，但往往在看板上沒有顯現出來，有點可惜。例如說等待中的 task 一旦返回就會是急件的狀況，更應該關注現在有哪些 task 正在 waiting 狀態。
6. Motion
這邊指的不單單是人員的移動，更多的是工作中尋找相關資訊的時間。例如是不是有個團隊 wiki？共享資料夾？等等。
7. Defects
就 bug 啊～！！越晚發現，代價越大。
以上七種浪費只是一個參考，在 Kanban WIP 的限制下，1、2、4、5 應該都可以很直接的被視覺化並改善。而 7 也將因為 WIP 的限制而間接改善，例如之前一個 bug 從開始修復到完工，或許因為其他 task 阻塞，在 doing 狀態中停停走走過上幾週才修復，時間拖的越長，腦袋中遺失的資訊也越多，品質自然堪憂。限制 WIP 後，將集中火力疏通它，品質自然的就提高了。
當然除了以上七點浪費，依據個團隊的不同，有更多的關鍵資訊也應該視覺化的呈現。以下三個指標，可以用來檢視團隊看板的完整性：
1. 看板系統能全面地反映需求交付過程嗎？
2. 瓶頸和問題能在看板上得到即時呈現嗎？
3. 團隊可根據看板的資訊協作和做決定嗎？
以上三點摘錄至 David Ko 老師 - Kanban Board 設計是用好看版的第一步
