Kanban的整体价值流 与 工序级价值流的流程效率
回顾在使用kanban的项目中，有一个问题一直被搁置，就是如果需求不断涌现，也许团队有些正在开发的需求被暂停或者阻塞，但是团队会因此立即拉取新的工作开始工作，是不是这种情况下在看 kanban 的整体价值流的流程效率没有太大的意义？我们只需要看工序级价值流的流程效率并对此不断优化就好了？大量的外部阻塞， 导致整体价值流效率过于糟糕，这种情况下该如何汇报 ？
1. 观点
针对汇报，可以提供两份不同的报告，一份是全局视角的整体价值流效率，另一份是剔除掉外部阻塞问题的整体价值流效率，而不是一味的只看工序级价值流并优化，这会带来虚假繁荣的现象。
虽然团队在使用 KANBAN 的时候，外部阻塞时可以从整体价值流分析中单独剥离出来，不和团队内部价值流效率混在一起评估，但是这仍然会带来隐形的问题。
2. 解决方案
内部阻塞 → 团队要想办法解决
外部阻塞 → 明确外部阻塞导致无法继续等工作，可暂时从 WIP 里移出 ，并且上报给PO/管理层处理 可以拉取新的任务
- 设置专门的Blocked列：这个列不计入开发阶段的 WIP，但依然计入整体价值流时间
- 计算一个包含所有工序的整体价值流效率，再计算一个剔除外部阻塞时间的整体价值流效率
- 汇报时准备两份数据：
- 全局价值流效率（反映全局的开发状态，很烂）
- 剔除Blocked列的全局价值流效率（剔除外部阻塞后，反映团队的真实状态，很好）
总LeadTime = 内部增值 + 内部阻塞 + 外部阻塞 开发时间 = 3天 ✅ 增值 等待review = 1天 ⚠️ 非增值（内部阻塞） 等待第三方API = 5天 ⚠️ 非增值（外部阻塞） 测试时间 = 1天 ✅ 增值 上线验证 = 1天 ✅ 增值 ───────────────────────── 总时间 = 11天 全局流程效率 = (3+1+1) / 11 × 100% = 45.46%剔除外部阻塞的LeadTime = 内部增值 + 内部阻塞 开发时间 = 3天 ✅ 增值 等待review = 1天 ⚠️ 非增值（内部阻塞） 测试时间 = 1天 ✅ 增值 上线验证 = 1天 ✅ 增值 ───────────────────────── 内部总时间 = 5天 内部全局流程效率 = (3+1+1) / 6 × 100% = 83.33%3. 解决方案带来的新问题
虽然kanban驱动开发，遇到外部阻塞团队可以自动拉取用户故事，并且在汇报的时候，某种程度上应该重点参考剔除掉外部阻塞在看价值流，但是整体的价值仍然有意义（不管你是否立即切换上下文），这个问题都逃不掉。
- 立即上下文切换成本：当外部阻塞解除时，如果开发人员如必须在 A（旧任务）和 B（新任务）进行上下文之间切换。那大脑重新进入状态带来的损失是非常大的。
- 延迟切换上下文成本：当 A 任务解除阻塞时，如果开发人员正忙于 B 任务的关键部分，A 就会继续等待。这就导致 A 的交付时间被二次推迟。
- 隐藏了系统性整体问题：这是最关键的一点。如果你通过拉取新故事来“消化”了阻塞带来的空闲，PMO或者其他管理层就永远看不见外部依赖有多糟糕。
之所以仍然把Kanban整体价值流展示出来，正是为了通过数据倒逼组织去解决那个外部原因。