看板基础概念:卡片、列、泳道、WIP限制与周期
好,咱们正式开始聊看板的核心概念。说实话,很多团队把看板当成“贴纸条的墙”,这其实有点浪费。看板真正的力量,藏在它那套简单但严谨的概念体系里。今天我就把这五个基础概念掰开揉碎,结合我自己的实战经验,给你讲透。
一句话总结:看板不是任务墙,而是一套可视化工作流的信号系统。卡片代表工作项,列代表阶段,泳道代表分类,WIP限制是节流阀,周期是体检报告。
2.1 看板卡片:最小工作单元
卡片,就是看板上的“原子”。每张卡片代表一个独立的工作项。可能是用户故事、Bug、技术任务,甚至是一个审批流程。
我个人习惯,卡片上必须包含三样东西:
- 标题——让人一眼知道“这是啥”
- 负责人——谁在干这活
- 截止日期或优先级——紧急程度
我在项目中遇到过,有人把卡片写得像小说,密密麻麻几百字。其实没必要。卡片是“信号”,不是“文档”。详细信息应该链到Jira或Confluence里。
我的小技巧:卡片标题控制在15字以内。超过15字,说明这个任务可能太大了,需要拆分。
举个例子,一张典型的卡片长这样:
标题:用户注册页面——邮箱验证功能
负责人:张三
优先级:P1
预估工时:4h
阻塞项:等待后端API接口
嗯,这里要注意:卡片一旦进入“进行中”列,就不要轻易改内容。改内容意味着需求变了,那应该把当前卡片归档,重新建一张。这是纪律问题。
2.2 看板列:工作流的可视化阶段
列,就是看板的“骨架”。每一列代表工作流中的一个阶段。最常见的分法是:待办 → 进行中 → 已完成。但实际项目中,这远远不够。
我记得有一次帮一个电商团队搭看板,他们一开始只设了三列,结果“进行中”那列堆了40多张卡片,谁也看不清谁在干什么。后来我们拆成了:
- 待办(Backlog)
- 分析中(需求澄清)
- 开发中
- 代码审查
- 测试中
- 待发布
- 已发布
你看,列的数量取决于你的团队工作流有多复杂。但有一条铁律:每一列必须对应一个明确的“完成标准”。比如“代码审查”列的完成标准是“至少两人Approved”。没有完成标准的列,就是黑洞。
警告:不要超过8列。列太多,看板会变成“迷宫”,反而降低信息传递效率。我见过最夸张的团队设了15列,结果没人愿意更新看板了。
2.3 看板泳道:横向的分类维度
泳道,就是看板上的“行”。列是纵向切分工作阶段,泳道是横向切分工作类别。说白了,泳道让你在同一块看板上,同时追踪不同类型的工作。
常见的泳道划分方式:
| 泳道类型 | 适用场景 | 例子 |
|---|---|---|
| 按团队 | 多团队共用一块看板 | 前端团队、后端团队、QA团队 |
| 按优先级 | 区分紧急程度 | P0紧急、P1重要、P2常规 |
| 按工作类型 | 区分任务性质 | 功能开发、技术债务、Bug修复 |
| 按服务等级 | 区分响应时效 | 标准服务、快速通道、固定交付 |
我曾经在一个运维团队里,用泳道区分“计划内工作”和“突发事件”。上面泳道放正常迭代任务,下面泳道放线上故障。这样管理层一眼就能看出:这周有多少精力被突发事件吃掉了。效果非常好。
泳道虽好,但别贪多。我建议不超过4条泳道。泳道太多,看板会变得像Excel表格,失去可视化优势。
2.4 WIP限制:防止“多任务并行”的毒药
WIP(Work In Progress)限制,是看板最反直觉、但最有价值的概念。它的意思是:每一列同时进行的卡片数量,有上限。
你想想看,为什么很多团队看起来忙得要死,产出却很低?因为每个人手里同时压着3、4个任务。今天写两行A代码,明天被拉去修B Bug,后天又去评审C方案。结果呢?所有任务都“进行中”,但一个都没完成。
WIP限制就是逼你“做完一件事,再开始下一件”。
具体怎么设?我一般用这个公式:
WIP上限 = 该列人数 × 1.5(向上取整)
比如开发列有4个人,那WIP上限就是6。为什么不是4?因为允许一点缓冲,但别超过1.5倍。超过2倍,基本等于没设限制。
核心原则:WIP限制不是用来“卡死”团队的,而是用来暴露问题的。当卡片在某一列堆积时,不要想着增加WIP上限,而要问:为什么这里堵了?是上游输入太快?还是下游处理太慢?
我曾经在一个项目里,测试列经常堵。团队第一反应是“加人”。我说别急,先看看为什么堵。结果发现,开发列一次扔过来5个功能,测试根本测不过来。后来我们把开发列的WIP从5降到3,测试列的压力立刻缓解了。你看,问题往往不在下游,而在上游。
2.5 看板周期:衡量效率的标尺
周期,就是一张卡片从“进入看板”到“完成”所花的时间。它是衡量团队交付效率的核心指标。
这里有两个容易混淆的概念:
- 前置时间(Lead Time):从客户提出需求,到需求交付的总时间。包含等待时间。
- 周期时间(Cycle Time):从团队开始处理这个需求,到完成的时间。不包含等待。
说白了,前置时间是“客户视角”,周期时间是“团队视角”。
我一般重点看周期时间。因为它直接反映团队的执行效率。如果周期时间越来越长,说明工作流里有瓶颈。如果周期时间稳定,说明团队节奏健康。
怎么算?很简单:
周期时间 = 卡片进入“进行中”列的时间 → 卡片进入“已完成”列的时间
举个例子,一张卡片周一进入开发,周五完成测试,那周期时间就是5天。
我的习惯:每周一早上花10分钟,统计上周所有完成卡片的周期时间,算个平均值。如果平均值超过7天,我就知道这周需要调整WIP限制或优化流程了。
2.6 知识体系总览
下面这张图,把这五个概念的关系画清楚了。你可以把它当作本章的“思维导图”。
你看,这五个概念不是孤立的。卡片是流动的实体,列和泳道是流动的轨道,WIP限制是红绿灯,周期是速度表。缺一个,看板就玩不转。
2.7 避坑指南:新手最容易犯的错
最后,分享几个我踩过的坑,你注意避开:
- 卡片太大——一张卡片干两周,那叫项目,不叫任务。卡片应该能在1-3天内完成。
- 列太多——超过8列,看板就失去了“一眼看清”的优势。
- WIP限制设了但不遵守——这是最致命的。设了WIP=3,但“进行中”列挂了8张卡,那WIP就是摆设。我建议每天站会时,指着看板问:“这列超了,谁先把手上的收掉?”
- 只看周期,不看WIP——周期是滞后指标,WIP是领先指标。WIP一超,周期必然变长。所以日常管理中,盯WIP比盯周期更有效。
我曾经犯过的错:刚开始推看板时,我太执着于“完美设计”,花了两周画看板结构,结果团队根本没动起来。后来我学乖了:先用最简单的三列跑起来,跑两周再迭代。记住,看板是“活”的,不是“画”出来的。