看板方法源自於豐田生產系統（Toyota Production System, TPS）、精實方法（LEAN）和約束理論（Theory of Constraints, TOC），由大衛．安德森（David J. Anderson）於其 2010 年的著作《看板方法：科技企業漸進變革成功之道》提出。（沒有繁中版）
Note
跟 1995 年出現的 Scrum 相比真的是很新。
跟它的兩個源頭理論相同，看板重視的是價值的流動。重點在於價值任務從計畫到交付給客戶的時間。藉由調整流程，來消除瓶頸或浪費，以降低價值流動的前置時間（lead time），同時提高生產量。
Note
跟所有敏捷方法相同，「客戶」指的不見得是字面上的「組織外的客戶」。
對看板的誤解
一般來說大家如果只是在網路上隨意瀏覽看板的概念，應該都會覺得大概是用來取代 Scrum 或 XP 之類的新方法，但其實層級不太一樣，看板不是另外一個方法論。
看板是一個元流程（metaprocess），意思是改善流程的流程。它需要當前已經有運行中的流程。所以它與 Scrum 不衝突，也可以拿來改善瀑布式流程，它甚至根本沒有是否要迭代的概念。
看板是一個漸進式的改革方法。它的設計初衷，是為了盡量減少改革的初始影響，從而減少改革的阻力。它透過將問題視覺化，然後讓團隊自發地逐步改進。所以如果你想要為了看板搞個「大刀闊斧」的改革，先不要！你應該還沒理解看板！
Note
其實就算是 Scrum，也沒有說它裡面的每個實踐都是必要的。每個團隊的業務流程和可用資源也都不同，本來也就會有不同適合的做法。
看板的三個原則：
- 工作視覺化
- 限制 WIP
- 管理流動
如果團隊沒有做到這三件事，就不叫看板方法。
Note
每本我看過的看板書籍都有明確說類似的話，大概是因為很多團隊只做了視覺化，然後就沒了。我懂，跟我使用記帳 APP 的方法差不多。（只記錄，不改進）
1. 工作視覺化
另外一種講法：暴露流程狀態，以幫助發現問題，而且要給所有人看到。雖然視覺化在敏捷已經很常見，提供了對各個工作項目的透明度，大家都知道誰在做什麼項目，什麼項目沒有人做。
不過看板需要更強調流程的透明度，即工作項目在流程裡的流動，如何從一個小組傳遞到另外一個小組。如果流動即將阻塞或受到影響，團隊能夠在流動停滯前就發現問題（例如 Buffer 數量不足）。
處理並行活動
有時候一個過程可能會同時存在兩個以上的開發活動同時存在，例如：UI 程式功能與美術製作。可以額外拆個分欄來可視化流動（或者極端一點把卡片撕成兩半，然後在最後拼起來）。
2. 限制 WIP
利特爾法則（Little's Law）
從這個法則得知，降低 WIP，可以縮短前置時間，讓產品的產出過程在一個短週期內完成，以保證軟體可以穩定、持續的保持在隨時可以釋出的狀況，這就是持續交付的效果。
WIP 太高，就會有大量工作停滯，前置時間長。執行敏捷時會發生傳統瀑布的感覺似乎是這樣來的。但 WIP 太低又會大量人員閒置，所以 WIP 限制數還是需要權衡。
Note
鼓-緩衝-繩（Drum-Buffer-Rope）
從約束理論的角度來說，Drum 代表瓶頸，Buffer 是各部分的存貨數量，也就是 WIP，Rope 瓶頸穩定前後流速的機制。
當瓶頸前的 Buffer 太少，代表瓶頸即將沒有工作可做，系統即將停滯。需要敲鑼打鼓來呼叫上游供貨，或者上游出現了問題。
當瓶頸前的 Buffer 太多，代表上游生產過剩，但因為瓶頸約束了系統流動，所以系統也不會因此變快，反而要支付存貨累積造成的額外成本。以 WIP 來說最常見的問題是上下文切換、品質下降與長回饋帶來的額外工作。
所以 WIP 限制是一種 Rope，透過瓶頸的負荷來控制整體流速。
停止生產線機制
透過限制 WIP，可以發現流動的瓶頸，或是突發狀況，並做到類似豐田生產方法的停止生產線（stop the line）機制。這個機制強迫讓團隊解決 WIP 卡住的問題，鼓勵整個工作流的成員協力處理任務目標，而不是獨善其身。
AI 時代
其實都 AI 時代了，以價值交付的穩定性來說，是直接 vibe 整個專案比較穩定，還是把整個專案拆分成數個明確的任務來分批 vibe 比較穩定？
或是用 SDD，問題就回到人身上了。是一次寫整個專案的 spec 比較穩定，還是把整個專案拆分成數個明確的任務 spec 並分批演進比較穩定？
AI 跟人類一樣，隨著使用的 context 變多，記憶與判斷出狀況的機率越高。較少的 WIP，可以降低思考顆粒度，讓事情簡單化，容易把程式品質提高，縮短前置時間，同時促成更頻繁的發佈。而頻繁且高品質的發佈可以提升與客戶之間的信任度。
最後，我們不再關注是否每個工人的工作都是最有效率的。改善流程以獲得快速流動，雖然可能會導致資源利用率的降低，但卻可以讓前置時間縮短。
3. 管理流動
流程總是能找到改進點，因為總是會存在某個瓶頸拖延你的工作。不過這些問題在白板上很容易顯現出來，而且往往越嚴重的問題越早暴露，一旦解決掉，工作的流動就會明顯改進。
當以這個原則進行工作時：
- 你能從精實思想中找到靈感來消除過程中的浪費，以便工作能夠順暢流動起來。
- 你也可以瀏覽一下約束理論，並嘗試識別、拓寬和緩解系統中的瓶頸。
- 其它敏捷實踐可以幫助你提升合作和品質，進而改善系統的流動。
到底選擇哪條路改進你的系統完全取決於你。最重要的一點是，當你的工作向你發出改進訊號時，你要回應並改善它。
跨越團隊
跟約束理論的狀況相同，在發掘改進機會的時候，你很快就會發現瓶頸在團隊外面，或是需要協調團隊外的非瓶頸輸入。為了獲得更快的流動，需要跨越當前團隊的工作範圍，你需要和其他團隊或者周圍的其他單位以不同的方式進行交互合作。
看板與敏捷的不同
每日立會
敏捷方法通常會有每日立會，團隊每個人輪流回答三個問題：
- 你昨天做了什麼？
- 你今天計劃做什麼？
- 是否有什麼困難阻礙你完成工作？
敏捷立會的常見問題是，因為論述的關注點在個人，除了工作阻礙比較容易發現之外，不太容易暴露流動的問題，例如：大家都說有工作項目在進行，也沒有被阻礙，但實際上流動開始停滯了。
看板方法不關注個人，只關注價值流動。所以每日立會討論的內容，是由專案經理或其他應當負責的人做為引導者，帶著大家檢視流程中所有的卡片。從最後往開頭看，檢視是否有卡片停滯或缺陷，檢視 buffer 數量是否正常 。
因為不用讓大家依序回答問題，這個機制讓每日立會更容易應用在更大的團隊上。2007 年 Corbis 公司成功主持了超過 50 人規模的立會。即使規模很大，但大約 10 分鐘就可以完成。
沒有明確規定 iteration
看板只強調改善流動，至於到底是 iteration 的流動，或是週期檢視的流動，還是傳統生產線的流動，根據團隊的需求決定。例如以維護專案為主的團隊，可能就會傾向於生產線的流法。沒有絕對是哪個比較好，但的確如果透過看板分析過後，iteration 明顯的沒有幫助到團隊，就可以捨棄掉。
停止啟動，聚焦完成
手上工作完成時，與其開展一個新的工作，大家可以幫助團隊中的其他人先完成已經開展的工作。
- 你能幫助完成進行中的工作嗎？完成它。
- 你不具有完成第 1 項的技能嗎？尋找瓶頸或其他減緩流動的事項，並幫助解決它們。
- 你不具有足夠技能解決瓶頸或移除阻礙事項嗎？拉入新工作，只要不超過 WIP 限制。
- 如果你還沒有工作可做，找一些有意思的並對團隊有用的事情，完成它。 例如：升級新的測試伺服器、清理部署環境中的資料庫、更新 API 的文件。這個大好機會也可以用於改進、發明或者學習新事物，以便日後能進行高效率工作。
這些只是經驗法則，但不該被當成守則使用。例如：考慮所處的環境，可能優先解決瓶頸比幫助其他人完成工作更合理。
Quote
沒有空閒就沒有改進。
—— Arne Roock