📚 课程目录第1章看板基础认知

1. 看板基础认知：什么是看板？

大家好，我是老张。做软件交付和流程改进十几年了，今天咱们聊聊看板。

很多人一听到「看板」，第一反应就是那个贴满便签的白板。嗯，没错，那是看板最直观的样子。但如果你只把它当成一个「可视化任务墙」，那就太可惜了。

看板本质上是一套拉动式工作流管理系统。它不规定你做什么，也不规定你怎么做，它只帮你看清现状、限制并行、让工作流动起来。

一句话总结：看板不是教你怎么干活，而是帮你看到活是怎么被堵住的。

看板这个词，来自日语「看板（かんばん）」，原意是「招牌」或「信号牌」。它最早出现在丰田生产系统中，用来控制生产线上的物料流转。

我记得第一次读到这段历史时，觉得特别有意思。丰田的工程师发现，如果前道工序拼命生产，后道工序消化不了，中间就会堆满半成品。于是他们发明了看板卡——后道工序用完一个零件，就把看板卡送回前道工序，前道工序看到卡片才开始生产。

这就是拉动式生产的雏形。

到了2000年代，David Anderson把看板思想引入软件开发领域。他当时在微软做技术支持团队的管理，发现传统的迭代式开发根本不适合他们那种「随时可能有紧急故障」的场景。于是他借鉴了丰田的看板理念，搞出了一套适合知识工作的看板方法。

说白了，看板从工厂车间走到软件团队，核心逻辑没变——后道工序决定前道工序的节奏。

看板方法有三大核心原则。我建议你把这三点刻在脑子里，因为后面所有实战内容，都是围绕它们展开的。

可视化是看板最直观的特征。把工作流程画出来，把每个工作项的状态贴上去，让所有人一眼就能看到「现在进行到哪了」。

我在项目中遇到过很多团队，开会时大家各说各的，项目经理说「需求在开发中」，开发说「我还在等设计稿」，设计说「需求还没确认」。你看，信息完全不对称。

可视化解决的就是这个问题。它把隐性的工作状态变成显性的视觉信号。不需要问任何人，看一眼板子就知道：

我的习惯：可视化不只是贴便签。我建议把「阻塞项」用红色标记，「高风险项」用黄色标记。颜色本身就是信号。

这是看板最反直觉、也最有力量的原则。

你想想看，大多数团队的习惯是什么？能多干就多干，能并行就并行。结果呢？每个人手上同时挂着三四件事，哪件都做不完，哪件都在等。

限制在制品的意思是：明确告诉团队，每个状态列最多能放几个工作项。比如「开发中」最多3个，「测试中」最多2个。超过了，就不能再往里面塞新任务。

我曾经带过一个运维团队，大家每天忙得脚不沾地，但交付率极低。我强制把WIP限制到每人最多2件事。刚开始大家很不适应，觉得「效率变低了」。但两周后，交付周期缩短了40%。

为什么会这样？因为限制WIP迫使团队完成一件事，再开始下一件。减少了上下文切换，减少了等待时间，整体效率反而提升了。

避坑指南：我曾经犯过一个错误——把WIP设得太死。比如「开发中」限制3个，但团队有5个人。结果大家没事干，反而催生了「隐性在制品」——有人偷偷在本地做，不贴到板子上。WIP要合理，不能为了限制而限制。

可视化让你看到状态，限制WIP让你控制数量，那管理流动就是让你关注工作项从「待办」到「完成」的整个过程。

看板不关心你具体怎么做开发、怎么测试，它关心的是：工作流是否顺畅？哪里出现了瓶颈？

我常用的方法是看「累积流图」。这张图能直观反映：

如果发现某个环节的累积曲线突然变平，说明那里堵住了。这时候就要去分析：是资源不够？是依赖没解决？还是流程本身有问题？

管理流动的本质，就是持续发现瓶颈、消除瓶颈。这不是一次性的优化，而是持续的过程。

下面这张图，是我自己梳理的看板知识体系。它把刚才讲的内容串在了一起。

很多初学者会问：看板和Scrum有什么区别？我简单列个表，你一看就明白。

维度	Scrum	看板
迭代周期	固定时间盒（如2周）	无固定周期，持续交付
角色	Product Owner、Scrum Master、开发团队	无强制角色定义
变更策略	迭代内不允许变更	随时可拉入新工作项（需遵守WIP限制）
度量指标	速度（Velocity）	交付周期、吞吐率、在制品数量
适用场景	需求相对稳定、团队成熟	需求变化频繁、运维类、支持类工作

我个人习惯是：Scrum 适合做「项目」，看板适合做「服务」。如果你团队每天面对的是不确定的、随时可能插入的请求，看板比Scrum更灵活。

最后，我总结一下看板在实际中能帮你解决哪些痛点：

嗯，这一章就到这里。记住那三个原则——可视化、限制在制品、管理流动。后面的章节，我们会一个一个展开，结合真实场景，告诉你具体怎么落地。