illegalCreed

中文

English

中文

English

Appearance

指南 ​

基于 Kanban 方法（David Anderson 体系，kanbanize.com/kanban-resources）与丰田生产方式编写

速查 ​

  • 可视化深度：不止分列，还要画泳道、标卡片、显式化每个阶段的入口/出口规则
  • WIP 限制取值：通常从「当前在制品的略低值」起步，渐进下调以暴露瓶颈
  • 拉系统的触发：下游出现空位（WIP 未满）才拉，不是上游做完就推
  • 瓶颈管理：瓶颈前的列会堆积，需「扩容」瓶颈环节（加人/改流程），非瓶颈环节减载
  • 流动指标：前置时间（提出→交付）、周期时间（开始→完成）、吞吐率（单位时间完成数）
  • 累积流图 CFD：堆叠各阶段在制品随时间的面积，斜率变化揭示瓶颈
  • 显式规则示例：「代码须过 PR 评审 + CI 绿才进 Done」「需求须有验收标准才进开发」
  • 反馈环：每日 replenishment 站会、每周流动评审、每月运营评审
  • Scrumban 要点：保留 Scrum 角色/Review/Retro，放弃固定 Sprint，用 WIP 驱动流式
  • Stop starting, start finishing：核心箴言，遇阻塞先收尾在手工作而非开新项
  • 服务类别（Class of Service）：标准/加急/固定日期/无形，不同类别不同 WIP 与优先级策略
  • 核心共识：Kanban 不解决「做什么」，它解决「如何让工作顺畅流动并持续改进」

4 核心实践深度 ​

实践一：可视化工作流 ​

可视化的深度远超「三列白板」：

要素说明
列（Columns）按真实流程阶段分（如 Backlog / Analysis / Dev / Test / Deploy / Done）
卡片（Cards）一张卡 = 一个工作项，写清描述、负责人、类型、阻塞标记
泳道（Swimlanes）按服务类别、团队、客户分横向通道
入口/出口标准每列定义「什么状态可进入/离开」，显式化
阻塞标记被卡住的项标红，暴露问题

目的：让价值流对所有人透明，问题无处藏身。

实践二：限制在制品（WIP Limit） ​

WIP 限制给每个流程阶段设上限。取值经验：

text
起步：从当前在制品的「略低值」开始，制造适度压力
调整：观察堆积与空闲，渐进下调（每次降 1-2）
下限：低到团队能保持稳定流动、不至于闲置
弹性：可为加急类预留一个缓冲位

关键纪律：WIP 限制是硬约束，达到上限时停止拉入新项，先完成现有的。团队常在压力下偷偷突破上限——这会摧毁 Kanban 的机制。

实践三：管理流动 ​

流动管理关注工作如何「流过」系统：

  • 识别瓶颈：瓶颈前的列堆积，瓶颈后的列空闲；改进瓶颈环节是最高杠杆
  • 减少批次大小：小批量流动更快、反馈更早（与 Lean 的小批量相通）
  • 减少等待：等待是浪费，分析卡片为何长期不动
  • 拉系统运作：下游空位触发拉入，而非上游推

核心箴言：Stop starting, start finishing（停止启动，开始完成）。

实践四：显式化流程规则 ​

把「一个工作项如何流转」的规则写清楚，让协作有共识而非默契：

text
示例规则：
  - 进入开发：需求有验收标准、PO 已确认
  - 进入测试：代码过 PR 评审、CI 全绿、单元测试覆盖达标
  - 进入 Done：满足 Definition of Done（部署到预发、文档更新）

显式规则让「为什么我的卡卡住了」有据可查，也让改进有抓手（规则本身可被讨论修改）。

拉系统详解 ​

推 vs 拉 ​

text
推系统（Push）：上游做完就推给下游 → 不顾下游容量 → 下游过载堆积
拉系统（Pull）：下游有空位才从上游拉 → 容量驱动 → 自动均衡负载

Kanban 的拉系统源自丰田 JIT：生产由实际需求（下游消耗）触发，而非上游预测。在软件开发中，「需求被完成的工作消耗」触发新需求拉入。

WIP 限制如何制造拉系统 ​

WIP 上限 = 该阶段的「容量」。当容量未满，可拉入；满了就停止拉入。这自动实现：①防止过载；②暴露瓶颈（瓶颈前堆积）；③驱动改进（堆积迫使团队思考为何流不动）。

流动指标与分析 ​

三大指标 ​

指标定义用途
前置时间 Lead Time需求提出 → 交付 完整时长客户视角的交付速度
周期时间 Cycle Time开始处理 → 完成 处理时长团队处理效率
吞吐率 Throughput单位时间完成项数系统产能

累积流图（CFD） ​

CFD 用堆叠面积图展示各阶段在制品随时间的变化：

  • 带宽（各阶段面积之和的厚度）：总在制品量，变薄说明流动改善
  • 斜率：吞吐率，斜率平缓说明流动停滞
  • 某阶段面积突然变厚：该阶段是瓶颈

交付预测 ​

用周期时间的统计分布（常为右偏）做预测：如「80% 的项在 X 天内完成」。这比 Scrum 的「Velocity 预测」更基于数据。

服务类别（Class of Service） ​

不同类别的工项用不同策略：

类别特征WIP/优先级策略
标准 Standard普通需求正常排队
加速 Expedite紧急、阻塞性可超 WIP、优先处理，但同时只允许 1 个
固定日期 Fixed Date有硬截止日按日期倒排，预留容量
无形 Intangible长期改进、风险缓解填充剩余容量

服务类别让团队对不同紧急度的工作有明确策略，而非一律 FIFO。

Scrumban 实践要点 ​

Scrumban = Scrum 结构 + Kanban 流式：

保留（来自 Scrum）替换为（来自 Kanban）
PO / SM 角色保留
Sprint Review / Retrospective保留（按需频率）
固定长度 Sprint放弃，改连续流
Sprint Backlog 承诺放弃，改 WIP 限制驱动
Velocity改用吞吐率、前置时间

适用：运维 + 产品混合团队、不便固定迭代节奏的场景。

反模式清单 ​

反模式表现纠正
无 WIP 限制的「白板」只画列不限数设 WIP 上限并执行
偷偷突破 WIP压力下随意加项把 WIP 当硬约束
只可视化不改进板漂亮但流动停滞用 CFD/指标驱动改进
把板当任务清单卡片长期不动区分 Backlog 与 WIP 列
无显式规则流转靠默契写清入口/出口标准
加速类滥用一切都标「紧急」限制加速类数量

Kanban 与 Lean、Scrum 的关系 ​

关系说明
Kanban 与 Lean同源（丰田 TPS），Kanban 是 Lean「拉动 + JIT」在工作流管理的具体化
Kanban 与 Scrum同属敏捷伞，可融合（Scrumban）；Kanban 连续流，Scrum 时间盒
Kanban 与 DevOpsKanban 的流动可视化与 DevOps 的 CI/CD 流水线互补