列作为状态

卡片板使工作可见。每个工作都是一张卡片。卡片从左到右通过表示状态的列移动。

经典的列是：待办 → 已选择 → 进行中 → 审查 → 已完成

但确切的列并不重要。重要的是每张卡片都有一个当前状态，而且这个状态对所有在该系统中工作的人都可见。

一个卡片代表什么

一个卡片代表一个可以独立完成的工作单元。不是一个项目。不是一个目标。一个明确、范围内的东西，具有明确的完成标准。

好的卡片示例：在生产服务器上旋转SSH密钥：完成标准是所有服务器都显示新密钥在authorized_keys中，并且旧密钥已被移除。

坏的卡片示例：提高安全性。（这是一個项目，而不是一个任务。将其拆分。）

WIP限制

在图表中，进行中列显示了WIP限制：3。这意味着同一时间最多只能有三张卡片处于进行中状态。如果你想提取第四张卡片，你必须先完成一张。

这感觉像是一个约束。这确实是一个约束。WIP限制使你在开始新事情之前完成你已经开始的工作。这在后续部分中会详细介绍为什么这很重要。

制定工作卡片

在卡片板中设置最难的技能不是画板。是制定卡片。太大的话，一张卡片可能在进行中几个星期，阻塞其他工作。太小的话，板子上就会充满噪音。

隔离工作没问题

任何多学科操作都有功能工作中心：面包店有面包、糕点、 savoury 和前台。一个产品工作室有设计、内容、构建和运营。一个建筑项目有框架、水管、电气和修饰。这些中心存在于一些原因：深度专门化需要专注的所有权。

卡片板不会消除这些分隔。它使在它们之间的交接明确和可见。

The handoff card

当工作单元从一个工作中心移动到另一个工作中心时,例如,设计资产需要在构建页面之前写复制,一个 手动卡 随着它一起移动。下游中心在他们有能力时看到卡片出现在他们的Backlog中。他们拉取它。没有需要发送的电子邮件。没有需要协调的会议。卡片本身就是信号。

What the diagram shows

★票开始在设计中心(In Progress: visual assets)。当设计完成他们的部分时,一个手动卡被创建,并在Build中心的Backlog中出现。Build拉取它。然后Ops拉取它。每个中心都有自己的板。每个板只显示该中心的当前工作。但是,★在所有这些板上都在移动,并且每个人都可以看到它在哪里。

这就是应用在组织中的超市见解:每个工作中心都是一个货架。卡片只在下游货架上重新补充,当上游工作被拉动并消耗时。

设计一个手动

手动卡是工作中心之间的合同。它必须包含足够的上下文,以便接收的团队可以在没有会议的情况下采取行动。

停止开始。开始完成。

WIP是Work In Progress的缩写。WIP限制是指在给定列中同时有多少张卡的上限。

这听起来像是一个限制。这就是点子。

为什么限制有助于

每次你开始一个新的任务而没有完成前一个任务,你都要支付上下文切换税。你的大脑加载新任务的上下文,部分卸载老任务。当你返回到老任务时,你需要重新加载它。对于知识工作,写作,调试,设计,审阅,这个重新加载成本会用小时来计算,而不是秒。

WIP限制防止工作积压。它们还会产生更有价值的结果：暴露瓶颈。

瓶颈变得显著

如果Review列的WIP限制为2，并且总是保持在2，那么这意味着：审查速度比生产慢。更多的工作完成了In Progress状态，但无法被Review消耗。没有WIP限制，板子上会充满‘完成但等待审查’的卡片，瓶颈无法被发现。有了WIP限制，In Progress列不能接受新的卡片，整个团队都能看到约束。

这不是一个失败。这是一个信息。系统告诉你需要解决Review的问题，增加人力，配对工作，减少批处理大小，而不是盲目推动更多的工作。

Little's Law（非正式）

Lead time（一个卡片从开始到完成所需时间）= Work In Progress ÷ Throughput（每单位时间完成的卡片数）。如果你想缩短Lead time而不增加人力，减少WIP。少了些在飞行中的事情，每件事情都能更快地完成。

R = (W × C) + T

WIP限制保护三个变量。效率顾问布莱恩·特雷西（Brian Tracy）在1986年给它们起了名字。

R = (W × C) + T

- R: 结果：你想要的结果

- W: 目标清晰度：你知道自己想要什么的清晰程度（0-10）

- C: 集中度：专注力强度（0-10）

- T: 工作时间（无干扰小时数）

为什么W和C相乘

目标清晰度和专注力不是独立的。对一个模糊目标投入高专注度会产生快速的错误方向移动。目标清晰度达到10分但没有专注力会产生什么也没有。它们相互作用：这就是为什么特雷西将它们写成乘积，而不是和的原因。一个在每个方面都得到了9/10的结果为R = 81 + T。一个在每个方面都得到了3/10的结果为R = 9 + T。差异不是累加的。

为什么T相加

每一个无干扰的小时都会线性地增加结果。T不能将W和C的乘积叠加：它只能在乘积的上面堆叠。这解释了为什么第一个动作总是改进W和C，而不是加长工作时间。T在一个低(W × C)乘积上增加并不会产生好的结果。

kanban板对每个变量的影响

- W: 一个清晰的卡片（具有清晰标题、可测验收标准、单一负责人）在开始工作之前提高W。模糊的卡片会自动降低W。

- C: WIP限制强制专注。Active列只有一个卡片，意味着对一个问题全神贯注。Active列有三张卡片，C被分三等分。

- T: 巨幕时间器创建无阻碍的工作时间 T 测量。板上的计时器不是装饰品:它实时跟踪 T。

特蕾西声称，优化 W、C 和 T 时，任何问题都可以在 30 分钟内解决。Kanban 板是优化所有三个的工具。

阅读板

练习从板状态中读取瓶颈。

不是敏捷。不是瀑布。

敏捷是一种方法论。瀑布是一种方法论。Kanban是一种系统。

方法论规定你如何工作。系统描述工作的真相。Kanban 不告诉你要有两周的冲刺, 每日站立会议或回顾。它告诉你一件事:让工作可见,限制WIP,并拉动。

方法论的问题

敏捷对于迭代地构建产品的团队非常适用，尤其是软件领域。而瀑布方法适用于需求明确、已知未知因素较少的项目，如建筑、硬件制造。然而，在跨学科工作中，设计任务与履行任务的循环时间和“完成”定义完全不同，这两种方法无法完美映射。

强制将设计中心与运营中心纳入同一个迭代周期是错误的。适用于内容创作的两周迭代会在物流工作中产生人为紧迫感。而为协同工作设计的站立仪式则会为独立个体带来额外的开销。

在工作上寻求共识

Un方法：找到需要完成的工作。找到最适合完成它的人或合作伙伴。不要在此基础上强加一个过程：让工作通过共享可见性系统表明自己的过程。

这不是缺乏过程。这是恰当的过程：足够协调，不足以导致协调开销超过工作价值。

不要构建你可以购买的东西。不要购买你可以发展的东西。

在创建任何工作卡之前，问：这个东西是否应该存在？你构建的每个工作，你将永远拥有。每个你订阅的SaaS，你将永远依赖。每个你fork的开源依赖，你将永远维护。

决策树：我们可以发展这个吗？一个可持续产生能力的过程、技能、关系，优先考虑。如果发展不现实：我们可以购买这个吗？一个解决80%问题的现成工具，优先考虑。如果购买不现实：构建它。并知道你现在拥有了它。

大多数组织将这个顺序颠倒。他们为问题构建定制基础设施，而通用工具可以很好地解决问题，然后他们陷入维护困境。Kanban使这个问题变得清晰：你的Backlog中的每个卡都是你选择构建的东西。诚实的问题是它是否应该出现在那里。

Build / Buy / Grow

应用决策框架。

设计一个板

把它放在一起。您将为特定的跨职能场景设计Kanban系统。

场景

一家小型工作室正在以新的品牌 relaunch 他们的产品。这个工作涉及四个中心：

- 设计：新标识，视觉身份，产品摄影，页面布局

- 内容：重写产品描述，landing页面副本，发邮件的公告

- 构建：更新网站，新购物流程，来自旧URL的重定向

- 运营：更新支付处理器设置，向合作伙伴传达，重新配置分析

重启有一个硬期限：在45天内的贸易展会上，新的品牌将公开。

独自工作的陷阱

在大多数组织中，Kanban 的目的是使工作在管理层次之间可见。经理们之间协调各个部门。Kanban 减少了协调开销。

在 un 模型中，没有经理。只有独自工作的人。设计师独自工作、开发者独自工作、作家独自工作、运营独自工作。每个独自工作的人都由定义地成为一个孤岛。它们之间没有组织结构连接。没有报告关系。没有经理强制协调。

Kanban 成为协调层。不是通过扁平化孤岛，而是使它们之间的交接工作可见和明确。一个独自工作的人不需要通过电子邮件或安排会议来交接工作。他们将一张卡片放在共享看板上。接收方独自工作的人在有空闲时才会从中提取。

这解释了为什么Kanban 更适合于模型比敏捷或瀑布：它不需要共享节奏、没有联合回顾、没有同步规划。每个独自工作的人都可以设置自己的WIP限制、自己的周期时间、自己的完成标准。协调发生在卡片级别，而不是在过程级别。