作為一個半吊子項目經理，周旋在技術與業務團隊中是我的必修課。為技術團隊做好第一道門板是我的職責之一，這并不是說我不關心項目的進度、質量，而是實在業務團隊五花八門的需求太多了。隨之而來的問題自然也就常見又頭疼：響應時間（前置時間）長、初稿代碼質量差、每個程序員并行項目過多??技術與業務團隊當然都很不滿意。我們急需變革。

在這種情況下，我讀到了這本《看板方法》。

作者表示，這本書是圍繞著兩個問題來寫的：

1. 如何實現現在敏捷社區所稱的可持續步調（sustainable pace），保護團隊免受業務部門提出的無窮無盡的需求的困擾？

2. 如何克服其中不可避免的變革阻力，將敏捷方法成功推廣到整個企業內？

這兩個問題，正是我關心的。想必眾多與我一樣深陷在交付速率與需求過多問題中的項目經理也非常急于解決這兩個問題。

看板是什么？

Kanban，最早是豐田生產方式及其改善方法的支撐機制，能夠帶來持續改進。本書的作者，David J. Anderson，則是將Kanban帶入軟件工程的第一人。他于2004年在微軟實施了第一個虛擬的軟件工程看板系統。

看板系統（Kanban system）來自一系列稱為拉動系統的實踐方法。看板（Kanban）方法指的是自2006-2008年間在Corbis公司涌現的漸進增量式的過程改進方法學。

在軟件開發行業，看板起到權限授予者（permission giver）的作用，鼓勵團隊根據具體情境制訂過程解決方案，而不是教條式地遵循某種軟件開發生命周期過程定義或模板。

使用看板方法的好處？

1. 促成增量式的變革。

2. 降低變革中的政治風險。

3. 最小化變革過程中遭遇的阻力。

4. 發現改善的機會，而且其中不會涉及復雜的工程方法變更。

從哪些地方開始入手？

1. 減少在制品的數量，即減少進行中的工作項數量。這能增進與下游合作伙伴入運維部門等之間的信任。

2. 頻繁發布。這能增進與上游合作伙伴比如市場營銷部門等之間的信任。

3. 降低變異性。這將有利于實現資源平衡（并潛在地降低對人數的需求），且能減少看板令牌（Kanban tokens）、減少在制品數量，最終體現為平均前置時間下降。

4. 為了降低變異性而進行的改變，需要留有富裕時間。只有這樣，團隊成員才會有時間與精力對自己的工作成果進行反思和進步。

看板 VS. Scrum

公司也在嘗試推行Scrum，但毫無成效。冷眼觀察下個人感受是：Scrum對人的要求太高了。

首先，得有一個經驗豐富的Scrum Master，才可能從小范圍內對流程進行改變。

其次，得有最少一個精通業務&技術的產品負責人，才可能每周挑選出最符合業務部門經濟利益的用戶故事與Scrum團隊開展有趣的討論。

同時，整個Scrum團隊的水準需要相對平均，并有著強烈的責任心，才可能讓各種討論發揮應有的作用，才可能出現主動承擔任務的理想狀態。

而這樣的人，在國內大部分的公司里，是不太可能出現的。基于種種原因，即使是有這樣潛力或能力的人也未必愿意表現出來。

而看板，要求的是必須要抵制住改變工作流程、職位名稱、角色及其職責，以及當前在用的具體實踐的誘惑。不要試圖去改變團隊成員與其他合作伙伴、參與者、干系人的內驅力、專業自豪感和自我心理（ego），主要要改變的是在制品的數量、與上下游業務間的接口及交互方式。

讓技術團隊的成員，業務團隊的成員，各個利益相關的成員、團隊乃至公司都在無聲無息中漸進式變革，這就是看板的成功之道吧。