从Scrum到Kanban，我们换了

一、先说结论：我们不是为了换而换

2024年第三季度，我所在的产品研发团队完成了一次彻底的工作流重组，从运行了三年半的Scrum模式切换到Kanban。这个决策在团队内部吵了整整三周，中间经历了两次投票、一次为期两周的并行试验，以及一次几乎导致核心开发离职的激烈冲突。

很多人以为我们又是一个“Scrum用不好就怪方法”的典型病例，但事实恰恰相反。我们团队在Scrum模式下交付了17个主要版本迭代，Sprint完成率稳定在87%以上，站会从未超过14分钟，回顾会议产出了超过80条有效改进项，其中71%在一个月内落地执行。用坊间流传的“Scrum成熟度模型”来套，我们至少算高成熟度团队。

那么为什么还换？核心结论就一句：Scrum的固定节奏和角色结构，在业务需求颗粒度急剧分化后，已经开始系统性地制造浪费。我们面对的不是Scrum“做不好”的问题，而是即便Scrum做得足够好，依然有团队三分之一的人觉得自己在“空转”。这个信号一旦出现，就值得动地基。

这篇文章不会讲Scrum和Kanban的定义，那些内容Wikipedia写得比我清楚。我要讲的是一支真实团队在2024年是怎么从决策到落地、从冲突到稳定，把工作方法换过去的完整经历。其中包含具体的数据变化、工具迁移细节、团队心理曲线，以及我对市面上很多流行观点的不同意见。如果你正在考虑类似的转型，或者刚转完发现不对劲，这大概是你需要的那种内容。

二、Scrum的“完美假象”是怎么裂开的

1. Sprint边界开始反噬交付效率

我们团队维护着一个电商SaaS产品的核心交易链路模块，同时承接大量来自运营侧和市场侧的小需求。2023年下半年开始，需求类型出现了肉眼可见的分化：一部分需求是结构清晰、范围可控的标准化功能迭代（适合固定Sprint），另一部分是“明天上线、后天验证”的增长实验型需求（完全不适合等两周）。

问题出在Scrum对Sprint边界的刚性保护上。我们严格执行“Sprint内不新增需求”的原则，这本身是Scrum的好实践，但当增长实验类需求占比从15%蹿升到接近40%时，这个原则开始制造两种典型浪费：

• 等待浪费：运营提了一个支付页按钮文案A/B测试的需求，周三下午提，下周一Sprint规划会才能被讨论，实际开发排到下周三。一个理论上2小时能上线验证的需求，等了整整7天。
• 捆绑浪费：为了让紧急小需求“插队”，产品经理开始把小需求强行捆绑到当前Sprint的某个用户故事里，结果一个本来5个点的故事被撑到13个点，Sprint后期全员加班。

Scrum Guide里说Sprint长度可以根据团队情况调整，我们也试过从两周缩短到一周，但一周的Sprint导致规划会议和评审会议的频率翻倍，开会时间占比从12%飙升到21%。开发同事的原话是：“我现在一周有四天在开会和准备开会。”这说明缩短Sprint不是解决颗粒度分化问题的正确手段。

2. 站会的“信息产出”严重退化

我必须要说一个很多人不愿意承认的事实：每日站会在团队协作高度默契、任务依赖关系清晰的情况下，边际信息价值极低。我们团队13个人，站会平均11分钟，每人发言不到1分钟。表面看效率很高，但如果你连续记录一周的站会内容，会发现大量发言属于“信息重复”和“零依赖声明”。

我让Scrum Master做了一个实验：连续10个工作日记录每个成员的发言内容，然后做信息密度评级。结果如下：

47%的发言是纯粹的“我在干活，没人需要知道详情”类型。这些信息如果通过看板工具（比如PingCode的任务状态流转）自动同步，完全不需要占用13个人每天11分钟。而真正有价值的22%阻塞求助，其实更适合在阻塞发生的当时、在对应任务的评论区或群聊里即时解决，而不是等到第二天早上9点15分才说。

很多人会跳出来说“那是你们的站会开得不对，站会应该关注Sprint Goal的进展而不是个人状态”。这句话理论上完全正确，但现实是：当Sprint里同时有7个用户故事在并行推进、且彼此之间依赖关系稀疏时，“围绕Sprint Goal同步进展”在实际操作中会退化成“每个人说一下自己在干嘛”，因为Sprint Goal本身已经不足以统摄所有并行工作的方向。这不是执行问题，这是任务结构导致的信息结构问题。

3. Sprint Review变成了“内部路演”

评审会议的问题不是Scrum的锅，而是组织结构的问题。我们团队的Sprint Review参与者包括：产品团队、开发团队、设计团队、三个不同业务线的运营代表。当利益相关方超过三个时，Review会天然演变成“产品经理向运营代表做功能汇报”的场面。开发最想得到的反馈，代码设计是否合理、技术债是否被接受，根本不会在Review会上出现，因为运营不关心也不懂。

与此同时，真正需要密集协作的人（比如后端开发和前端开发之间关于接口设计的对齐），反而是在Review会后、在工位上用IDE指着屏幕做完的。这就产生了一个黑色幽默：Sprint Review名义上的目的是“检视和调整”，但真正有效的调整发生在会后走廊。当一个会议的主体内容可以被一封邮件或一个录屏替代时，这个会议的时间成本就该被重新评估。

三、Kanban的诱惑，以及多数人没讲清楚的三件事

1. “流动效率”听起来很性感，但落地第一周我们搞砸了

很多人讲Kanban的时候会先讲“限制在制品”、“可视化工作流”、“管理流动”这些金光闪闪的概念。我要先讲我们是怎么搞砸的，因为搞砸的教训比成功经验有价值得多。

切换到Kanban的第一周，我们犯了一个几乎所有新手都会犯的错误：把Scrum Sprint Backlog原封不动地贴到看板的“待办”列，然后把WIP限制设成“一个开发最多同时做两个任务”就以为大功告成。

结果第一周的交付数据惨不忍睹：

• 平均前置时间（从任务进入“开发中”到“已完成”）从Scrum时期的3.2天暴增到5.7天
• 有4个高优先级任务在“测试中”列堆了整整三天没人动
• 两个后端开发同时在做6个任务，每个任务的进度都卡在40%-60%

问题出在哪里？我们只做了“形式上的可视化”，但没有理解Kanban最核心的逻辑：看板不是为了让你看到有多少活儿，而是让你看到瓶颈在哪里。当我们把Scrum的积压直接平移过来时，“待办”列有37个任务，开发列WIP设成6，测试列WIP设成2。瓶颈从一开始就注定会出现在测试列，但我们在设计看板的时候完全没有数据支撑，WIP数全是拍脑袋设的。

这次搞砸让我深刻理解了一个关键点：从Scrum切换到Kanban，不是换一块板子，而是换一套度量体系和决策逻辑。Scrum用“速率”和“燃尽图”来管理，Kanban用“前置时间”、“吞吐量”和“累积流图”来管理。如果你用Scrum的思维去运行Kanban的板子，你会得到两者的缺点而不是优点。

2. “没有Sprint”不等于“没有节奏”

这是我在看业内不少Kanban文章时最不满意的一点。大量内容把Kanban描述成“没有固定迭代、随时可以发布”的自由模式，给人一种从“监狱”来到“大草原”的错觉。这个表述本身就在制造误解。

我们的实际体验是：Kanban不是没有节奏，而是节奏的锚点从“时间盒”转移到了“交付策略”上。你失去的是一个每两周固定触发的“强制心跳”，但你需要自己建立一个新节奏，我们把它称为“交付脉搏”。

具体做法是这样的：在Scrum时期，Sprint是天然的节奏发生器，到了Sprint最后一天，大家本能地知道“该收尾了”、“该演示了”。切换到Kanban后，这个心理锚点消失了。我们在第三周出现了明显的“节奏迷失”：部分开发开始无意识地拖延，因为没有了Sprint截止日期的压迫感，一个任务可以在“开发中”停5天没人觉得有问题。

我们的解决方案是建立三个“节奏锚点”：

• 每日瓶颈站会（15分钟）：不再关注个人状态，只关注“看板上哪列的任务卡了超过24小时”以及“需要谁来解决”
• 每周队列填充会（30分钟）：从Backlog中拉取下一周要开始的需求，做最后一轮优先级确认和依赖梳理
• 每两周服务交付回顾（45分钟）：不再是Demo给外部看，而是团队内部看数据（前置时间分布、阻塞种类、吞吐量趋势），然后只改一件事

这里我想强调一个观点：很多团队从Scrum转Kanban后抱怨“团队变懒了”，问题往往不在Kanban本身，而在于节奏重建的缺失。Scrum的Sprint提供的是“外部强制节奏”，Kanban要求团队建立“内部自律节奏”，后者对团队成熟度的要求其实更高，不是更低。

3. 大多数人以为Kanban不需要估算，但我们试了三种方式后决定保留轻量估算

“Kanban不做估算”是一个流传甚广的误解。严格来说，Kanban不强制要求像Scrum那样对每个用户故事做故事点估算，但这不代表你不需要任何形式的规模判断。

我们在转型后试了三种工作方式：

我们最终保留了第三种方式，理由是：不做长篇大论的规划不等于不做“规模感知”。一个8个点的需求和一个2个点的需求，在队列填充会上应该有完全不同的讨论深度和准入标准。把这个信息完全抹掉，看似简化了流程，实则把决策压力转移到了下游，导致“开发中”列经常被大型需求堵死。

这一点也是我自己在接触大量敏捷团队后形成的一个观点：不建议任何团队在转型初期就把估算全部砍掉，尤其是100人以上的组织里，跨团队协作仍然需要一定程度的规模信息来做承诺对齐。当然，如果你的团队3-5个人、做的是内部工具、没有外部交付压力，那零估算完全可行。但别把这个特例当通行准则。

四、我们是怎么一步步换过去的：一份经得起拷问的过渡流程

很多人只讲“换”的结果，不讲“换”的过程。但过程才是含金量最高的部分，因为过程决定了你会不会在第三周放弃。下面是我们团队使用的五步过渡法，每一步都附带我们踩过的坑和修正方式。

1. 第一步：用数据做转型诊断，不要凭感觉决策

转型之前，我们花了三周时间采集了Scrum模式下的关键数据，作为后续对比的基线。数据维度包括：

• 平均需求前置时间（从需求确认到交付上线）
• Sprint完成率及未完成项的分布
• 各角色每周中断次数（被打断处理紧急需求的频率）
• 任务在“等待测试”、“等待CR”、“等待部署”等阻塞状态的停留时长

这些数据告诉我们一个非常明确的事实：我们团队的主要瓶颈不是开发速度，而是“等待”。一个需求从“开发完成”到“上线验证”的等待时间占了整体前置时间的37%。也就是说，减少等待比提升开发速度的ROI高得多。这个结论直接决定了Kanban是比Scrum更适合我们的方向，因为Kanban的核心管理对象恰恰是“等待”。

如果没有这组基线数据，我们的转型决策就会停留在“感觉Scrum太僵了”这个模糊层面，而模糊的动机是无法支撑转型过程中的反复和阵痛的。

2. 第二步：先并行运行，不要一刀切

我们在正式切换之前，选择了两个低风险的需求类型（内部工具需求和文档类任务）用Kanban方式跑了两周。目的是在不影响核心业务交付的前提下，让团队熟悉看板操作、WIP限制的感受以及“没有Sprint”的心理状态。

这个并行期有一个意外收获：我们发现团队对“可视化阻塞”这件事的敏感度远低于预期。在Scrum里，任务卡住了你会在站会上说一嘴；但在Kanban里，任务卡住的表现是它静静地停在看板的某一列，如果没有人主动去看、去问，它可能停三四天没人注意。

于是我们在并行期加了一条硬规则，后来也带入了正式模式：任何任务在非“待办”列停留超过48小时，由该列负责人在群内主动说明原因和预计解决时间。这条规则看似简单粗暴，但它解决了Kanban最容易被诟病的“缺乏紧迫感”问题。

3. 第三步：工具和看板结构不能照抄模板

我们用的是PingCode，这款工具在Scrum支持上做得非常成熟，切换到Kanban模式也很顺畅。但我想强调的是工具适配，而不是工具功能。

市面上很多Kanban教程会给你一个标准看板列模板：“待办-分析中-开发中-测试中-待发布-已完成”。我们的建议是：看板列的设计必须反映你团队实际的工作流瓶颈点，而不是抄一个通用模板。

以我们团队为例，数据基线显示“等待Code Review”和“等待部署环境”是两个最大的阻塞点，所以我们的看板专门把这两步从“开发中”和“测试中”里拆出来，变成独立的列：

• 就绪
• 开发中
• 待CR（Code Review）
• 测试中
• 待部署验证
• 已完成

拆出来之后效果立竿见影：团队第一次直观看到“待CR”列常态化堆着4-5个任务，而“测试中”列却经常空闲。这直接促成了我们调整CR机制，从“所有代码必须Senior CR”改为“分级CR，常规任务由同级互审”，CR瓶颈从平均18小时降到4小时。

这里我特别想说一句关于工具的情况：PingCode在这个阶段确实帮了大忙，主要是因为它的看板自定义能力和数据面板能力是打通的。我们在自定义列之后，累积流图和前置时间分布自动更新，不需要额外做数据采集。对于100人以上、需要跨组协作的中大型团队来说，工具的数据自动化能力直接决定了你能否坚持跑下去，因为手动统计工作流数据的成本在团队规模变大后会指数级上升。

4. 第四步：WIP限制要基于数据迭代，不能拍脑袋也不该照抄

这是整个转型过程中技术含量最高、也最容易搞错的一步。WIP（在制品）限制是Kanban的灵魂，但“限制设多少”这件事几乎没有靠谱的通用公式。

我们的做法是分三轮调整：

第一轮：初始设定（基于团队人数）

开发列WIP = 开发人数 × 1.5，测试列WIP = 测试人数。结果：开发列经常超限，测试列经常空闲。第一轮失败。

第二轮：基于历史吞吐量反推

统计过去12个Sprint的“每周平均完成任务数”，以此作为WIP上限，用利特尔法则反推。结果：整体WIP偏高，因为历史数据里包含了大量Sprint末期集中完成的任务，不能反映稳态流动能力。

第三轮：动态调参 + 阻塞信号监控

我们不再设固定WIP，而是设一个“基准WIP”和一个“硬上限”，允许在基准和硬上限之间浮动，但一旦达到硬上限就必须触发“阻塞信号”，当天的瓶颈站会优先解决超限列的问题。同时，用PingCode的卡片老化指标来监控哪些任务停在列里超过48小时。第三轮跑了一个月后，团队找到了自己的舒适区。

最终的数据变化：

• 平均前置时间：基线6.4天 → 第三轮后3.1天
• 85分位前置时间（即85%的任务在多久内完成）：基线11.2天 → 第三轮后5.8天
• 每周吞吐量：基线7.3个任务 → 第三轮后8.1个任务（变化不大，但稳定性大幅提升）

这里有一个重要洞察：吞吐量总量提升不大，但前置时间大幅缩短。这说明WIP限制的主要收益不是“做得更多”，而是“做得更快”，同样的产出，更短的交付周期。如果你的团队追求的是“单位时间内完成更多需求”，WIP限制给不了你；但如果你追求的是“每一个需求从提出到上线的周期更短”，WIP就是你最重要的杠杆。

另外，我还要补充一个在PingCode这类工具上操作时的实操建议：把WIP限制直接设在看板列上，不要靠“口头约定”。我们最初靠团队自觉遵守WIP，结果没撑过两天。后来在PingCode的列设置里直接设了硬限制，超过限制无法拖入新任务，这个物理约束比任何公约都有效。别太高估人类的自觉性，尤其是在任务压力大的时候。

5. 第五步：为“恐慌期”和异常情况预留缓冲机制

很多人讲Kanban的优势时会回避一个问题：如果出现紧急线上故障、或者运营要求当天上线一个活动页面，Kanban怎么处理？在Scrum里，你可以说“这是Sprint外的工作”或者“紧急插入但会影响Sprint完成率”，好歹有一个概念框架来处理。但Kanban没有Sprint边界，紧急任务理论上可以直接拖进“开发中”，然后你精心维护的WIP限制和流动数据就会被冲得稀烂。

我们的解决方案是设立一个“紧急通道”，在看板上单独设一列“紧急-快车道”，这一列有独立的WIP限制（设为2），而且遵循特殊规则：

• 进入紧急通道的任务必须由产品负责人和Tech Lead双重确认
• 紧急通道的任务不计入常规列的WIP统计，但单独计算响应时效
• 紧急通道使用率超过15%时触发预警，意味着“紧急需求常态化”，需要从源头解决

这个机制在实际运行中起到了两个作用：一是给紧急需求一个规范化入口而不是让它在流程外野蛮生长；二是通过监控紧急通道使用率反推业务侧的问题，如果一家公司的“紧急需求”占比过高，那问题不在敏捷方法上，在需求管理上。

五、哪些团队不适合从Scrum直接切到Kanban

我写这个话题不是为了给Kanban泼冷水，恰恰相反，我希望更多人用对Kanban。但过去半年里我和不少同行交流，发现有些团队在转型后三个月又退回了Scrum，理由五花八门。我把这些案例梳理了一下，归纳出三类不适合直接切换的情况。如果你所在团队符合以下特征，请三思。

1. 刚组建不到半年的新团队

新团队的特征是角色关系未定型、协作模式不稳定、每个人对“完成”的理解还存在偏差。在这种阶段，Scrum的固定时间盒和明确的角色定义反而是一种保护。Daily Standup对于新团队来说不是信息同步，而是建立“我们是一支团队”的身份认同，这一点在Kanban模式下很难替代。

我见过一支2024年初组建的7人团队，跳过Scrum直接上Kanban，三个月后问题爆发：两个后端开发各自为政，因为没有Sprint Goal的统合，两个人做的接口风格都不一样，前端对接的时候才发现。如果有Scrum的Sprint规划和Sprint Goal，这种问题在规划会上就可能暴露。我的建议很直接：先做好Scrum，做到团队对“协作的基本契约”没有歧义的时候，再考虑要不要切Kanban。

2. 高度依赖外部交付、且外部团队仍在用瀑布模式的遗留系统团队

这类团队的典型场景是：自己团队用敏捷方法做应用层开发，但底层服务或数据接口由一个外包团队或内部遗留系统团队提供，对方按月度排期、变更需要提前走审批。

在这种情况下，你自己切换到Kanban的灵活交付能力会被外部依赖的刚性约束死死卡住。你内部一个需求2天可以开发完，但API接口要等20天，你2天做完之后任务就只能停在“阻塞”状态干等着。Kanban可视化出来的将是一张触目惊心的“等待地狱图”，但你没有权力去改外部团队的流程。这种情况下，Scrum的固定Sprint节奏反而能让你和外部依赖的月度排期对齐，减少团队的心理内耗。

3. 团队信任度低、内部问责文化严重的组织

这条可能有点得罪人，但我必须说：Kanban对团队自组织和信任度的要求比Scrum更高，而不是更低。Scrum好歹有Scrum Master承担过程守护的职责，有Sprint Retrospective这个定期“算账”的机制，管理层的安全感相对容易建立。在Kanban里，如果你没有一个成熟的回顾机制和开放的团队文化，“减少会议”会被理解成“没人管了”，“可视化阻塞”会被理解成“公开处刑”。

我在一个朋友的团队看到过真实案例：他们的技术总监把Kanban看板当成“监控大屏”，每天盯着“开发中”列超过3天的任务在群里点名。结果开发学会了把大任务拆成十几个小任务，这样每个任务都不超过2天，看板数据漂漂亮亮，但实际交付速度毫无改善。这是典型的“度量被博弈”现象，根源不在Kanban，而在管理层对团队缺乏信任。如果你的组织文化还停留在“用数据管控人”的阶段，先改善文化再换方法，顺序不能反。

六、角色变成了什么：Scrum Master去哪里了

从Scrum到Kanban，角色是一个敏感话题。Scrum的三角色结构（Product Owner、Scrum Master、Development Team）清晰到几乎可以写在名片上。切换到Kanban后，没有明文规定这些角色是否保留、如何调整。我们团队经历了三个月的摸索，形成了现在的角色分工，我觉得有参考价值。

1. Scrum Master变成流动效率教练

我们团队的Scrum Master在转型后没有离开，也没有变成闲职。他的角色从“确保团队在按Scrum做”转变为“确保团队在持续改善流动效率”。具体工作内容变了：

• 不再主持每日站会（瓶颈站会由轮值成员主持），而是每周做一次累积流图和前置时间数据分析，产出一份“流动健康简报”
• 不再维护Sprint Backlog，而是维护WIP限制的合理性，根据数据变化建议调整
• 不再组织Sprint Review，而是组织每两周一次的服务交付回顾，聚焦“这周哪类阻塞反复出现”

最关键的变化是：他的工作对象从“人”变成了“数据和流程”。不再需要提醒开发更新任务状态（PingCode的状态自动流转解决了这个），不再需要维护燃尽图（累积流图自动生成），精力被释放到更高价值的事情上，分析阻碍流动的系统性原因而不是盯着个人。

这对Scrum Master的个人能力也提出了不同的要求：在Scrum里，一个好的Scrum Master需要很强的教练能力；在Kanban里，一个好的流动效率教练需要较强的数据分析和系统思维能力。不是所有Scrum Master都能顺利切换，这取决于个人能力结构。我见过一些Scrum Master在转型后感到失落，因为“不再被需要”的感觉很强烈。如果你是Scrum Master，正在考虑推动团队切换，也请评估一下自己是否愿意和有能力做这个角色转变。

2. Product Owner保持角色，但工作节奏变了

PO没有被取消，但工作方式从“批次供给”变成了“连续供给”。Scrum要求PO在Sprint规划会前准备好一个排好序的Product Backlog，这本质上是批次模式，两周准备一次、一次性交付一批需求给开发团队。

切换到Kanban后，PO的工作变成了持续维护一个“就绪就拉”的需求池。需求的排序不再等Sprint规划会，而是随时根据业务反馈调整。这对PO的需求管理能力要求更高了，因为没有Sprint这个“硬承诺容器”，PO必须自己掌握拉取节奏：拉太快，下游堆积，前置时间恶化；拉太慢，开发空闲，吞吐量浪费。我们团队的PO在转型的第一个月出现了明显的焦虑，因为他失去了Scrum Sprint这个“确定性边界”。后来通过每周的队列填充会逐渐建立新的节奏感。

3. 开发团队的角色边界模糊化

这是转型中最微妙的变化。在Scrum里，虽然宣导“跨职能团队”，但实际上前端、后端、测试的角色边界依然清晰。切换到Kanban后，因为关注的是流动效率而非Sprint完成率，处于等待状态的人会更自然地伸手去帮上游或下游。

举一个具体例子：在Scrum时期，如果测试人员的任务都在“测试中”列，前端开发通常不会主动去做测试（哪怕有能力做），因为“我的Sprint任务还没做完”。在Kanban里，当测试列堆积超过WIP限制时，看板本身就是最强有力的信号，前端会主动去看测试列有哪些任务可以帮忙。这不是因为前端变勤快了，而是因为机制设计把“测试堵了，所以大家都会受影响”这个因果关系可视化了出来。

半年下来，我们团队出现了自然的多技能成长，两个前端开发开始写自动化测试脚本，一个后端开发开始处理简单的前端样式调整。不是管理者要求他们学的，是流程的自然激励。

七、数据说话：转型半年的量化变化

我答应过这篇文章要有数据。以下是转型半年后，与Scrum最后三个月基线数据的对比。所有数据来源于PingCode的项目数据面板和我们自己的监控工具（部分脱敏处理）。

1. 流动效率指标

流程效率从41%提升到68%是我们最满意的变化。简单解释一下：一个需求从提出来到上线的总周期时间里，只有41%是真正在“被处理”（开发、测试、部署），其余59%是各种等待（等人审核、等环境、等排期）。Kanban通过限制WIP和可视化瓶颈，把这些等待时间挤出了系统。68%意味着实现三天的需求从提出来到上线不到五天，这对于运营侧的增长实验来说基本够用了。

2. 团队体验指标

“被打断感”下降了但依然有4.8分，说明Kanban没有完全解决中断问题，但确实改善了。主要残留的中断来源来自外部团队的需求变更和线上问题，这不是工作方法能解决的。

“对交付节奏的控制感”从5.1跳到7.9，是我们没想到的意外收益。在Scrum里，Sprint的计划性和可预测性理论上应该让人更有控制感，但实际上因为Sprint末期频繁赶工和Scope谈判，很多人感觉“被Sprint推着走”。Kanban里虽然没了固定计划，但每个人都清楚自己手上的任务和看板上游的积压情况，反而更有掌控感。这个发现与很多敏捷教科书的说法相反，也可能是我们团队的特殊情况，但值得记录下来。

3. 一个非预期发现：缺陷逃逸率轻微上升

转型后第三个月，我们注意到一个不太好的信号：缺陷逃逸率（上线后发现的有效缺陷数/总测试用例数）从Scrum时期的2.1%上升到了3.4%。经过排查，原因指向一个细节：在Scrum里，Sprint末期有一个“全员压测”的非正式环节，开发和测试一起把即将发布的功能从头过一遍。切换到Kanban后，功能单独上线，这个“全员集中测试”的习惯消失了，导致一些集成场景的缺陷溜到了线上。

我们的解决方案是：在“待部署验证”列里加了一个子检查项，“是否涉及跨模块交互？如果是，需经集成测试套件跑一遍”。同时在PingCode里把这条检查项设为该列任务的必填字段。三个月后逃逸率降回2.0%。

这个案例说明了一个我越来越坚信的道理：方法切换不是“废除旧流程、启用新流程”，而是“识别旧流程中哪些有效实践被无意识地放弃了，然后用新方法的框架重新安置它们”。别因为讨厌Scrum就否定它的一切，也别因为推崇Kanban就假设它天然完善。

八、如果你决定要换，我给你的行动清单

前面讲了七千多字，如果你已经看到这里，大概是真的在考虑或者已经在做这个转型。以下是我的行动建议清单，按优先级排序，每一项都基于我真实踩过的坑。

1. 转型前必做的三件事

• 采集至少一个月的基线数据：前置时间、吞吐量、各列等待时间是底线。没有基线，你永远无法判断转型是否成功，也无力应对“换了之后反而更慢”的质疑。
• 做一次全员“痛点匿名投票”：让大家写出当前Scrum实践中最让人痛苦的三个点，排名前三的痛点就是你的转型优先级。如果痛点主要集中在“Sprint太短”、“会议太多”，Kanban可能是解法；如果痛点集中在“需求不清”、“验收标准模糊”，那换什么方法都没用。
• 和业务方做一次正式沟通：告诉他们“我们要换工作方法，交付节奏会从固定两周变成按需持续交付，短期内可能出现波动”。管理好利益相关方的预期是转型成功的一半。我见过太多转型死在第三周，不是因为团队不行，而是因为业务方在第三周开始抱怨“为什么这周没看到Sprint Review的Demo”。

2. 转型中容易踩的五个坑及规避方式

• 坑1：WIP设太高，建议从“开发人数×1”开始设，跑两周看数据再调。宁低勿高。
• 坑2：放弃所有会议，Kanban不是不开会，而是开不同的会。至少要保留瓶颈站会和定期回顾。
• 坑3：没有阻塞升级机制，任务卡了超过48小时没有自动通知机制的话，一定会被遗忘。工具层面解决（PingCode的卡片老化提醒可以设），流程层面也要明确。
• 坑4：产品经理不适应连续供给模式，给PO额外的支持，前两周让他只负责维护“就绪”列的排序和准入标准。这是角色切换中最难的一环。
• 坑5：拿累积流图当摆设，累积流图是Kanban最核心的数据工具，如果你只看图不调流程，还不如不看。每月至少基于数据做一次WIP或列结构调整。

3. 判断转型是否成功的“非指标信号”

数据以外，还有一些定性信号值得关注：

• 团队成员开始自发讨论“为什么这个任务在CR列停了6个小时”而不是讨论“这周Sprint完得成吗”
• 紧急需求的“紧急”定义变严格了，运营不再随便标“紧急”，因为他们发现标了也不会插队，而是走快车道有既定流程
• 有人开始做非本职的技术工作，并且不觉得是在“帮忙”，而觉得是“让整体流动更顺畅”

这三个信号如果出现了，说明团队已经把Kanban从“流程”内化成了“思维模式”，这才是真正的转型完成。

九、我不建议你转Kanban的三种情况

虽然整篇文章都在讲怎么换，但在结尾我想非常明确地列出三种情况，你不应该换，或者说换了一定会后悔。

1. 你的团队Scrum还没跑通

如果你还在纠结“站会超15分钟怎么办”、“Review会没人说话怎么办”、“PO不写验收标准怎么办”，这说明你的问题不在方法论选择上，而在基础实践执行上。把Scrum基础打扎实，跑道堵了再换跑道，而不是跑道还没铺平就换另一条。Kanban不会替你解决Scrum能力不足的问题。

2. 你的管理层把“换方法”当“提效率”的捷径

如果领导认为“换了Kanban就能加快交付速度”，那换之前必须把期望管理做到位。我在前文的数据很清楚地显示了：吞吐量只提升了16%，但前置时间缩短了56%。Kanban的核心收益是“快”而不是“多”。如果你的领导追求的是“同样的时间内交付更多功能”，你应该改善工程能力（自动化测试、CI/CD优化、代码质量提升）而不是换工作方法。

3. 你只是对Scrum“审美疲劳”了

这个理由听起来不严肃，但它真实存在。做了两年的Scrum，大家对Sprint、站会、Review产生了疲倦感，这时候“换Kanban”更像是一种心理上的新鲜感需求。如果这是你真实的原因，请诚实地面对它，然后换一种成本更低的方式解决，比如换个工具、换个Sprint长度、或者让团队轮流主持回顾会议。别用一场伤筋动骨的转型来解决一个“有点腻了”的问题。

十、写在最后：别追求“最好的方法”，追求“此时此地最合适的选择”

做敏捷这些年，我见过太多关于“Scrum好还是Kanban好”的无意义辩论。Scrum和Kanban都是工具，工具的价值由使用场景决定，不由工具本身决定。一把手术刀和一把菜刀没有谁比谁更好，看你是在手术室还是在厨房。

我们团队换到Kanban，不是因为Kanban更好，而是因为我们团队的业务特征、人员成熟度和瓶颈类型在2024年已经与2021年完全不同。同样，三年后我们可能会再调整，可能是Scrumban，也可能是完全自创的混合模式。别把自己的团队锁死在一个标签里。

如果你读完这篇文章觉得“想试试了”，我的最后一个建议是：别一次性全切。找一个低风险的子项目或者一个子团队先跑一个月，用数据验证你的判断。一个月后，如果你下班前不用再为“明天Sprint Review的Demo东西够不够”而焦虑，如果你发现已经有两周没人在晚上10点以后提交代码，那就继续跑下去。如果一个月后发现团队更乱了，你就收获了一条宝贵的经验：Kanban也不适合当时的你们。这条经验本身值回所有折腾成本。

方法有更新，但判断原则永远只有一条：你的团队是否在持续改进？只要你对这个问题的答案是“是”，Scrum还是Kanban已经不那么重要了。