What's Kanban
Kanban，源自日语“看板”（冷知识：Kanban 和汉语拼音一致），是由日本丰田公司的工程师大野大一于 1940 年发明的一套及时管理模式（Just In Time， JIT）。JIT 的核心理念是：
让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量
在敏捷软件开发流行后，工程管理人员也将 Kanban 引入到了软件开发当中，成为了与 Scrum 比肩的一套通用实现模式。虽然现代版 Kanban 比当年丰田几只木架、几张贴纸丰富得多，但是主要功能还是还是这么几点：
- 可视化工作
- 限制进行中的工作（WIP）
- 最大化工作效率或流程
- 持续改善团队秩序
Basic
Kanban 的基本组成其实非常简单：一块看板，一个泳道图和几张贴纸：
-
Kanban Board:
丰田用的看板非常简陋，现代的开发团队通常会使用，例如trello，这种更专门的看板工具。上面提到过，看板的主要功能是可视化一个项目或是工作流。它能直观地展示任务项，使团队成员随时查看每个任务的状态。
-
Kanban List or Lane
泳道图的每一列表示项目进程的不同阶段；每一个泳道上会贴一些卡片，代表该阶段正在处理的任务。我们可以将整块看板抽象为管道，每个泳道就是管道内先后执行的处理器，卡片从左往后通过管道后，才能结束整个工作流。
各泳道通常使用 To-Do、Doing、Done 这类能明确表达流程先后顺序的标签，以帮助我们直观地发现各个阶段的瓶颈。我曾看到过有些团队的看板泳道是“高”、“中”、“低”这种优先级标签，这个一般用作 planning 阶段的任务池（backlog），常于 Kanban 结合使用。
-
Kanban Card
每张卡片代表的是一个任务项，它一般包括受托人、截止时间、优先级、分类、状态等等 tag，现代开发工具一般都可以对这些 tag 进行筛选和查询。开发团队通过对卡片进度的追踪，可以了解到该任务的生命周期。
-
Work in progress（WIP） Limits
Kanban 还有个概念叫做 WIP limits，主要用来限制项目各执行阶段的最大负荷。限制 WIP 可以更轻松地识别团队工作流程中效率最低的阶段，也就是交付管道中的瓶颈。尽早发现瓶颈能有效防止过度生产，并及时投入人力或资源去解决最急切的问题。
Kanban vs. Scrum
OK，上文提到了另一种敏捷软件开发模式 Scrum，它也常常给我们呈现一幅贴纸卡片板的形象。那 Scrum 和 Kanban 有什么区别呢？
Role
角色分配是它们俩最直观的区别。Scrum 有三个最基本的角色扮演：
- Product Owner：产品负责人，主要职责是分析用户需求，并将这些需求分解为各个子任务。他是各个任务优先级的制定者，以及最终发布产品的决策者
- Scrum Master：Scrum 管理的执行者，俗称“监工”，负责人力和资源的调配，指导和监督 Scrum 开发流程的执行和落实
- Team Members：就是具体干活的人，敏捷软件开发比较强调主观能动性，所以需要 member 们主动揽活，还能互相扶持
相比之下，Kanban 更简洁，没有强制的角色分配，要求每个团队成员自发地履行执行和监督的职能。当然，现实中保证会有一个领导干部的啦，不过存在感稍弱于 Scrum，还常常亲自参与干活。
Workflow
工作流程上也有很大的区别，Scrum 是基于迭代（iteration）执行的，所以强调“按时完工”；而 Kanban 更关注最大 WIP，所以不强调时间结点。
Kanban 和 Scrum 的管理工具都是白板+贴纸的组合，主流的看板工具（如 Jira、TargetProces、Trello）都可以满足两者的需求。但是 Kanban 的每一列必需列出最大的 WIP 限制，要求每一列的卡片数量不得高于这个限制。
此外，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 指标制定长远计划，并提升生产效率。
讲了这么多的 Kanban 的好处，也说一下我认为的缺点。Kanban 毕竟是脱胎于重工业时代，强调的是组织性和纪律性，本质上还是将人放到流水线上操作；当生产线上的工人开始疲惫后，自然而然地会转向“摸鱼的艺术”。管理者在使用 Kanban 这类工具之外，也应加入更多更有趣的内容，以帮助团队消除这类“疲惫感”。最后还是那句话——工具不是解决问题的关键，人才是！
