What's Kanban

Kanban，源自日語“看板”（冷知識：Kanban 和漢語拼音一致），是由日本豐田公司的工程師大野大一于 1940 年發(fā)明的一套及時管理模式（Just In Time， JIT）。JIT 的核心理念是：

讓正確的物資，在正確的時間，流動到正確的地方，數量是剛剛好的數量

Toyota

在敏捷軟件開發(fā)流行后，工程管理人員也將 Kanban 引入到了軟件開發(fā)當中，成為了與 Scrum 比肩的一套通用實現模式。雖然現代版 Kanban 比當年豐田幾只木架、幾張貼紙豐富得多，但是主要功能還是還是這么幾點：

• 可視化工作
• 限制進行中的工作（WIP）
• 最大化工作效率或流程
• 持續(xù)改善團隊秩序

Basic

Kanban 的基本組成其實非常簡單：一塊看板，一個泳道圖和幾張貼紙：

Kanban Basic

• Kanban Board:

  豐田用的看板非常簡陋，現代的開發(fā)團隊通常會使用，例如trello，這種更專門的看板工具。上面提到過，看板的主要功能是可視化一個項目或是工作流。它能直觀地展示任務項，使團隊成員隨時查看每個任務的狀態(tài)。

• Kanban List or Lane

  泳道圖的每一列表示項目進程的不同階段；每一個泳道上會貼一些卡片，代表該階段正在處理的任務。我們可以將整塊看板抽象為管道，每個泳道就是管道內先后執(zhí)行的處理器，卡片從左往后通過管道后，完成產品交付；交付花費的時間我們稱為 Cycle time，是 Kanban 的一個重要指標。

  Pipeline & Processors

  各泳道通常使用 To-Do、Doing、Done 這類能明確表達流程先后順序的標簽，以幫助我們直觀地發(fā)現各個階段的瓶頸。我曾看到過有些團隊的看板泳道是“高”、“中”、“低”這種優(yōu)先級標簽，這個一般用作 planning 階段的任務池（backlog），常于 Kanban 結合使用。

• Kanban Card

  每張卡片代表的是一個任務項，它一般包括受托人、截止時間、優(yōu)先級、分類、狀態(tài)等等 tag，現代開發(fā)工具一般都可以對這些 tag 進行篩選和查詢。開發(fā)團隊通過對卡片進度的追蹤，可以了解到該任務的生命周期。

  這里再廢話幾句，Kanban 在上世紀四十年代被發(fā)明出來的時候，確實是工業(yè)界的一次“認知升級”，簡單高效，影響深遠。但是都這么多年了，其實也沒太多神秘光環(huán)了，大家別再過分挖掘一塊板或是一張紙有什么內在的深刻的含義了。

• Work in progress（WIP） Limits

  Kanban 還有個核心概念叫做 WIP 限制，主要用來指定各階段的最大負荷。限制 WIP 可以幫助領導干部更快地識別出工作流程中效率最低的那個階段，也就是交付管道中的瓶頸；盡早發(fā)現瓶頸能有效防止過度生產，并及時投入資源去解決最急切的問題。
  WIP 限制是 Kanban 有別于其他敏捷開發(fā)模式的最大特色。通俗來說，Kanban 關注的其實是吞吐量：通過一定的資源調動來改善吞吐量，從而提升生產效率；而不是依賴 deadline 來提升效率。

  Bottleneck

Kanban vs. Scrum

OK，上文提到了另一種敏捷軟件開發(fā)模式 Scrum，它也常常給我們呈現一幅貼紙卡片板的形象。那 Scrum 和 Kanban 有什么區(qū)別呢？

Role

角色分配是它們倆最直觀的區(qū)別。Scrum 有三個最基本的角色扮演：

• Product Owner：產品負責人，主要職責是分析用戶需求，并將這些需求分解為各個子任務。他是各個任務優(yōu)先級的制定者，以及最終發(fā)布產品的決策者
• Scrum Master：Scrum 管理的執(zhí)行者，俗稱“監(jiān)工”，負責人力和資源的調配，指導和監(jiān)督 Scrum 開發(fā)流程的執(zhí)行和落實
• Team Members：就是具體干活的人，敏捷軟件開發(fā)比較強調主觀能動性，所以需要 member 們主動攬活，還能互相扶持

相比之下，Kanban 更簡潔，沒有強制的角色分配，要求每個團隊成員自發(fā)地履行執(zhí)行和監(jiān)督的職能。當然，現實中保證會有一個領導干部的啦，不過存在感稍弱于 Scrum，還常常親自參與干活。

Workflow

工作流程上也有很大的區(qū)別，Scrum 是基于迭代周期（Sprint）執(zhí)行的，所以強調“按時完工”；而 Kanban 更關注最大 WIP，所以不強調時間結點。

Kanban 和 Scrum 的管理工具都是白板+貼紙的組合，主流的看板工具（如 Jira、TargetProces、Trello）都可以滿足兩者的需求。但是 Kanban 的每一列必需列出最大的 WIP 限制，要求每一列的卡片數量不得高于這個限制。

Kanban Board

此外，Scrum 看板往往服務于一個較小組織，人力安排上要求這個組織包含全流程相關的所有技能，比如設計、測試、開發(fā)、架構都能在這個組織里找到相應的角色，因此常常需要一個 member 擁有多種技能。

Kanban 相對應于一個較大組織的全流程管理，一個小組往往只負責其中幾個相鄰泳道；人力分工更加精細，更趨向傳統工業(yè)上的流水線管理。

Which to choose

那到底是選 Kanban，還是 Scrum 呢？顯然沒有明確的界碑，不過有這么幾點建議可以用作參考。

• 選 Scrum

  • 你可以相對容易地細分每個任務，并且這些細分的任務塊都能在規(guī)定時間內（比如兩周）完成
  • 需要整個項目的高度可預測性，Scrum 專注于將 sprint 時間減到最少
  • 如果團隊成員較新，Scrum 可以幫助大家更快地了解開發(fā)的全流程

• 選 Kanban

  • 如果你的項目變更比較頻繁，包括需求、人力、時間等等變更
  • 任務塊很難細分，并且?guī)缀醪豢赡茉趦芍軆韧旯?/li>
  • 團隊比較成熟且紀律良好，即便沒有指定 deadline 也能保證作業(yè)能及時完工

當然，我們也不必拘泥于教條，現實中常常把它們倆結合使用，現在還給這種結合起了一個專業(yè)名詞，叫Scrumban。敏捷軟件開發(fā)的“敏捷”是簡單高效的意思，大家千萬不要把它們搞成了玄學；尤其是“原教旨主義”這一套，更是大可不必。

Benefits

OK，我們再來總結一下 Kanban 方法的優(yōu)點：

• 靈活性（Flexibility）

  由于 Kanban 并沒有規(guī)定的時間限制，因而團隊可以更輕易地調整任務優(yōu)先級，以便盡快解決生產瓶頸

• 透明性（Transparency）

  團隊共用一張視圖，每個人都可以清晰地觀察到工作進度；領導干部能從更宏觀的視角觀察流水，并幫助制定提升計劃

• 關注度（Focus）

  Kanban 的主要目標是控制 WIP 數量，因此同一時間段內，一個小 team 只需要關注特定的任務數，也就擁有了更充裕的時間來解決最緊迫的問題

• 生產效率（Productivity）

  從 1940 年代起，Kanban 就在各行業(yè)中被證明是一種行之可效的管理方式，生產團隊可以借助 Kanban 指標（Cycle time）制定長遠計劃，并提升生產效率。

講了這么多的 Kanban 的好處，也說一下我認為的缺點。Kanban 畢竟是脫胎于重工業(yè)時代，強調的是組織性和紀律性，本質上還是將人放到流水線上操作；當生產線上的工人開始疲憊后，自然而然地會轉向“摸魚的藝術”。管理者在使用 Kanban 這類工具之外，也應加入更多有趣的內容，以幫助團隊消除這類“疲憊感”。最后還是那句話——工具不是解決問題的關鍵，人才是！