刚接触敏捷转型的团队对 Kanban 和 Scrum 的基本概念和应用环境都不陌生，但都是作为被动接受者来理解和使用的，这篇文章的目的是希望基于底层逻辑来阐述看板的艺术来帮助团队加深理解，从而帮助 Scrum Master 在带领团队的过程中灵活运用。
Kanban的艺术就是通过可视化，让问题以一种有逻辑的方式呈现出来。
什么是有逻辑的方式？
Kanban是可视化及优化实现价值的工作流的方式。
举一个例子，团队要完成一个降本的方案发布，团队的价值是发布完整的方案，这里就包括：可能性分析 — 价值评估 — 审查 — 构建方案 — 方案验证 — 整合及测试 — 供应链应用（供应商/工厂） — 前线验证。这就是一条按照价值交付的工作流逻辑可视化方式。
Kanban可以帮助识别哪些问题？
当通过看板可视化实现价值的工作流后，随着流动的过程，识别出组织和团队在实现价值过程中的浪费和阻碍，限制WIP，减少批次量大小并管理队列长度。在这个过程中核心是避免陷入局部优化的陷阱。
开发交付速度快真的有有意义么？
作为研发部门的一员，对这个场景并不陌生，我们经常会被挑战开发的交付速度不够快，进而研发的部门经理就会和利益相关方开始一场资源和优先级协商的拉锯战。我们经常很容易的将交付速度慢的现象归根于开发速度。如果开发交付速度是每个冲刺5个故事，支持的测试只能每个冲刺交付其中的3个故事，这3个故事中只有2个故事能被执行到生产线系统。
资源短缺是根源么？
通过看板我们比较容易能够看出工作流中的瓶颈出现在哪个环节，进而分析其根源，当然这里有一个很奇怪的现象就是一旦识别出瓶颈，争夺资源的现象就会紧跟其后，这里的资源包括计划需要新招人员，外包服务，或者从其他项目中中途调配资源等等，这些都属于局部优化的范畴。
在进行优化措施之前，首先要回答：“我们确实需要扩大瓶颈环节的吞吐量么？”如何理解这个问题，继续用上面这个例子来阐述，开发每个冲刺交付5个故事，测试只能交付其中3个，供应链应用只能实现其中2个，那么最终这2个故事的交付能不能实现产品负责人产品目标？满足利益相关方的期待？我们往往错误地将资源利用率优先于有用的价值增量。当然现实情况，大部分是交付的速度不符合产品实现的策略，这时候我们需要通过增加瓶颈环节的吞吐量进而提高整个交付价值流的速度。资源短缺往往不是仅有的造成这种现象的原因，我们仍然需要运用系统性思维来将这个瓶颈环节放在整个价值交付链条中来分析根本原因，或许造成瓶颈的只是在某一个评审环节，或者某一项特殊的技能。总之，看板的应用是将一个系统的，端到端的价值流通过可视化的方式，让影响、参与并且实现这个价值交付的所有人看到，并在不断的流动的过程中，识别出问题所在，并且仍然在系统性思维的指导下，灵活运用，找到不断优化的方法。
注：部分图片来源于网络
关于作者
Katara Nie Scrum中文网敏捷教练。从业15年，从产品开发、项目经理、产品负责人到敏捷教练，深度参与大型设备解决方案新产品开发的全链条开发。在业务驱动、需求管理、供应链实施、领导力沟通、全球团队及跨公司团队管理等方面具有丰富的经验，擅长帮助大型企业关注客户价值、业务导向、用户心态和流程改进，以推动价值交付。
