What's Kanban

Kanban，源自日语“看板”（冷知识：Kanban 和汉语拼音一致），是由日本丰田公司的工程师大野大一于 1940 年发明的一套及时管理模式（Just In Time， JIT）。JIT 的核心理念是：

让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量

Toyota

在敏捷软件开发流行后，工程管理人员也将 Kanban 引入到了软件开发当中，成为了与 Scrum 比肩的一套通用实现模式。虽然现代版 Kanban 比当年丰田几只木架、几张贴纸丰富得多，但是主要功能还是还是这么几点：

可视化工作
限制进行中的工作（WIP）
最大化工作效率或流程
持续改善团队秩序

Basic

Kanban 的基本组成其实非常简单：一块看板，一个泳道图和几张贴纸：

Kanban Basic

Kanban Board:

丰田用的看板非常简陋，现代的开发团队通常会使用，例如trello，这种更专门的看板工具。上面提到过，看板的主要功能是可视化一个项目或是工作流。它能直观地展示任务项，使团队成员随时查看每个任务的状态。
Kanban List or Lane

泳道图的每一列表示项目进程的不同阶段；每一个泳道上会贴一些卡片，代表该阶段正在处理的任务。我们可以将整块看板抽象为管道，每个泳道就是管道内先后执行的处理器，卡片从左往后通过管道后，完成产品交付；交付花费的时间我们称为 Cycle time，是 Kanban 的一个重要指标。
Pipeline & Processors
各泳道通常使用 To-Do、Doing、Done 这类能明确表达流程先后顺序的标签，以帮助我们直观地发现各个阶段的瓶颈。我曾看到过有些团队的看板泳道是“高”、“中”、“低”这种优先级标签，这个一般用作 planning 阶段的任务池（backlog），常于 Kanban 结合使用。
Kanban Card

每张卡片代表的是一个任务项，它一般包括受托人、截止时间、优先级、分类、状态等等 tag，现代开发工具一般都可以对这些 tag 进行筛选和查询。开发团队通过对卡片进度的追踪，可以了解到该任务的生命周期。

这里再废话几句，Kanban 在上世纪四十年代被发明出来的时候，确实是工业界的一次“认知升级”，简单高效，影响深远。但是都这么多年了，其实也没太多神秘光环了，大家别再过分挖掘一块板或是一张纸有什么内在的深刻的含义了。
Work in progress（WIP） Limits

Kanban 还有个核心概念叫做 WIP 限制，主要用来指定各阶段的最大负荷。限制 WIP 可以帮助领导干部更快地识别出工作流程中效率最低的那个阶段，也就是交付管道中的瓶颈；尽早发现瓶颈能有效防止过度生产，并及时投入资源去解决最急切的问题。
WIP 限制是 Kanban 有别于其他敏捷开发模式的最大特色。通俗来说，Kanban 关注的其实是吞吐量：通过一定的资源调动来改善吞吐量，从而提升生产效率；而不是依赖 deadline 来提升效率。
Bottleneck

Kanban vs. Scrum

OK，上文提到了另一种敏捷软件开发模式 Scrum，它也常常给我们呈现一幅贴纸卡片板的形象。那 Scrum 和 Kanban 有什么区别呢？

Role

角色分配是它们俩最直观的区别。Scrum 有三个最基本的角色扮演：

Product Owner：产品负责人，主要职责是分析用户需求，并将这些需求分解为各个子任务。他是各个任务优先级的制定者，以及最终发布产品的决策者
Scrum Master：Scrum 管理的执行者，俗称“监工”，负责人力和资源的调配，指导和监督 Scrum 开发流程的执行和落实
Team Members：就是具体干活的人，敏捷软件开发比较强调主观能动性，所以需要 member 们主动揽活，还能互相扶持

相比之下，Kanban 更简洁，没有强制的角色分配，要求每个团队成员自发地履行执行和监督的职能。当然，现实中保证会有一个领导干部的啦，不过存在感稍弱于 Scrum，还常常亲自参与干活。

Workflow

工作流程上也有很大的区别，Scrum 是基于迭代周期（Sprint）执行的，所以强调“按时完工”；而 Kanban 更关注最大 WIP，所以不强调时间结点。

Kanban 和 Scrum 的管理工具都是白板+贴纸的组合，主流的看板工具（如 Jira、TargetProces、Trello）都可以满足两者的需求。但是 Kanban 的每一列必需列出最大的 WIP 限制，要求每一列的卡片数量不得高于这个限制。

Kanban Board

此外，Scrum 看板往往服务于一个较小组织，人力安排上要求这个组织包含全流程相关的所有技能，比如设计、测试、开发、架构都能在这个组织里找到相应的角色，因此常常需要一个 member 拥有多种技能。

Kanban 相对应于一个较大组织的全流程管理，一个小组往往只负责其中几个相邻泳道；人力分工更加精细，更趋向传统工业上的流水线管理。

Which to choose

那到底是选 Kanban，还是 Scrum 呢？显然没有明确的界碑，不过有这么几点建议可以用作参考。

选 Scrum
- 你可以相对容易地细分每个任务，并且这些细分的任务块都能在规定时间内（比如两周）完成
- 需要整个项目的高度可预测性，Scrum 专注于将 sprint 时间减到最少
- 如果团队成员较新，Scrum 可以帮助大家更快地了解开发的全流程
选 Kanban
- 如果你的项目变更比较频繁，包括需求、人力、时间等等变更
- 任务块很难细分，并且几乎不可能在两周内完工
- 团队比较成熟且纪律良好，即便没有指定 deadline 也能保证作业能及时完工

当然，我们也不必拘泥于教条，现实中常常把它们俩结合使用，现在还给这种结合起了一个专业名词，叫Scrumban。敏捷软件开发的“敏捷”是简单高效的意思，大家千万不要把它们搞成了玄学；尤其是“原教旨主义”这一套，更是大可不必。

Benefits

OK，我们再来总结一下 Kanban 方法的优点：

灵活性（Flexibility）

由于 Kanban 并没有规定的时间限制，因而团队可以更轻易地调整任务优先级，以便尽快解决生产瓶颈
透明性（Transparency）

团队共用一张视图，每个人都可以清晰地观察到工作进度；领导干部能从更宏观的视角观察流水，并帮助制定提升计划
关注度（Focus）

Kanban 的主要目标是控制 WIP 数量，因此同一时间段内，一个小 team 只需要关注特定的任务数，也就拥有了更充裕的时间来解决最紧迫的问题
生产效率（Productivity）

从 1940 年代起，Kanban 就在各行业中被证明是一种行之可效的管理方式，生产团队可以借助 Kanban 指标（Cycle time）制定长远计划，并提升生产效率。

讲了这么多的 Kanban 的好处，也说一下我认为的缺点。Kanban 毕竟是脱胎于重工业时代，强调的是组织性和纪律性，本质上还是将人放到流水线上操作；当生产线上的工人开始疲惫后，自然而然地会转向“摸鱼的艺术”。管理者在使用 Kanban 这类工具之外，也应加入更多有趣的内容，以帮助团队消除这类“疲惫感”。最后还是那句话——工具不是解决问题的关键，人才是！