文章要點
文章主要分成
- 第一篇 Part I 是『讓李小龍你看見 Kanban 的美好』的統整和心得，參雜一些個人的解釋
- 第二篇 Part II 則是我嘗試使用學習到的kanban觀念，改進我的『個人看板』（尚未完成）
Kanban 簡介
如果你上網搜尋 Kanban 可能會出現，兩種最常見的解釋，其一是豐田生產模式的 kanban ，發明人為大野耐一，致力於工廠生產效率改善；其二為應用於軟體流程開發的 Kanban (Development)，此方法著名得提倡者 David J. Anderson，他是微軟導入 kanban 方法等敏捷方法的先驅，解救微軟績效不佳的支援部門，設法尋找一套方法讓部門問題自然浮現；早期著名著作有 Kanban: Successful Evolutionary Change for Your Technology Business。
學習小技巧
知道方法或工具誕生的情境、原因與動機，可以幫助你更容易掌或它的特性，幫助釐清方法背後的邏輯 （類似於你認識一個人原生家庭和成長過程，更能深刻的了解這一個人，以及解釋他的舉動背後的動機）
讓李小龍你看見 Kanban 的美好 Presentation Slide, David Ko [4] 幫我們整理好了，我就直接引用其內容輔助解釋！
採用 kanban 使用情境的基本原則
kanban『使用情境的基本原則』，包含：
解釋
- 由你現在做的開始：團隊必須已經有自己一套運作的流程，kanban適合在這種情境下導入，進而融合現有模式進行改善
- 以 漸進和演化 的方始改變：如同勸人不要想一步登天，組織運作變革要成功，通常是漸進式、一次一小部分，慢慢找出適合每個團隊的方式
- 尊重 目前的角色,責任和工作頭銜：如同上一點所提，漸進式的第一步，就是尊重目前有的現況
定義
我們回頭看看 wiki 頁面怎麼描述 kanban：
統整一下
kanban 的目標：
- 改進系統瓶頸
- 平衡需求和資源
藉由
- 視覺化流程，讓工作流程可以顯現在 kanban 上
- 輔助決策，知道如何調整團隊運作
kanban 的核心招式
我們引用 reference 的投影片[6]
其中五點都有英文的解釋，我就不贅述；聚會投影片有提到額外一點『實現反饋迴圈』，我想指的是當運行kanban一段時間後，不單只是找出瓶頸，更會對kanban機制加入客製化調整，例如：增加新增 column list 作為緩衝或有額外的狀態定義……等等
Kanban 和 李小龍哲學的相似之處
如同李小龍對武功的見解，可以由『Be Water My Friend』影片中的歌詞體現；相似的， Kanban 並__沒有固定形式__，一切__基於基本原則__，根據使用情境開始演化改善，找出最有效率的方式；此外 Kanban 除了__製造業__和__軟體開發團隊__，也可以廣泛使用在__測試團隊__、維運團隊、行銷部門、跨部門合作……等等；甚至是不同層級的應用場景，例如：個人看板（Personal Kanban)
如下圖：Kanban 明顯的功效，是用視覺化找出尋找瓶頸，設法顯現問題並團隊一起解決，反之，如果連問題在哪都不知道，難以修整改進；
如下圖，Kanban 上的 Task 流動情況必須是流暢，就如水的流動，就如同水流不順暢，找出淤塞處給予清除。
Kanban 演化範例
簡單kanban
下圖依照右上角次序從 1~4，從最簡單的 kanban 演化呈現優先順序的 Next Column ，挑選出要先作的事情；雖然目前 kanban 下圖2 可以呈現每個人工作狀態，但如圖4所說，目前還缺乏了一些東西。
團隊合作與更詳細的流程
下圖5 為加入各個 column list 加入 task 數目限制，同時以個人為單位分出 task 的河道 下圖6 轉而用 avatar 阿凡達(個人頭像)，比較親切；也希望團隊可以共同分擔任務，互相幫忙協助
下圖7,8 比起上圖6 有加註更詳細的流程，加入限制團隊WIP數目
Task Card 內容改善
下圖9 針對 task card 的內容加入更詳細的描述；下圖10則是加入急件/一般/重構不同急迫程度的通道，同時，也位 task 加入開始與結束時間等相關資訊
更大的流程視野
下圖11,12 擴大從需求到交付的範圍，可以綜觀整個產出的流程
系統化的改進方式
提及改進的方式，就得提到『目標：簡單有效的常識管理』這本書所提及的限制理論 Theory of constraint [7] 也可以參考 Ruddy Lee [8]的文章，也很簡易的說明
在 下圖a 中有詳細介紹：
- 辨識問題
- 善用限制（我自己認為理應翻譯成『妥善有效率使用受到限制的資源』）
- 順從限制（設法減少受限制資源的工作量）
- 鬆綁限制（最後才是增加受到限制的資源）
但通常慣老闆都是直接跳到 4. ，懶得花時間找出系統瓶頸的原因，只想要花錢多雇用人解決，但對解決問題不一定最有效率的方式。
下圖 b,c,d 是一個從 kanban 找出團隊測試部分為『限制』，設法以限制理論改進的案例，也可參考 David Ko 的舉例 [9]
真實情況的例子
下圖為分享中的實作案例，其中的問題都非常實際，都有可能出現在現實公司情境，具備參考價值。