软件迭代 Sprint 看板
使用场景: 研发同学或 Scrum Master，管理两周 Sprint
待办池：所有待排期故事
本次 Sprint：已优先级排序的任务
进行中（在制品上限：3）：开发中
代码审查：等待 Code Review
测试中：QA 验证
已完成：部署到测试环境
这样组织的原因: 把代码审查和测试拆成独立的两列，审查瓶颈一眼可见——代码审查列堆满时，团队就知道该停止开新任务，先把审查消化掉。
看板示例
下面这些案例展示了不同团队和场景中最常用的看板结构：软件研发、内容生产、招聘流程、客户支持和个人任务管理。每个案例都给出了真实的列结构，找一个最接近你场景的直接复用就行。
真实案例
内容生产流水线
使用场景: 内容负责人或编辑，统筹多名内容作者
选题池：内容储备
需求简报：进行中
写作：初稿阶段
编辑：审稿中
设计：配图制作
待发布：已安排上线时间
已发布
这样组织的原因: 七列内容看板能清楚定位每篇文章卡在哪里——如果五篇稿子堆在编辑列，说明瓶颈在审稿环节，而不是写作速度。
招聘流程看板
使用场景: 招聘负责人或用人部门，追踪候选人进度
已投递：新简历
简历筛选：审核中
电话初筛：待约或已完成
面试：现场或视频面试
背景调查
已发 Offer
已入职 / 未通过
这样组织的原因: 把招聘流程画成看板，能清楚看出每个阶段有多少候选人在流转，以及漏斗推进速度能否赶上目标入职日期。
客户支持工单队列
使用场景: 客服 Team Lead，管理工单流转和 SLA 履约
待处理：未分配工单
处理中：跟进中
等待客户回复：已阻塞
已升级：转给技术团队
已解决
这样组织的原因: "等待客户回复"列防止工单长期停在处理中而无动作，让团队清楚知道哪些延误来自内部、哪些是外部等待。
产品发布 Checklist 看板
使用场景: 产品经理，协调跨职能发布工作
规划中：策略和范围确认
进行中：任务推进
被阻塞：等待输入或依赖项
待审批：等待确认
已完成
这样组织的原因: 带有"被阻塞"列的发布看板让依赖问题在拖延发布之前就暴露出来——产品经理一眼看清什么卡住了、谁来解除阻塞。
个人任务看板
使用场景: 个人贡献者或自由职业者，管理自己的工作量
收件箱：所有新进事项
本周计划：已承诺完成
进行中（上限 2）：当前执行
等待中：已委托或被阻塞
已完成
这样组织的原因: 进行中严格限制 2 项，强制优先级排序——新任务开始之前必须先完成一件进行中的事，从根本上减少上下文切换。
使用技巧
- 每个活跃列都要设置在制品上限——没有上限的看板只是一面便利贴墙，不能发现瓶颈。
- 用卡片颜色或标签区分任务类型（缺陷、功能、杂务），优先级一目了然。
- 每次站会先看被阻塞的卡片——一张阻塞卡可能卡住的工作比三张进行中的任务还多。
- 已完成的卡片每周归档而不是删除，完成列的历史记录是做速度统计和复盘的重要数据。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=kanban
使用这个模板