团队级敏捷方法

KANBAN

作者： Aka
更新时间：2024年5 月07日 16:38
发布时间：2023年12 月11日

Kanban 的定义

Kanban是⼀种优化价值（定义价值可能有多种⽅法，举例来说：包括考虑来⾃于客户、使⽤者、组织及环境的各种需要。）流动 (the flow of value) 的策略，Kanban定义的核⼼是“流” (flow) 的概念，其过程使⽤了可视化与拉式系统。流是指潜在价值在系统中的流动，由于⼤多数⼯作流 (workflow) 都是为了最大化价值交付⽽存在的，Kanban的策略就是通过优化流来优化价值交付的过程，但优化并不⼀定意味着最⼤化。更确切地说，价值交付过程的优化意味着团队要努⼒在如何完成⼯作的效能、效率和可预测性之间找到恰当的平衡：

⼀个具有效能的⼯作流是能够在客户需要的时候交付他们想要的东⻄。
⼀个具有效率的⼯作流是尽可能地以最优化的⽅式分配可⽤且具经济效益的资源以交付价值。
⼀个更具可预测性的⼯作流是能够在可接受的不确定性范围内准确地预测价值交付。

为了实现上述的目标，Kanban的策略是让成员尽早地发现和提出问题。只有在这三个要素之间找到⼀个可持续的平衡时，才能达成价值交付的优化。
因为Kanban能使⽤在各种不同的⼯作流上，应⽤场景不限于某个产业或业务场景。专业知识⼯作者，例如财务⾦融、市场营销、医疗保健和软件开发等，都从 Kanban 的实践中获益。

发展历史

基本的看板方法起源于精益制造，其灵感来自丰田生产系统。它起源于20世纪40年代末，当时丰田汽车公司实施了一种名为“及时”的生产系统，其目标是根据客户需求进行生产，并确定生产线内可能存在的材料短缺。但正是Corbis的一个团队意识到，丰田设计的这种方法可以成为适用于任何类型组织流程的流程。看板通常与Scrum等方法和框架结合使用在软件开发中。
David Anderson 2010年的著作《看板》描述了该方法的演变，从2004年微软的一个项目（使用约束理论方法并结合鼓–缓冲–绳（与看板拉动系统类似））到2006年至2007年Corbis的一个工程）。2009年，Don Reinertsen出版了一本关于第二代精益产品开发的书，其中描述了看板系统的采用以及数据收集和管理决策经济模型的使用。另一个早期贡献来自Corey Ladas，他在2008年出版的《Scrumban》一书中提出，看板可以改善软件开发中的scrum。拉达斯将scrumban视为从scrum到看板的过渡。Jim Benson和Tonianne DeMaria Barry于2011年出版了《个人看板》，将看板应用于个人和小团队。在《来自内部的看板》（2014）中，Mike Burrows解释了看板的原则、实践和潜在价值观，并将其与早期的理论和模型联系起来。在《敏捷项目管理与看板》（2015）中Eric Brechner概述了看板在微软和Xbox的实践。Klaus Leopold和Siegfried Kaltenecker的《看板变革领导力》（2015）从变革管理的角度解释了该方法，并为变革举措提供了指导。2016年，精益看板大学出版社出版了该方法的简明指南，其中包括早期看板项目的改进和扩展。

2020年，John Coleman和Daniel Vacanti出版了《看板指南》[6]，描述了操作看板系统所需的最低条件。Colleen Johnson、Daniel Vacanti和Prateek Singh于2022年出版了《看板口袋指南》[15]，帮助从业者了解看板实践。Will Seele和Daniel Vacanti还在2022年出版了《Scrum团队的流量指标》[16]一书，将看板中常用的指标的好处带给Scrum团队。

Kanban 理论基础

Kanban 得于著名的流动理论，包括（但不限于）：系统思维、精益原则、队列理论（批次⼤⼩与队列规模）、可变性以及质量控制。随着时间的推移，基于这些理论持续地改进Kanban系统是组织试图优化价值交付的⼀个途径。
⽤以建立Kanban的理论也被⽤于现有许多的以价值为导向的⽅法论和框架。因为具有这些相似处，Kanban能够⽽且也应该⽤于强化这些交付技术。

Kanban 实践

Kanban包括以下三个协同⼯作的实践：

定义与可视化⼯作流
主动管理⼯作流中的⼯作项 (item)
改进⼯作流

在执⾏时，这些 Kanban 实践被统称为 Kanban 系统 (Kanban system)。在 Kanban 系统中参与价值交付的⼈员称为 Kanban 系统成员 (Kanban system members)。

定义与可视化⼯作流

优化流须先定义流在特定情境中流的含义。在其情境中，Kanban 系统成员对于流的明确且共同的认知，就称为 “⼯作流的定义” (Definition of Workflow，DoW)。 DoW 是 Kanban 的基础概念。

最低限度——成员必须要⽤下列全部的要素建立他们的 DoW：

在⼯作流中移动的各个价值单位的定义。这些价值单位被称为 “⼯作项”（或是 “项”）(work items (or items) )。
在⼯作流中 “开始” 与 “完成” ⼯作项的定义。根据⼯作项的不同，⼯作流可能有多个起点或终点。
⼯作项⾃开始到结束时流动所经过的⼀个或多个已定义状态。介于开始节点与结束节点间的任何⼀个⼯作项就称为 “在制品” (work in progress， WIP)。
如何从开始到结束间控制 WIP 的定义。
有关⼯作项如何在每个状态中从开始到完成的明确规定。
⼀份⽤来预估⼀个⼯作项从开始到完成所应花费的时间的 “服务⽔平期望” (service level expectation，SLE)。

根据团队所遇状况不同，Kanban 系统成员经常须在 DoW 加入额外的要素，像是各种价值观、原则及⼯作协议等。

主动管理⼯作流中的⼯作项

⼯作流中各种⼯作项的主动管理的方式可以采⽤多种不同的形式，包括（但不限于）：

控制 WIP。
避免⼯作项在⼯作流的任何⼀个阶段堆叠起来。
使⽤ SLE 为参照指标，确保⼯作项不会在⽆必要的情况下陈放过久。
解除障碍。

经常性地审查对于⼯作项的主动管理，是 Kanban 系统成员常⽤的⼀种改进实践，但是并不需要强制规定审查或是定期性会议，只要的确有发⽣主动管理的事实即可。

控制 WIP

Kanban 系统成员须明确地控制在⼯作流中从开始到结束间的⼯作项数量。这种控制称为 “WIP 数量限制”（WIP limits），通常是以数字或是以在 Kanban ⾯板上的空位/令牌来展现。⼀个 WIP 数量限制可以包括（但不限于）在单⼀栏位中、多个分组的栏位/泳道/区块内、或是整个⾯板上的⼯作项。控制 WIP 不仅能够有助于提升⼯作的流动效率，也能够改进 Kanban 系统成员共同的专注、承诺及协作。
通过控制 WIP 还会带来⼀个额外的好处，那就是建立了拉式系统。称为拉式系统的缘由是因为Kanban 系统成员只会在出现明确信号告知有容量时，才会拉起⼀个⼯作项开始。当 WIP 低于 DoW 上设定的限制时，就是选取新⼯作项的信号。成员应该避免在⼯作流上特定区域中拉/挑选⾼于 WIP Limit 所限制的⼯作项数量。在极少数情况下，系统成员可能会同意拉入额外超过 WIP 数量限制的⼯作项，但这种情况不应该成为常规操作。任何在控制 WIP 时可接受的例外情况都应该作为 DoW 的⼀部分予以明确说明。

服务⽔平期望

SLE 是⼀个对单个⼯作项从开始到完成所要花费时间的预测。 SLE 本⾝有两部分：花费的时间和与该时间相关的工作量比率（例如，“85% 的⼯作项将在 8 天或更短的时间内完成”）。 SLE 应该基于过往历史的周期时间 (cycle time)计算，并在 Kanban ⾯板 (kanban board) 上进⾏可视化展现。如果过往历史的周期时间数据不存在，那么⽤最佳的预测值即可，直到有⾜够的历史数据⽤于合适的 SLE 计算。

改进⼯作流

将 DoW 清晰明确后，Kanban 系统成员的责任就是要持续地改进⼯作流，以在效能、效率及可预测性间达到更好的平衡。团队⽤从可视化与 Kanban 各种其它度量所得来的信息，来指导他们如何调整 DoW 以取得最⼤利益。
常⻅的做法是不时地审查 DoW 并讨论与实施所需要的变革。然⽽，并不需等到例⾏的正式会议时才实施这些变更。 Kanban 系统成员可以⽽且应该根据实际情境的变化⽽立刻做出改变。也没有任何规范要求⼯作流的改进必须是⼩范围且增量的。如果可视化和 Kanban 度量显⽰需要进⾏重⼤的变革，那也是成员应该立刻实施的。

Kanban 度量
Kanban 的应⽤，需要收集和分析关于流的最低度量（或度量指标）组合。这些度量能反映当前 Kanban 系统的健康情况与效能，并有助于快速做出关于如何交付价值的决策。
必须跟踪的四项流度量项为：