看板 vs Scrum：哪种敏捷方法更适合你的团队

很多团队引入敏捷时，会先问一句：看板还是Scrum？这句话真正想确认的，通常是哪种敏捷方法更适合自己的团队。直接的回答是：二者没有高下之分，分岔点在于工作能不能被装进固定周期。能按目标分批、按期交付的团队，Scrum的固定迭代能带来更清晰的交付节奏；任务持续进入、优先级经常调整的团队，看板更贴合实际。

在给出选型建议之前，先把两个名字背后各自意味着什么看清楚。

为什么总在看板和Scrum之间纠结

看板和Scrum都源自敏捷思想，却常被放进同一个筐里比较。一个常见的误会是把它们等同于电子看板，以为把任务卡片拖到一块板子上，就是在用看板方法或Scrum。实际上，Scrum是通过固定时长的冲刺组织工作的框架，看板是一种强调可视化和流动的流程管理方法。两者都可以用看板视图呈现任务状态，管理逻辑并不相同。

团队纠结，多数时候是因为没分清自己遇到的是哪一类问题：是节奏乱，还是工作堵在某个环节不流动。前者适合用Scrum建立节奏，后者更适合用看板先把流程暴露出来。

看板与Scrum的5个关键区别

看板和Scrum的区别可以落到五个维度：交付节奏、角色设置、变更弹性、估算度量与导入方式。

交付节奏：固定冲刺与持续流动

Scrum把工作切成等长的冲刺（Sprint），通常1周到4周，每轮结束时交付一个可用的产品增量。看板不设固定周期，工作项完成一个、拉入一个，团队关心的是任务从进入流程到完成要花多久。

角色设置：明确三角色与沿用现岗位

Scrum规定三个角色：产品负责人维护待办列表并排定优先级，ScrumMaster服务团队、保证流程运转，开发团队自组织完成交付。看板方法不预设角色，也不强制跨职能，现有岗位和汇报关系可以保持不变，导入门槛更低。

变更弹性：冲刺内稳定与随时拉动

Scrum进入一个冲刺后，范围尽量保持稳定，避免团队承诺被打断。看板没有时间盒，高优先级需求可以随时插入，调整会快速反映到下一次任务拉动。

估算与度量：迭代速度与流动效率

Scrum常在迭代计划中用故事点做估算，以速度和燃尽图跟踪进展。看板不强制估算，更关注周期时间、吞吐量和累计流图，用来判断流程在哪一环节积压。

导入方式：结构性变革与渐进式改良

落地Scrum通常要把人员重组为跨职能团队并引入新角色，组织变化较大。看板主张从现有流程开始，先把状态可视化，再逐步限制在制品，属于渐进改良。第一次尝试敏捷的组织，常从看板起步以降低阻力。

看板与Scrum对比表

下表从交付节奏、角色、变更、度量与组织影响五个维度，汇总看板与Scrum的差异：

汇总后可以看清：看板把重心放在流动效率，Scrum把重心放在周期承诺与交付节奏。两者不是先进与落后的关系，而是管理重心的差别。

看板：让工作持续流动起来的敏捷方法

看板方法起源于丰田生产系统，后来被引入知识工作领域，是团队常用的一种敏捷方法。它不规定团队如何分工，只要求把工作流看清楚、让任务平稳地流向完成。

看板的核心实践

看板的实践可以落到四点。一是把工作流可视化，让每个任务的状态随时可见。二是限制在制品（WIP），给每个环节的任务数量设上限，避免团队同时开太多头。三是显式化流程规则，谁在什么条件下把任务推进到下一状态，团队有共同约定。四是管理流动并持续改进，哪一列出现积压，就把资源补到瓶颈环节。

看板适合什么场景和团队

看板适合任务持续进入、优先级经常调整、没有明确版本边界的团队。典型场景包括运维与缺陷响应、客户需求受理、内部系统支持，以及多个团队共用一套工作流的情况。这类团队如果强行套用Scrum，容易为了凑迭代而硬排计划；用看板反而能让高优先级工作不被挡在流程后面。

Scrum：用固定迭代建立交付节奏的敏捷方法

Scrum是迭代增量式的敏捷方法，核心是用固定节奏把模糊需求逐步变成可交付的产品。它的基本单位是冲刺，团队在冲刺内完成从计划到可演示增量的全过程，结束后通过评审和回顾改进下一轮。

Scrum的角色与事件

Scrum的三个角色各管一段。产品负责人维护产品待办列表并决定做什么，开发团队自组织拆分任务并完成交付，ScrumMaster不指挥干活，负责让流程顺畅运转并帮助团队扫除障碍。支撑节奏的事件包括冲刺计划会、每日站会、冲刺评审会和冲刺回顾会，计划、同步、验收和改进各有一个固定落点。产品待办列表是需求的唯一权威来源，每个冲刺结束时都应产出潜在可发布的增量。

Scrum适合什么场景和团队

Scrum适合有明确版本或发布目标、需要向业务方定期承诺交付的团队。典型场景是产品功能迭代、平台版本开发和面向市场的项目交付。它对团队结构有要求：成员最好能覆盖从需求到测试发布的完整技能，跨职能越完整，冲刺内越少依赖外部，交付越顺畅。

看板还是Scrum：结合团队现状做敏捷方法选型

把"看板还是Scrum"换成三个关于团队自己的问题，答案会更清楚。

需求能不能被拆成分批交付的目标？能拆，就用Scrum的固定冲刺守住每个周期的承诺；拆不动，就没必要假装有固定节奏，看板更合适。

任务来源稳定，还是每天都有插单？经常插单的团队，更适合用看板随时调整优先级；硬套Scrum，插单会反复打断迭代。

团队更需要节奏纪律，还是灵活响应？想建立前者，从Scrum开始；想保留后者，从看板开始。

一个通俗的参照：Scrum像按班次发车的列车，到点就出发，适合一批有共同目标的乘客；看板像持续运转的传送带，来了就往下送，适合不断到达的小件工作。这个类比只帮助理解，判断依据仍是团队的工作形态。

规模化组织里的混合落地

在规模化研发组织里，一个团队全员套用同一种敏捷方法的情况并不多见。核心产品版本团队跑Scrum，运维、缺陷修复和内部支持团队跑看板，两者在同一组织内并存是常见形态。方法不同，不代表要各搭一套工具。

项目管理工具如果能同时承载Scrum迭代与看板流程，团队就能按需选择项目类型，组织层面也更容易统一度量口径。禅道项目管理软件完整支持Scrum、瀑布、看板项目以及融合敏捷与融合瀑布模型；执行层提供迭代、燃尽图与看板视图，看板支持自定义列和在制品设置。研发负责人可以按团队形态分别配置，而不是被单一模板绑住。

常见问题

看板方法中WIP上限一般怎么定？

WIP上限没有统一数值，常见做法是从现状出发逐步收紧。先统计团队目前平均同时推进的任务数，把它作为初始上限，之后每隔一两周下调一格，观察周期时间是否随之缩短。如果某个环节长期空转或积压，再单独调整该列的上限，而不是全盘照搬别人的数字。

看板不估算工作量，靠什么预测交付时间？

看板用历史流动数据做预测，而不是给单张卡片估算工作量。统计过去已完成工作项的平均周期时间，或看团队每周能交付多少项，就能推算一批待办大约多久做完，得到的结果通常是一个区间而不是精确日期。流动数据积累越多，预测越稳定，这也是看板把估算成本留给流程改进的原因。

Scrum的完成定义和验收标准是一回事吗？

不是一回事。完成定义是团队对"做完"的统一底线，比如代码评审通过、测试通过、文档已更新，它适用于每一个待办项；验收标准是针对单个需求的具体可验证条件。两者配合使用，完成定义守住质量下限，验收标准保证这个需求按预期实现。

燃尽图和累计流图分别解决什么问题？

燃尽图回答"这个冲刺能不能按期结束"，它展示剩余工作量随时间的下降趋势是否正常；累计流图回答"流程哪里堵"，它展示各阶段在制品数量随时间如何堆积。前者服务于当前迭代的进度判断，后者服务于跨迭代的流程改进，两者不是替代关系。