从瀑布到敏捷，我们踩了大坑

一、我们衡量敏捷转型成败的尺度，一开始就错了

2021 年年底，我刚接手一个 130 人规模的研发中心，CTO 在会议室里拍桌子：“三个月，所有人切换到 Scrum。”人力资源总监跟着补了一句：“我已经买好了 CSPO 认证课程，所有人必须参加。”

三个月后，站会开得整整齐齐，Sprint 周期卡得稳稳当当，Jira 面板上燃尽图美得像教科书。但产品副总裁说了一句让我记到现在的话：“怎么敏捷了三个月，交付速度反而慢了？”我翻开数据一看：上线周期从瀑布时期的 4 周，变成了 6 周。缺陷逃逸率从 12% 升到 18%。最关键的是，那天下午我旁听了三场站会，意识到一个扎心的事实，我们根本没有在做敏捷，我们只是把瀑布装进了敏捷的壳子里。

后来我花了两年，在不同规模的组织里反复验证一个结论：大多数团队从瀑布转向敏捷，踩的不是技术坑，不是流程坑，而是“度量尺度的错位”。瀑布那套成功标准，需求文档签字率、里程碑准时度、变更控制板上的驳回次数，被悄无声息地平移到了敏捷环境里。团队以为自己失败了，管理层觉得敏捷是骗局。实际上，是所有人拿着一把错误的尺子，在量一块完全不同布料的衣服。

二、核心结论：大多数敏捷转型失败，不是因为团队不行，而是因为控制欲没有被妥善安置

在讲具体踩坑经历之前，我想先把结论摆出来。这个结论不是从书上看来的，是我在 4 个不同行业、不同规模的技术组织里反复观察、对比、纠正之后沉淀下来的判断。

瀑布模型的本质，是一套“预判性控制”体系，所有风险必须在需求阶段被识别、评估、签字画押。PRD 写到 60 页，是因为写文档的人害怕遗漏。变更控制委员会每周开一次，是因为管理层害怕失控。这种恐惧在瀑布时代被制度化地安抚了：签字意味着“这根绳子我拉过了，后面出事不是我的责任”。

敏捷模型颠覆的恰恰是这套安抚机制。它要求你接受“我不知道全部需求”这件事，然后通过短周期反馈来逐渐逼近正确答案。这在一个习惯了确定性承诺的组织里，会引发系统性的焦虑。产品经理焦虑“需求不写完怎么排期”，开发工程师焦虑“中途改需求谁来买单”，测试工程师焦虑“用例没冻结怎么测”。

我看到的失败案例里，没有一个是因为 Scrum 流程本身有问题。所有的坑都指向同一个根源：组织试图用敏捷的流程，继续满足瀑布时代的控制需求。于是 15 分钟的站会变成了 40 分钟的汇报会，Sprint 计划会变成了需求签字会，回顾会变成了绩效考核前置环节。

后面我拆解的所有具体坑，都是从这个根源长出来的分支。

三、真实场景还原：当 130 人团队同时“被敏捷”

回到开头那个场景。我需要还原当时的组织背景，因为这个背景决定了后面所有坑的形态。你没有这种背景，踩的坑可能完全不同，这也是为什么市面上很多敏捷转型文章你看完之后觉得“说得都对，但跟我的情况对不上”。

1. 团队结构的既有惯性

这个 130 人团队不是互联网原生组织。它是从一个给政企客户做定制化系统的软件公司演化过来的。团队结构是典型的 职能筒仓型：产品部 15 人，开发一部和二部共 80 人，测试部 25 人，运维 10 人。每个部门有自己的考核指标。产品部考核的是“需求文档完整度”和“客户签字率”，开发部考核的是“按期交付率”，测试部考核的是“缺陷发现数”和“回归通过率”。

这种考核体系在瀑布模式下运转了六年，非常丝滑。因为瀑布本身就是一个“交付物串联”的逻辑：你的输出是我的输入，你签完字我接手，责任边界清清楚楚。

宣布敏捷转型的那一刻，没有任何人想过要改考核体系。这一点我也是后来复盘时才意识到的，当你让一群按“个人责任”被考核的人，去做一件需要“集体担责”的事，结果一定是每个人都在保护自己的那一小块领地。

2. 客户合同的硬约束

另一个背景条件非常关键，但大多数敏捷培训课程不会告诉你：这个团队的客户合同是固定总价合同。政府客户签的是“交付 XX 系统，总价 XX 万，分三期里程碑验收”。每一个里程碑都绑定了明确的功能清单，验收标准写了 30 页。

这意味着什么？意味着我们的“Product Owner”实际上没有权力调整范围。范围已经在合同里锁死了。Scrum 理论里讲的“Product Owner 有权根据业务价值动态调整优先级”，在这里根本不成立。你能调的只有交付顺序，不能砍需求，也不能加需求。这导致 Sprint 计划会变成了一个奇怪的样子，需求已经全部排好了，我们围在一起假装“估算故事点”，实际上每个人都知道这些东西一个都不会少。

这个背景跟很多 B2B 软件公司和项目型公司的实际情况高度吻合。如果你在这种公司做敏捷转型，却完全照搬互联网产品型公司的 Scrum 实践，第一步就踩空了。

3. 中层管理者的隐形抵抗

这个坑是我踩得最疼的。技术总监、测试经理、产品总监，这三个人表面上非常配合敏捷转型。他们参加了培训，自己掏钱买了《Scrum 精髓》，开会的时候嘴里挂着“自组织团队”“仆人式领导”。

但三个月后我发现，产品总监依然在私下让产品经理把 PRD 写到 80% 完成度才准进 Sprint；测试经理依然要求测试团队在每个 Sprint 的第一天提交“测试计划文档”并签字；技术总监在 Sprint 进行中直接给开发组长打电话：“那个接口你先别管用户故事了，客户下周要验收，优先级最高。”

中层管理者是任何敏捷转型中最容易被忽视的堵点。他们不是坏，也不是顽固，而是敏捷直接威胁了他们在瀑布体系中的权力基础。过去他们的价值体现在“审批”“把关”“协调”，现在这些动作在敏捷框架里被视为浪费和瓶颈。你不能指望一个被要求放弃核心职责的人真心拥抱变革，除非你给他一个新的、同样重要的职责。

四、拆解五大常见误区：这些坑我们一个一个趟过

1. 误区一：认为站会是“汇报”，不是“对齐”

我们第一个 Sprint 的站会开了 45 分钟。不是因为讨论得热烈，而是因为每个人都对着自己的 Jira 任务条，说“昨天做了什么，今天要做什么”。SM（Scrum Master）在旁边拿着本子记，记完之后还追问：“这个需求什么时候能测完？”，SM 不知不觉变成了项目经理。

这种站会有三个特征，你可以对照一下自己的团队：

第一，每个人只对着 SM 说话，不是对着团队。眼神方向暴露了心态，这是汇报，不是同步。

第二，没有人主动说出阻塞。因为过去在瀑布文化里，“遇到问题”等于“可能延期”，“延期”等于“绩效扣分”。大家宁可会后私下找人帮忙，也不愿意在站会上暴露自己卡住了。

第三，SM 在记笔记。站会的核心产出不是会议纪要，而是“我接下来要去找谁聊什么”。如果 SM 一直低头记，说明他在试图把信息汇总成一份可追踪的文档，这是瀑布思维的残留。

我们后来做了一个硬性规定：站会上不允许任何人拿笔记本，不允许投屏 Jira，每个人最多说 90 秒，说完就走。刚开始团队非常不适应，沉默时间变多了。但两周之后，出了问题的人开始主动说“我卡在 XX 接口的依赖上”，因为不说出来，没有人知道他卡住了，而“15 分钟站会无记录”这个机制，让暴露问题不再有惩罚性后果。

2. 误区二：用 Sprint 计划会替代了需求评审

我们在转型初期做了一个看似“高效”的决定：取消原有的需求评审流程，需求直接进入 Sprint 计划会讨论。结果第一个 Sprint 的交付质量崩得一塌糊涂。测试团队在 Sprint 的第三天发现 60% 的用户故事根本没有验收标准，开发写出来的功能跟产品经理想的完全是两回事。

根源在于，瀑布时代的需求评审承担了“共识构建”的功能，所有人坐在一起，对着 PRD 过每一行，提出疑问，达成一致。这个共识构建的时间成本大约是每个需求 2 到 4 个小时。Sprint 计划会的时间窗口根本承载不了这么大的信息交换量，结果就是产品经理在计划会上快速念了一遍故事标题，开发凭经验和猜测去写代码。

我们的纠正措施不是回到 PRD 的老路，而是引入“需求梳理会”作为 Sprint 计划会的前置环节。在 Sprint 开始前 3 天，PO 先带着一组已经粗略拆解的用户故事跟开发、测试的核心成员过一遍。这个梳理会不承诺范围，不做估算，只做一件事：确保所有人对“要做什么”有一致的理解。Sprint 计划会只做最终的范围确认和任务拆分。

3. 误区三：把故事点当成工时，把燃尽图当成考核工具

这个坑直接导致了开发团队的集体抵触。我们当时的项目管理部有一个 Excel 报表，每周自动抓取 Jira 数据，算出每个开发人员的“故事点完成数”，然后在周报里排名。

两周之后，开发人员开始做两件事：第一，给每个任务往高了估算故事点；第二，挑简单但故事点多的任务做，复杂的、探索性的任务没人认领。

故事点是一个相对估算工具，它的基本逻辑是“这个功能相对于那个功能，大约是 2 倍的工作量”。它只有在团队内部保持一致性时才有意义。一旦变成跨人的比较指标，它就会像所有被衡量的东西一样，被博弈、被膨胀、失去意义。

燃尽图的问题类似。我们有一个项目经理每天盯着燃尽图，看到燃尽线高于理想线，就在群里发截图催促。团队的反应是：把已经接近于完成但未验收的任务标记为“完成”，燃尽线立刻漂亮了，但交付质量一塌糊涂。

燃尽图是一个“发现问题的信号”，不是一个“追责的依据”。当燃尽线偏离理想线时，正确的反应是问“发生了什么，需要我帮什么忙”，而不是“为什么还没做完”。这个区别，决定了一个敏捷教练到底是建设者还是破坏者。

4. 误区四：回顾会变成了“免责大会”

我参加过的最糟糕的 Sprint 回顾会，开了 2 个小时，产出是三条改进项：

• “需求应该在 Sprint 开始前写得更清楚”，产品经理记一条
• “开发应该更仔细地看验收标准”，开发组长记一条
• “测试用例应该在 Sprint 第一天写完”，测试经理记一条

这些话翻译过来就是：“问题在你，不在我。”《敏捷回顾》那本书里讲过一个核心原则：回顾会的焦点应该是“系统和流程”，不是“个人”。但大多数团队天然倾向于找一个人来负责，因为归因于系统太抽象，归因于个人最简单。

我们后来引入了一个根本性的改变：回顾会不讨论“谁做错了什么”，只讨论“什么流程导致了这个问题”和“我们怎么改这个流程”。同时引入了 “改进看板”，每次回顾会产出的改进项，必须是一条可执行的动作，指定一个负责人，进入下一个 Sprint 的回顾跟踪。如果一个改进项在连续三个 Sprint 的回顾中都没有被执行，我们就不讨论新问题，只复盘为什么这个改进推不下去。这个机制把回顾会从“倾诉现场”变成了“行动引擎”。

5. 误区五：把 Scrum Master 当成项目经理用

转型初期，我们直接把原来 3 个项目经理改了个名字叫 Scrum Master。这些人过去做的是：分配任务、盯进度、协调资源、汇报状态。现在名字变了，做的事一模一样。更糟的是，团队也习惯了这种模式，遇到任何障碍第一反应不是自己解决，而是“找 SM 协调一下”。

SM 的核心职责是“让团队学会自己解决问题”，不是“替团队解决问题”。一个合格的 SM 在站会上听到“我被外部依赖卡住了”时，不应该说“我去帮你催一下”，而应该说“你有没有直接联系过对方的接口人？如果没有，为什么？你现在可以在这里承诺会后 30 分钟内去联系，明天站会上我们同步结果。”

两者区别巨大。前者强化依赖，后者培养自组织能力。我们在第 4 个 Sprint 换掉了全部 3 位 SM，从开发团队内部选了 3 个有意愿、有影响力但不是管理岗的资深工程师来担任。这 3 个人因为本身就在写代码，能深刻理解团队的痛，又没有管理包袱，效果远超前任。

五、专业判断逻辑：不同组织类型下，敏捷转型的可行路径完全不同

我在过去几年里接触过不同类型的敏捷转型案例，用 PingCode 服务过超过 200 家中大型技术组织之后，我逐渐形成了一套判断框架。不是所有团队都适合一步到位切 Scrum，也不是所有团队都需要保留瀑布元素。关键变量有三个：需求不确定性、交付节奏要求、合同约束类型。

1. 判断矩阵：四类组织的四种路径

我把团队分成四种类型，每一类适用的敏捷策略差异很大：

这个矩阵的要点在于：你的合同结构决定了你的敏捷自由度。如果你签的是固定总价固定范围合同，就别指望 Product Owner 能动态调整优先级。你能做的最大程度敏捷，是在每个里程碑内部用迭代方式开发，让客户在里程碑内看到可运行的中间版本，提前暴露理解和实现上的偏差。这就是“大瀑布套小敏捷”的真实含义，不是妥协，是在约束条件下找最优解。

2. PingCode 在政企客户中的实践观察

我最早接触 PingCode 是在一家央企下属的科技子公司，他们 150 人的研发团队正在从外包管理模式向自有产品研发转型。他们的场景非常典型：上层有集团下达的年度信息化建设指标，项目必须在年底前通过验收；但具体模块的需求在年初根本不可能写清楚。

他们用 PingCode 搭建了一个分层需求管理结构：史诗（Epic）对应年度建设任务，特性（Feature）对应季度里程碑，用户故事对应每个 Sprint 的交付项。史诗和特性层的范围相对稳定，满足向上汇报和合同管理的需要；用户故事层允许在每个 Sprint 内根据开发过程中发现的问题进行调整。

这个架构解决了一个关键矛盾：管理层需要确定性的承诺，团队需要灵活性的空间。管理层的确定性由史诗和特性层保障，团队的空间由用户故事和任务层释放。两层之间通过 PingCode 的关联追踪能力互相映射，任何一个用户故事的变化都能追溯到它影响了哪个特性，进而评估对里程碑的影响，而不是简单地禁止变化。

他们实施 6 个月后的数据变化值得注意：

• 需求变更的响应速度从平均 8 个工作日缩短到 3 个工作日
• 里程碑准时交付率从 72% 提升到 88%
• 但最重要的是，团队主动提出的需求优化建议从每月 2 条上升到 15 条，说明团队从“被动执行”转向了“主动思考”

这个数据不是工具带来的，是架构设计带来的。工具只是让这个架构可以被追踪、被可视化。

六、不同阶段的行动路线：别一上来就“全员敏捷”

基于前面所有踩坑经验，我现在给任何组织的建议都是：敏捷转型分三步走，每一步有明确的可验证目标，达到目标再进下一步。不要一上来就喊“两个月全面切换 Scrum”，这是我在那 130 人团队里犯过的最贵的错误。

1. 第一阶段：建立“可视化”基础（1-2 个月）

目标：让工作流可见。这个阶段不要引入 Scrum 的任何流程和角色。只做一件事：把团队当前正在做的所有事情，放到一个可视化看板上。用 PingCode 的看板视图，或者物理白板贴便签都行。

这个阶段的关键衡量指标：

• 看板上 WIP（在制品）数量是否逐渐收敛到一个合理范围内
• 团队是否开始自发地移动任务卡片
• 管理者是否开始基于看板提问，而不是基于 Excel 周报提问

这个阶段最容易犯的错误：一上来就在看板上加“预计完成日期”“计划工时”“责任人”这些瀑布字段，把看板变成了一个可视化的大号甘特图。看板的第一个用途是暴露流程的阻塞，不是追踪个人效率。

2. 第二阶段：引入“时间盒”和“站会”（第 3-4 个月）

目标：让节奏稳定。在可视化跑通了 4-6 周之后，引入固定长度的迭代周期（建议从 2 周开始，不要一上来就 1 周或 4 周），以及每日站会。

这个阶段的衡量指标：

• 是否在 3 个迭代内找到了相对稳定的迭代速率（每个迭代平均完成的故事点数趋于一个区间）
• 站会是否在 15 分钟内结束
• 迭代结束时是否有未完成的在制品被客观记录（而不是被悄悄挪到下一个迭代，假装是新任务）

这个阶段最容易犯的错误是在迭代速率还不稳定的时候就引入绩效考核式燃尽图监控。迭代速率需要至少 3 到 4 个迭代的数据积累才能形成参考价值。

3. 第三阶段：引入回顾和持续改进（第 5 个月起）

目标：让改进机制自运转。前两个阶段扎实了，再引入 Sprint 回顾会、改进看板、以及更正式的需求梳理机制。

这个阶段的衡量标准从“产出了多少改进项”变为“改进项执行率”，过去三个迭代中，回顾会产出的改进项实际完成的比例。如果低于 50%，说明团队的改进机制尚未生效，需要放缓节奏，先解决为什么改不了的问题。

七、什么时候该坚持敏捷，什么时候该承认“混合模式”才是正解

写到这里，我想做一个关键的取舍判断。市面上的敏捷布道者喜欢传递一个信息：只要坚持，总能纯正。我在现实中看到的真相是：某些组织架构和合同结构下，完全 Scrum 不仅不可行，而且不应该被追求。

坚持纯 Scrum 的前提条件有三个：

• 合同结构允许范围动态调整（或根本没有外部合同，自研产品）
• 客户或业务方愿意且有能力每个 Sprint 参与评审（否则 Sprint 评审变成了内部自嗨，反馈闭环断裂）
• 组织愿意调整考核体系（从考核个人的“完成率”转向考核团队的“价值交付”）

如果这三个条件一个都不满足，我给你的建议是：不要做 Scrum，做 Kanban。Kanban 不要求时间盒，不要求角色变更，核心只做一件事，限制在制品数量，让工作流动起来。文化改变是渐进的，不是通过角色重新定义和流程切换达成的。很多组织在 Kanban 上跑了一年之后，团队自己会提出“我们是不是应该试试固定节奏的迭代”，这时候再转 Scrum，阻力会小得多。

如果三个条件满足了一到两个，可以做“大瀑布下的小敏捷”：宏观层面的里程碑、预算、合同范围按瀑布管理；微观层面每个里程碑内部按 Scrum 迭代开发。这种模式在 PingCode 服务的多数 B2B 客户中是主流实践。

真正的专业判断，不是告诉你“敏捷一定比瀑布好”，而是能精准识别你的约束条件，给出适配的策略。

八、写在最后：敏捷不是信任流程，是信任人

回到开篇那个 130 人团队的后续。我们在第 6 个月做了一个关键决定：承认自己不适合一步到位的 Scrum，退回到“里程碑锁定范围 + 迭代内敏捷开发”的混合模式。承认这件事的那一刻，会议上所有人都松了口气，不是失败的松气，是终于不用再假装自己能做一件做不到的事的释然。

第 12 个月，我们在混合模式下交付了当年最大的政企项目，客户在验收会上说了一句我没想到的话：“这是第一次，我们在每个里程碑的中间节点就能看到可运行的系统。”这不是敏捷的胜利，是“找到适配模式”的胜利。

我个人现在判断一个组织是否真正在践行敏捷，不看它用什么框架、开什么会、用什么工具。我看一个指标：当团队成员发现一个需求不合理时，他能不能在 Sprint 中途提出来，并被认真讨论，而不是被驳回或被要求“先按 PRD 做完再说”。如果这个动作在你们团队里是顺畅的、无惩罚性的、被鼓励的，那就是敏捷。不管你用的是 Scrum 还是 Kanban 还是混合模式。

如果你的团队刚踏上这条路，或者已经踩了一堆坑，我建议你现在做一件事：停下来，先想清楚你们的约束条件是什么，然后带着这篇文章里的判断框架，开一个只谈约束不谈解决方案的会。把合同结构、考核体系、客户参与意愿这三件事摆在台面上，让所有人对现实达成共识。共识之后，策略会自己浮现。工具和流程只是执行层的事。用 PingCode 也好，用 Jira 也好，用物理白板也好，那都是后话。先看清自己站在哪块地皮上，再决定盖什么房子。