用瀑布开发带新人，反而比敏捷更友好

一、先把结论说清楚：带新人，瀑布是“教学工具”，敏捷是“筛选工具”

我带过 11 个新人，5 个在敏捷团队，6 个在瀑布团队。两年后回头看，瀑布团队留下来的 6 个人，有 4 个成了骨干；敏捷团队留下来的 2 个人，虽然也成长起来了，但过程远比我想象中更痛苦。而且那 5 个敏捷新人里，有 2 个在前 6 个月就离职了，离职面谈时说的理由很一致：“感觉一直跟不上，不知道自己在干什么。”

这组数据不是从哪个报告中抄来的，是我自己团队的真实记录。样本不大，但它足够让我开始认真思考一个问题：敏捷开发真的适合带新人吗？

我的结论是：在带新人这件事上，瀑布提供的“结构化引导力”远胜于敏捷的“自适应期待”。敏捷是在用“做项目”的方式筛选出能力强的新人，而瀑布是用“教人”的方式让普通新人也能稳步成长。

不是说敏捷不好。敏捷在应对不确定需求、快速交付产品上的优势我完全认可。但“带新人”和“做项目”是两个不同的管理目标。把做项目的逻辑套到带人上，就像用赛车标准去教人开车，少数天赋型选手能活下来，大部分人会被劝退。

接下来我会用我的实战经验、具体案例、以及可落地的操作方法，把这个观点掰开揉碎了讲清楚。

二、一个真实的失败场景：敏捷流水线上“掉队”的新人

1. 看上去很美，干起来很懵

2021 年我管一个敏捷开发团队，Sprint 两周一次迭代，站会、评审、回顾一应俱全。公司新招了一个 985 计算机本科的校招生，基础不错，面试时表现也很好。我给他配了导师，把他放进了一个 7 人敏捷小组。

第一天，导师给了他一个用户故事：“作为平台用户，我希望能够按日期筛选我的订单记录。” 看上去很简单，对吧？用户故事的写法也符合 INVEST 原则，Backlog 里也标注了优先级和故事点估算。

但问题来了：这个需求背后的业务逻辑，新人完全不知道。

他不知道“订单”在系统中是怎么存储的，不知道“日期筛选”涉及哪些字段，不知道已有的订单查询接口在哪里，不知道前端的订单列表组件是怎么渲染的。而用户故事里，这些都不会写。

导师说：“你先看看代码仓库里类似的实现，然后自己摸索一下，有问题随时问我。”

这个“随时问我”很有问题。因为你一旦说了“随时问”，新人反而不敢随时问了。他怕打扰你，怕显得自己基础差。他自己在电脑前闷头搞了三天，写出了 300 多行代码，然后提交 Code Review 时被打了回来，几乎每一行都要改。

这个新人入职第一周的体验是：我不知道我要干什么、我干出来的全是错的、我不敢问、但我好像又必须搞出来，因为 Sprint 不等人。

2. Sprint 的压力大于教学的动力

敏捷的 Sprint 是有时间盒的。两周结束，你要交东西。对于老人来说，这个节奏没问题，甚至有些松弛。但对于新人，这个节奏是致命的。

因为新人不是“代码写得慢”的问题，是“根本不知道该写什么”的问题。他用三天搞清楚该写什么，用三天写完代码，再用两天改完 CR 意见，然后发现测试跑不过，又花两天修 Bug。这时候 Sprint 已经结束了，他的故事还没做完。

在回顾会上，新人低着头说：“我这次没有完成，我会继续努力。”

大家都说“没关系，刚来都需要适应”。但 Sprint 评审没完成就是没完成，燃尽图上那条线不会说谎。Scrum Master 在会后找我，说这个新人的 velocity 影响了团队整体数据，问我怎么处理。

你看，当管理指标开始推着你走的时候，你很难再有耐心慢慢教一个人。你明知道他需要系统学习，但你没有时间。Sprint 不会停下来等他。

这就是敏捷带新人的第一个死结：时间盒是为交付设的，不是为学习设的。

3. “随时沟通”变成了一种负担

敏捷强调“个体和互动高于流程和工具”。但新人的困境恰恰是：他没有能力发起有效的互动。

他不知道该问什么、怎么问、问谁。你让他“随时沟通”，他只能问出“这个地方报错了怎么办”这种点状问题。导师帮他解决了这个具体报错，但他还是不知道整个数据流是怎么走的。

相比之下，瀑布的流程是反过来设计的。瀑布不强调“随时沟通”，它强调在关键节点上做正式沟通。需求评审会、设计方案评审会、测试用例评审会，这些会议在新人眼里不是负担，而是强制性的学习节点。他必须参加、必须听、必须理解，因为要签字确认。

敏捷的自由度，对老人是红利，对新人是陷阱。

三、瀑布为什么反而更适合带新人：结构化就是引导力

1. 五个阶段，就是五块学习积木

瀑布的线性流程，教科书上写的是“需求→设计→编码→测试→验收”。我以前也觉得这个太死板，太不灵活。但当我开始系统地带新人之后，我发现这五个阶段天然就是一套教学大纲。

我是这么用的：

1. 需求阶段：新人跟着产品经理去听用户诉求，记录需求文档。这个阶段他要学会的是“理解业务”。不是写代码，是把业务逻辑用自己的话复述一遍。
2. 设计阶段：新人画架构图、写接口定义、设计数据库表结构。导师在这个阶段做 Review，在他动手写代码之前就纠正思路。这个阶段他要学会的是“系统性思考”。
3. 编码阶段：新人开始写代码，但已经有一份详细的设计文档做参考。他不是在白纸上画，而是在格子里填色。这个阶段他要学会的是“工程规范”。
4. 测试阶段：新人自己写单元测试和集成测试用例，学会“如何验证自己的代码是对的”。
5. 验收阶段：新人把功能演示给导师和产品经理看，学会“如何交付和汇报”。

这五个阶段，每个阶段都有明确的输入和输出。新人不需要自己去猜“下一步该干什么”，他只需要在当前阶段把一件事情做好。这对于刚入职 3 个月以内的人来说，是一种心理上的安全感。

2. 设计评审是成本最低的纠错机制

瀑布被人诟病最多的是“反馈太慢”。传统说法是：需求做完了才知道设计有问题，设计做完了才知道代码实现不了，代码写完了测试才发现 Bug，测试完了上线才发现用户根本不买单。

这个批评在“做产品”的场景下是成立的。但在“带新人”的场景下，我有一个相反的观察：瀑布的“阶段评审”其实是把反馈前置到了编码之前，恰恰是纠错成本最低的时刻。

举个真实例子。我让一个新人设计一个“用户权限管理”模块的数据库表结构。他画了一个 ER 图，把用户、角色、权限三张表做了关联。我在设计评审会上看了三分钟，问他：“如果未来一个用户需要同时属于两个部门，权限怎么算？”

他愣了一下，发现自己只考虑了单部门场景。

这个错误如果在敏捷模式下，大概率要到编码完成甚至测试阶段才会被发现。因为敏捷强调“尽早交付可工作的软件”，新人可能直接上手写了一个只支持单部门的权限控制，然后在 Sprint 评审时被产品经理指出“这个不符合实际业务需求”。

在代码阶段改一个设计问题，成本是开会时的 10 倍以上。

3. “不变”对新人是一种保护

敏捷拥抱变化，这是它最核心的价值观。但对于新人来说，“需求变更”不是好事，是灾难。

我见过一个新人，跟着做了三周的功能，快做完的时候产品经理过来说：“客户那边反馈，这个流程需要加一个审批节点。”

老人面对这种情况，心里不爽但技术上能搞定。他清楚代码结构，知道在哪里加一个状态位，知道怎么改工作流引擎的配置。但新人遇到需求变更，他的反应是：“我前面三周学的全白费了，我要重新理解整个流程。”

他的知识体系还没建立起来，变更对他来说不是“调整”，而是推倒重来。

瀑布的“阶段性锁定”在带新人时是一个关键保护机制。需求文档评审通过后，在进入设计阶段之前就锁定需求。新人在编码阶段不会被告知“需求改了”，他可以安心地、专注地把手头这一个任务做到最好。

专注力是新人的稀缺资源，而确定性是专注力的前提。

四、一个关键判断：不要把“带人”和“做项目”混为一谈

1. 给新人的“沙盒”，给老人的“战场”

我做了一个管理上的分层策略，效果很好，分享给大家。

核心逻辑：新人用瀑布带，老人用敏捷跑。

具体做法是这样的：每个新人入职后的前 3 个月，不进入正式的敏捷 Sprint。我给他分配一个2 到 4 周的“瀑布式小项目”，通常是一个相对独立的功能模块，需求明确、边界清晰、不依赖太多外部接口。这个模块的生产环境上线时间不做硬性要求，但我要求他必须完整走完“需求理解→设计方案→编码→测试→演示”五个阶段。

这个“沙盒项目”的目的不是交付，是教学。每一次阶段评审，都是一对一的深度辅导。

而老人的主战场继续用敏捷，不受影响。老人已经具备了在不确定性中工作的能力，他们需要的是快速迭代和高效协作。

把这两种模式用在不同的人身上，而不是纠结于用一种模式覆盖所有人。这个分层策略让我团队的离职率从新人入职 6 个月内的 40%（敏捷组）降到了 0%（瀑布组）。

2. PingCode 里一个有意思的数据观察

PingCode 主要服务中大型企业，客户规模大多数在 100 人以上。我接触过不少用 PingCode 做 Scrum 管理的技术管理者，聊到一个共同痛点：新人在敏捷看板上的任务流动异常缓慢。

PingCode 的看板上，任务有“待处理、进行中、已完成”三个基本状态。正常老手的任务在“进行中”的平均停留时间是 1.5 天。而新人的同一个状态停留时间是 4.2 天，是老手的 2.8 倍。

更关键的是“返工率”。老手从“已完成”被重新打回到“进行中”的概率大约是 8%，而新人的这一数据是 35%。也就是说，新人每完成 3 个任务，就有 1 个需要被打回来重做。

为什么？因为新人理解需求不准确，代码质量不达标，测试覆盖不够。而这些问题的根源，不是新人不行，是敏捷的“轻文档、重沟通”模式让新人缺少足够的输入信息。

如果用瀑布的方式，给新人一份详细的需求规格说明书和设计文档，他的“返工率”能降到多少？我后来在自己的瀑布小组中统计了一下，大约在 12% 左右，仍然高于老手，但已经比 35% 好太多了。

3. 什么情况下可以给新人直接用敏捷

我不是一刀切地说所有新人都必须用瀑布带。实事求是的判断是：

如果满足以下三个条件，新人可以直接进敏捷团队：

1. 新人本身有 2 年以上的全职开发经验，不是校招应届生。他已经形成了自己的学习方法和代码规范，能够在碎片化的信息中快速建立知识框架。
2. 团队有专门的 Onboarding 文档体系，而且这个文档是持续维护的，不是三年前写的。新人不靠口口相传来学东西。
3. 业务领域相对简单，不是金融、医疗、工业控制这类需要大量背景知识的垂直领域。

这三个条件缺一个，我建议至少安排 1 到 2 个“瀑布式入门任务”作为过渡。

五、具体怎么落地：一套可直接套用的“瀑布带人清单”

1. 选任务：第一个任务决定信心

给新人的第一个任务非常重要。我选任务的三个标准：

1. 业务价值明确：新人做完之后能直观地看到效果。比如“增加一个导出 Excel 的功能”，比“重构某个底层工具类”更适合做第一个任务。
2. 技术边界清晰：只涉及 1 到 2 个模块，不跨系统调用。避免一上来就给一个要改 5 个微服务的任务。
3. 有现成参考：代码库里有类似的功能实现可以参考。新人不是从零发明，是仿写+理解。

我通常会从 Backlog 里挑 3 到 5 个候选任务，自己先评估一遍技术复杂度，然后选一个最符合这三个条件的分配给新人。

2. 需求阶段：让新人复述，而不是点头

新人最常见的反应是“明白了”。但一让他复述，就会发现其实完全没明白。

我在需求阶段的固定流程：

1. 产品经理讲需求（30 分钟），新人旁听并记录。
2. 当天下午，新人用自己的话把需求写成一页纸的描述，发给我。
3. 我指出 3 到 5 个他理解有偏差的地方，逐条纠正。
4. 新人修改后重新提交，我确认通过，需求阶段结束。

这个过程一般需要 2 天。看起来慢，但需求阶段的理解深度决定了后面所有阶段的质量。这个地方不能省时间。

3. 设计阶段：导师审文档，不审代码

设计阶段是瀑布带新人最关键的一环。我带新人的原则是：在动手写代码之前，所有核心决策都要经过评审。

评审内容至少包括：

• 数据库表结构设计（ER 图 + 字段说明）
• 接口定义（入参、出参、异常码）
• 核心逻辑的流程图或伪代码

这个阶段的导师投入大约是 2 到 3 个深度沟通会，每次 1 小时左右。但这一小时在后续带来的回报是巨大的，因为新人不会再在编码阶段写出方向性错误的东西。

4. 编码阶段：先跑通，再写好

新人的编码阶段最容易出现两种极端：一种是闷头写很久交不上来，一种是一股脑全交上来但质量一塌糊涂。

我的做法是拆成 3 个检查点：

1. 检查点 1：功能跑通版本。只要功能能跑起来，代码写得丑我不说。先确保正反馈。
2. 检查点 2：代码规范化。对照团队的 Code Style 指南逐条过，新人在这个阶段会学到很多工程规范。
3. 检查点 3：异常处理和边界条件。教会新人“不要只写快乐路径”。

5. 测试和验收：教他“如何证明自己是对的”

新人常用的表述是“我这里测了，没问题”。问他怎么测的，他说“浏览器里点了几下”。

我带新人的测试阶段会要求他：

• 写 3 个单元测试（快乐路径、异常路径、边界值）
• 写 1 个集成测试（模拟完整的用户操作链路）
• 在验收会上，用 5 分钟演示功能，并回答两个问题：“你做了什么”和“你是怎么验证它的”

这一整套流程走下来，大约需要 2 到 4 周，视任务复杂度而定。完成之后，新人的基础能力框架就立起来了。

六、常见误区：别把“敏捷不适合带新人”理解成“敏捷不好”

1. 工具没有好坏，看用在谁身上

我必须强调：我说瀑布适合带新人，不是说敏捷不好。敏捷在正确的场景下是极其高效的开发模式，这一点毫无疑问。

但问题是，很多团队在选择开发流程时，只考虑了“项目特性”，没考虑“人员构成”。一个有 30% 新人的团队和一个全是老手的团队，用同一套敏捷流程，结果可能完全不一样。

流程要适配人，而不是让人去硬适配流程。

2. 不要神化敏捷，也不要妖魔化它

业界有一个不好的风气，就是把敏捷当成唯一正确的答案。招聘 JD 上写“要有敏捷开发经验”，面试官问“你用过 Scrum 吗”，好像不用敏捷就是落后的。

我自己用了很多年敏捷，也看了很多国际上的反思。Martin Fowler 本人就说过，很多团队在做的是“Flaccid Scrum”，只有形式没有实质的“软趴趴的 Scrum”。这种情况下的敏捷，不仅带不了新人，连交付质量都保证不了。

务实的管理者应该问的问题是：“我的团队现在最需要什么？”而不是“现在流行什么？”

3. 带新人这件事，本质上是教育，不是管理

这是我个人最深的体会。管理关注的是产出和效率，教育关注的是成长和建立基础。如果用一个管理者的视角去带新人，你会要求他快速产出；但如果用一个教育者的视角去带新人，你会给他搭好脚手架。

瀑布就是那个脚手架。你先把框架搭好，让他一步一步爬，爬稳了之后再把脚手架拆掉，让他自由发挥。这比“直接把新人扔到水里学游泳”要高效得多，也人性化得多。

七、行动建议：不同情况下的取舍和过渡

1. 大厂 vs 小厂，带人策略不一样

大厂（500 人以上技术团队）通常有完整的 Onboarding 体系和内部培训资源。在这种情况下，让新人直接进敏捷团队，配合已有的文档和培训，风险相对可控。

但如果你在 100 人以下的公司，或者业务处于快速发展期、文档相对薄弱的阶段，我强烈建议用瀑布带新人。因为当组织的基础设施不成熟时，流程本身就是最好的知识传递工具。

2. 什么时候该让新人切换到敏捷

我的判断标准是：当他能独立完成一个功能模块的“需求理解到上线交付”全流程，且过程中不需要导师介入超过 3 次，就可以进入敏捷小组了。

这个标准在我的团队里，通常对应入职后的第 2 到第 3 个月。完成了 2 个“瀑布式小项目”之后，新人对业务、代码规范、团队协作方式都有了基本认知，这时候切换到敏捷，他能跟上节奏，也能贡献产出。

3. 已经在用敏捷的团队，怎么插入瀑布带人

不需要改变整个团队的流程。只需要为新人单独划出一个“入职缓冲期”即可。

具体操作：

1. 新人头 4 周不进入 Sprint 排期，只做独立的“瀑布式任务”。
2. 新人参加站会，但不报进度，只听别人怎么讲。这让他感受节奏，但不承担压力。
3. 第 5 周开始，新人正式进入 Sprint，但第一个 Sprint 的任务量是正常老手的 50%。
4. 第 8 周开始，任务量拉平到正常水平。

这个过渡方案不需要改变现有团队的 Scrum 流程，只是在 Backlog 里为新人留出一块“教学任务区”。管理成本很低，效果却很显著。

八、最后说两句实在话

写这篇文章的缘起，是一个朋友问我：“为什么感觉现在的应届生越来越难带？”

我和他聊了很久，发现他的问题不在应届生身上，而在于他用了一种对新人最不友好的流程，却期待新人能自己快速适应。

敏捷本身没什么错，但你把它用在带人上，就像拿副拐杖给正常人跑步，能跑，但累得很。而真正该用拐杖的人，你反而没给他。

带新人不该是一场幸存者筛选，应该是一套可以复用的能力培养流程。瀑布的可贵之处，恰恰在于它的每一步都能被清晰地审视、改进、复现。这种确定性，是新人最需要的东西。

我给你的具体行动建议很简单：

1. 盘点一下你团队现在有多少个入职 6 个月内的新人。
2. 选一个新人，给他分配一个“瀑布式小项目”，4 周内走完五个阶段。
3. 观察他在哪个阶段的产出质量最高，哪个阶段最吃力，据此调整后续的辅导重点。
4. 无论你用 Jira、PingCode 还是 Excel 管任务，把新人的任务单独标出来，不要混在 Sprint Backlog 里。
5. 坚持 3 个月后，对比这个新人和之前直接用敏捷带的新人，看看独立产出能力和留存率有没有变化。

如果你试了之后发现不对，欢迎回来告诉我哪里有问题。如果你试了之后发现确实有效，也请把你的经验分享出来。带人这件事，值得我们花更多时间去认真做。

流程是为成长服务的，不是反过来。