小团队敏捷，别照搬大厂流程

一、为什么我说“小团队敏捷，别照搬大厂流程”

过去五年，我参与过十几家技术团队的敏捷转型咨询，有一家做跨境电商的 8 人研发团队让我到现在都记得很清楚。他们花了三个月时间，认认真真地把 Scrum Guide 上写的每一件事都做了，Sprint Planning 开足两小时、每日站会雷打不动、Sprint Review 邀请所有相关方、Retrospective 用五星投票法。三个月以后，技术负责人在复盘会上说了一句话：“我们现在流程跑得很顺，但交付速度比三个月前慢了40%。”

这不是孤例。2023 年 State of Agile Report 的数据显示，团队规模在 20 人以下的组织中，完全照搬 Scrum 框架的团队，有 47% 在 18 个月内回退到了更轻量级的协作方式，或者直接放弃了敏捷标签。注意，这里说的不是“敏捷没用”，而是“照搬大厂流程没用”。

我今天想把这个问题彻底说清楚。因为网上太多文章在讲“小团队如何做减法”，但减法的底层逻辑是什么、该减哪里不该减哪里、减完以后怎么判断是不是减对了，这些很少有人讲透。而我的核心结论只有一句话：小团队需要的不是大厂流程的精简版，而是一套完全不同的协作模型。你把这个模型建对了，流程会自己长出来；建错了，减多少步都是在错误的方向上加速。

二、先把背景理清楚，你口中的“敏捷”和大厂的“敏捷”根本不是一回事

很多小团队往敏捷上靠的时候，其实是在模仿一个自己没见过的东西。你看到的是别人公众号文章里写的 Sprint Planning、Backlog Refinement、Definition of Done，你看不到的是大厂做这些事背后的组织前提。

2018 年我在一家 2000 人规模的 SaaS 公司做 Scrum Master，那时候我们一个 Scrum Team 的标准配置是：1 个全职 Product Owner、1 个全职 Scrum Master、5 到 7 个开发、2 个测试、1 个专职 UX。光支撑一个 9 个人的交付团队，外围还有对应的职能经理、技术委员会、架构组、发布管理组。这套流程为什么能跑起来？因为它把协作的复杂度从“人”身上转移到了“流程”身上，流程是你和我不需要私交很好也能协作的保底机制。

但一个 8 个人的创业公司是什么状态？你根本不需要这个保底机制。你的 PO 可能就是 CEO 本人，你的开发坐在你旁边，测试是开发自己兼的，设计师是外包的。你和同事之间每天说的话可能比大厂一个 Sprint 期间的正式沟通还多。在这种情况下，强行引入一套为“陌生人协作”设计的流程，不是在解决问题，是在制造问题。

1. 大厂流程解决的是大规模协作的信息衰减问题

我举个例子让你感受一下规模带来的信息衰减有多严重。一个 3 人团队，所有人在一个群里，需求变更只要说一句话，所有人都知道。一个 30 人团队，一个需求变更至少经过 3 层传递：产品经理告诉 Tech Lead，Tech Lead 告诉开发，开发告诉测试。每一层都会产生信息损耗，有人漏听、有人理解偏差、有人根本不知道变了。

大厂的 Sprint 周期、站会、评审会，本质上是针对这种信息衰减设计的“信息强制同步机制”。你需要一个固定的频率、固定的格式、固定的参与人，才能保证在多层级传递中信息不丢包。但如果你是 8 人团队，你们之间根本没有那么多层级，信息衰减几乎为零，你还需要这些强制同步机制吗？

2. 小团队的本质优势是“高带宽沟通”

我之前带过一个 6 人全栈团队，需求评审的方式就是在白板上画完，然后问一圈：“行不行？有没有坑？”三个人说没问题，一个人提出了一个技术风险，我们当场改了方案，十分钟结束。这种事情在大厂需要走一轮 RFC 流程，从发起评审到所有人回复意见，至少两三天。

这里的关键不是大厂慢、小团队快，而是小团队天然拥有高带宽的沟通环境。你们之间信息传递的速度、准确度和上下文丰富程度，是大厂任何流程都达不到的。你如果放弃这个优势，把高带宽降级为低带宽，再用流程去补偿，这就是典型的得不偿失。

三、拆解最常见的五个误区，你可能正在犯这些错

接下来我把小团队在敏捷转型中最常踩的五个坑一个个拆开讲。这些坑我在至少三家公司里见过不同的团队反复踩，有些是我自己踩过的，有些是我眼看着别人踩下去的。

1. 误区一：强行设立专职 Scrum Master

Scrum Guide 里说得明明白白，Scrum Master 是一个有明确职责的角色。于是一个 7 人团队就真的设了一个专职 SM，这个人不写代码、不做测试、不管需求，每天的任务就是“维护流程”。

现实是什么？一个 7 人团队的流程维护工作，每天不会超过 30 分钟。剩下的时间这个人干嘛？他会本能地“找活儿干”，去优化看板、去研究插件、去给每个人发流程改进建议。很快，流程维护变成流程发明，流程发明变成流程压力。团队成员开始觉得这个 SM 是多余的，而 SM 本人为了证明自己的价值，会越来越强调流程的严格执行。这就是我见过的最典型的“流程自激振荡”，角色创造了流程需求，流程需求又反过来强化了角色的必要性。

我的建议很简单：15 人以下的团队，Scrum Master 必须是轮值或者兼任。让 Tech Lead 兼、让某个开发轮值一个月、甚至不需要这个角色名称，只保留关键职责，比如保障会议不跑偏、跟进阻塞项的解决。一件事如果需要专人全职负责，那这件事本身就值得重新审视。

2. 误区二：僵化执行两到四周的 Sprint 周期

“Sprint 长度一旦确定就不要轻易改变”，这句话我从不下十个敏捷教练嘴里听到过。这句话对 50 人的团队有用，对一个在探索 PMF 的 5 人创业团队来说就是慢性自杀。

我去年帮一家 AI 应用创业团队看过他们的研发流程。他们严格执行两周 Sprint，但几乎每个 Sprint 的第三天需求就全变了，因为创始人每天都在见客户、拿反馈、调方向。他们的应对方式是什么？把新需求写进下一个 Sprint，然后继续按照两周前定好的 Plan 往前跑。结果是，每个 Sprint 交付的都是“两周前需要的功能”，而不是“今天需要的功能”。

Sprint 的本质不是时间盒，而是节奏感。对于还在市场验证阶段的小团队，一周可能都太长。我见过最极端的情况是一个 4 人团队把节奏砍到了“三日冲刺”，周一早上对齐、周三下午演示、周四早上再对齐。他们一个月内迭代的次数，是传统两周 Sprint 的两倍。不是因为他们更勤奋，而是因为他们的节奏和信息流动的频率真正匹配了。

3. 误区三：每日站会变成汇报表演

站会的原始设计是非常好的：15 分钟、站着开、只说三件事，昨天干了啥、今天要干啥、有没有阻塞。但不知道从什么时候开始，这个东西在小团队里也变成了每个人对着 Tech Lead 汇报工作。一个 6 人团队，每人说两三分钟，15 分钟刚好讲完，但听完以后你不知道隔壁同事的代码对你的模块有什么影响、不知道某个阻塞项的根本原因是什么、也不知道今天下午的优先级会不会变。

问题的根子在哪儿？在于小团队的信息本身就应该是即时流动的，你不需要等 24 小时才同步一次。我在一个 10 人团队里做过一个实验：把每日站会改成每天下午 4 点的一次 10 分钟异步文字更新，把真正的面对面同步改为随时发起、随时结束的“即时对齐”，发现风险、拉人、说清楚、散会，平均每次不超过 8 分钟。一个月后，团队自发觉得“开会的焦虑感”下降了 60% 以上，而信息同步质量没有任何下降。

4. 误区四：Sprint Review 和 Retrospective 被合并或走过场

我之前见过最离谱的一个案例：一个 9 人团队把 Review 和 Retro 合并成一个一小时的会，前 30 分钟走马观花地演示，后 30 分钟每人说一句“这个 Sprint 挺好的，继续加油”就散会。这样的回顾会持续了四个月，团队效率持续下降，但回顾会每次的结论都是“继续保持”。

这里的问题是，Review 和 Retro 是两件完全不同的事。Review 是对外，我们交付了什么、干系人满不满意、下一步方向要不要调。Retro 是对内，我们的协作方式有没有问题、流程有没有摩擦点、彼此的配合能不能更顺。小团队最容易犯的错就是把两者混成一锅粥，因为人少、事情少，好像可以一锅端。但实际上，人越少，回顾的质量越重要，因为你们没有冗余，一个人不顺等于整个团队不顺。

我的做法是：Review 可以不定期做，有需要演示的成果就约干系人看，不需要演示的 Sprint 就直接发 Release Note。但 Retro 必须定期做，哪怕只有 20 分钟，也必须聚焦在一个问题上，“这个 Sprint 最让你难受的一件事是什么，我们下周能不能把它干掉”。

5. 误区五：把 Story Points 和 Velocity 当成绩效指标

这是我见过的杀伤力最大的误区，没有之一。当一个团队开始用 Story Points 来对比“这个 Sprint 谁干得多、谁干得少”，或者用 Velocity 来承诺“下个 Sprint 我们必须完成多少点”的时候，这个团队已经从敏捷退回到了计件工资时代。

Story Points 是什么？是估算工具，是团队内部用来预判复杂度的相对尺度，它不是生产力指标。Velocity 是什么？是团队交付能力的历史参考，用来帮助 PO 判断大概能做多少，它不是绩效承诺。但在很多小团队里，创始人天然会把“可量化的东西”拿来做管理工具，因为小公司的人太少了，创始人对每个人的产出高度敏感。结果就是，开发开始往 Points 里注水，把一个 3 点的任务拆成三个 2 点任务，Velocity 蹭蹭往上涨，但真正的交付质量没人关心。

我的底线规矩是：任何团队的 Story Points 和 Velocity 数据，绝对不出现在绩效评估、薪资调整和任何形式的横向对比中。一次都不行。一旦破了这个规矩，估算就变成了博弈，敏捷的基石就碎了。

四、我的专业判断逻辑，怎么判断一个流程该不该留

讲完误区，下一个问题自然就是：我怎么知道哪些流程该砍、哪些该留？总不能凭感觉说“这个太多余了”就砍掉。我需要一套能复用的判断框架。

我用的框架很简单，四个问题，任何一个流程、会议、角色、规则，都拿这四问筛一遍：

第一问：这个流程解决的是“信息传递”问题还是“信息创造”问题？如果是信息传递，比如站会同步进度、Sprint Review 同步交付结果，在 10 人以下团队里，你大概率有更高效的方式替代它。如果是信息创造，比如 Planning 一起拆任务、Retro 一起反思协作方式，这些都是必须面对面做的东西，不能砍，但可以压缩时间。

第二问：去掉这个流程后，最大的风险是什么？这个风险能不能用更轻量的方式兜住？比如去掉站会，最大的风险是某个人卡住了没人知道。那能不能做一个规则：谁卡住了，谁就在群里发一条消息 @ Tech Lead，15 分钟内必须有人响应。加了这条规则以后，站会这个流程就可以安全地退化。

第三问：这个流程的参与者，在没有这个流程的时候，自己做不做这件事？如果开发本来每天就在看板、拉分支、写代码，你不需要通过站会去“确认”他有没有在工作。如果一个团队本来就自觉做 Code Review，你不需要在 DoD 里专门写一条“代码必须经过 Review”。流程应该只补那些“没人做但又必须做的事”，而不是把“大家都已经在做的事”再包装一遍。

第四问：这个流程是让你更信任团队，还是更依赖流程本身？这个问题很软，但它是我判断一个团队敏捷健不健康的温度计。一个团队如果所有的协作都靠流程自动推着走，离开流程就不知道怎么做，这个团队其实是“流程依赖型”，不是“自适应型”。而小团队要想活下来，必须是后者。

这四个问题我在每次 Retro 的时候都会拿出来和团队过一遍。尤其是第四问，经常能在团队内部引发非常有价值的讨论。有一次一个开发直接说：“我们在站会上说的东西，其实开会前我已经在群里发过了，来开会就是再说一遍。”，这句话帮他整个团队砍掉了为期三个月的无效站会。

五、PingCode 这类工具对大团队意味着什么，反过来理解小团队该要什么

我在咨询服务里有一个很常用的方法：如果你想理解小团队该怎么做，你先去看看那些服务大企业的工具在解决什么问题，然后反着推。

PingCode 是一个很好的分析样本。我仔细看过 PingCode 的 Scrum 解决方案，它在几个地方做得非常重，多级需求管理、史诗-特性-用户故事的分层体系、迭代燃尽图、回顾板记录，这些设计背后都指向一个事实：它服务的是百人以上的组织，这些组织的核心痛点不是“写代码不够快”，而是“需求从业务端到开发端的传递路径太长，中间损耗太大”。

我举 PingCode 里一个具体的功能设计来说明这件事。在它的需求管理流程里，产品负责人可以给每个需求设定优先级和业务价值。这个功能对 100 人的团队是必要的，因为 PO 和开发之间隔着至少一层 Tech Lead，开发看不到 PO 的优先级判断依据，这个字段就是唯一的信号载体。但对一个 8 人团队，PO 就坐在你旁边，优先级为什么这么排他可以当场讲清楚，这个字段的价值就急剧下降。

再比如 PingCode 的迭代燃尽图功能。这个东西在大团队里几乎不可或缺，Scrum Master 和 PO 靠它来感知风险，当燃尽曲线偏离理想线时触发预警。但同样的功能放到 6 人团队，开发自己比燃尽图更早知道哪张卡要延了，因为卡就贴在看板上，每天路过都能看到。燃尽图的作用从“预警工具”退化成了“记录工具”。

这不是说 PingCode 的工具不好，恰恰相反，它做得非常精准，精准地命中了 100 人以上组织在 Scrum 落地时的真实痛点。但这也恰好说明了我的核心观点：小团队和大团队需要的流程基础设施是完全不同的层级。你用 PingCode 给百人团队做的完整 Scrum 解决方案去管一个 6 人团队，就相当于用一套 ERP 去管理一个路边摊的进销存。

那反过来，小团队该用什么？我这些年用下来的判断标准只有一个：工具对你的团队来说应该“轻到看不见”。它不应该成为一个需要学习成本、需要日常维护、需要专人管理的东西。小团队的工具选择，应该遵循三个原则：

第一，信息可见性大于流程完整性。你不需要一个工具能跑完整的 Scrum 流程，你需要的是这个工具能让每个人三秒内看到“现在谁在干什么、有什么卡住了、下一步优先做哪个”。一个简单的看板工具，甚至一个共享表格，只要信息可见性够高，就比一套完整但复杂的 Scrum 工具好用得多。

第二，操作成本必须趋近于零。如果你的开发更新一张卡需要点三下、填两个字段、选一个下拉框，这个工具对他就是负担。小团队的信息更新频率远高于大团队，每次更新的操作成本哪怕只多 3 秒，一天累计下来就是一个不可忽视的时间黑洞。我见过一个 6 人团队，因为用的工具太复杂，大家干脆不更新了，最后看板变成了“上周的考古现场”。

第三，能随时用能随时扔。小团队的流程一直在变，你今天觉得这个分组好，下个月可能就觉得不需要了。工具必须具备极高的灵活性，不能因为你要调整一个分类、改一个标签、合并一个列表就要做一大堆配置。如果调整流程的代价比忍受不太合适的流程还大，这个工具就成了流程演化的阻碍。

六、不同场景下的行动建议，没有一种答案适合所有人

前面讲了很多“不要做什么”，接下来该讲“不同类型的小团队该做什么”。小团队不是一个同质群体，一个在做内部工具的 8 人团队，和一个在做消费级 APP 的 8 人团队，需要的东西完全不同。我按照最常见的四类场景分开来说。

1. 场景一：创业探索期团队（正在找 PMF）

如果你是一个 5 到 12 人的初创团队，还在验证市场方向、频繁 pivot，那你的第一优先级根本不是流程。你需要的不是 Scrum，是一套能让你以天为单位快速验证假设的节奏。

我建议的做法：完全放弃 Sprint 概念，改用“实验-验证”节奏。具体形式可以是这样，周一下午花一小时定这周要做的一个核心实验（比如“如果把注册流程从三步改成一步，转化率会不会提高？”），然后全队聚焦把这个实验做上线，周三或周四看数据，周五决定下周继续深挖还是换个方向。这个节奏里没有 Backlog、没有 Planning、没有 Review，只有“假设-执行-验证-调整”这个短闭环。

这个阶段最容易犯的错就是引入一套稳定的流程，因为你本身就不稳定，稳定的流程只会拖慢你 pivot 的速度。

2. 场景二：成长期产品团队（已有稳定用户，需要快速迭代）

如果你的 10 到 20 人团队有了一款已经有用户基础的产品，方向相对明确，但需求量大、竞争压力高，这时候你需要的是“有节奏的灵活性”。

我建议的做法：保留一个轻量级的迭代周期，但缩短到一周。周一早上用 30 分钟快速对齐本周优先级（不是拆任务，是确认优先顺序），中间不安排任何固定会议，周五下午用 30 分钟做一次“演示+回顾”合并会议，先花 15 分钟让每个人展示这周做的最重要的一件事，然后花 15 分钟用“一个词”的方式收集情绪反馈（比如每个人说一个词总结这周的感受，“爽”、“乱”、“堵”、“顺”这种词就够了，不需要展开打分表）。

这个阶段的关键是保持节奏但不僵化。一周是一个心理上舒服的步频，足够快，又不至于让团队觉得被追着跑。

3. 场景三：内包/内部工具团队（服务内部客户）

内部工具团队和面向外部用户的产品团队有一个本质区别：你的“客户”坐在同一栋楼里，需求可以直接面谈。这个优势往往被浪费了。

我建议的做法：放弃写长篇 PRD 和 User Story，直接用“需求方对坐”的方式做规划。每两周让需求方和开发坐在一起，需求方当场说最需要的三个东西，开发当场评估复杂度和排期，达成一致后直接开工。需求方有权在两周内用一个新需求换掉一个还没开始做的旧需求，这就是你给内部客户提供的“灵活性 SLA”。

内部工具团队最常见的翻车原因是：把自己当成一个“外部乙方”，走完整的需求-评审-排期-开发-验收流程。但你的需求方根本不需要这些，他只要你快。缩短这个路径，比任何流程优化都管用。

4. 场景四：远程/分布式小团队

疫情以后这种团队越来越多，3 到 8 个人分布在不同的城市甚至不同的时区。这是唯一一个我建议增加流程的场景，但增加的不是管理流程，是信息同步流程。

我建议的做法：建立一个“异步优先”的协作纪律。具体包括：每天下班前必须写一段不超过 200 字的“今日进展+明日计划+阻塞项”发在共享频道；所有重要决策必须在文档中留下记录，不允许只在视频通话里口头决定；每个任务卡必须有一个“为什么这个任务现在最重要”的简短注释，让任何人在任何时候都能理解上下文。

远程团队最大的敌人不是距离，是上下文丢失。你加的这些流程不是用来管人的，是用来保证每个人在没有面对面接触时也能拥有足够的上下文信息。这个投入是值得的。

七、做取舍，什么时候该坚持流程，什么时候该放弃

讲完不同场景的建议，我必须补一个重要的话题：流程不是越少越好。有些时候，坚持一个看似“重”的流程反而是正确的选择。问题是，你怎么判断什么时候该坚持、什么时候该放弃？

我这五年里反复验证过的一个判断标准是：看你和团队当前最大的痛点是什么性质的。

1. 如果痛点是“乱”，适度增加结构性流程

如果团队反馈的是“不知道优先级是什么”、“昨天做的需求今天说不要了”、“代码改完发现和别人的冲突了”，这些都是“结构性缺失”的信号。你需要的是加流程，而不是减流程。

具体可以加什么？一个明确的优先级排序机制（PO 说了算，其他人别再插需求）、一个简单的分支管理规则（feature branch + PR review，别直接往 main 上推）、一个“需求变更必须走一句口头确认”的小规矩。这些东西一点都不重，但它们能解决“乱”的问题。

2. 如果痛点是“慢”，审视是不是流程在制造等待

如果团队反馈的是“等需求评审等了两天”、“等代码审核等了一下午”、“等测试环境排到明天”，这些都是流程制造了等待队列。你需要砍流程，同时引入更直接的协作方式。

比如需求评审不等集体会议，直接 PO 和开发当场确认；代码审核不等人“有空再看”，设一个规则：@ 到谁的 PR 谁在 2 小时内必须看；测试不走独立环节，开发和 PO 一起验收。这些都在砍中间环节，把串行变并行。

3. 如果痛点是“烦”，考虑流程的参与感是否出了问题

如果团队反馈的是“又要开会了”、“又要填工时了”、“又要把同样的东西在三个地方更新”，这些不是流程太多或太少，是流程设计不考虑人的感受。人不是流水线上的机器，人对“无意义重复劳动”的容忍度极低。

这时候你需要做的不是砍流程本身，而是砍掉流程中那些“让人觉得没价值”的部分。我见过一个团队把日报从“写今天做了什么、明天做什么”改成“写今天学到的一个东西”，团队的情绪反馈从极度抵触变成了“还行，有时候还挺有意思”。同样的时间投入，感受完全不同。

4. 如果痛点是“怕”，这是最严重的问题

如果团队的反馈是“不敢改别人的代码”、“不敢说不合理的需求”、“不敢在回顾会上说真话”，这是信任崩塌的信号。流程保不住了，你得先治人。

我的处理方式很直接：暂停所有正式回顾会，找一个团队信任的人（不一定是管理者），分别和每个人一对一面谈，搞清楚怕的源头是什么。是某人被公开批评过？是绩效和某些指标过度挂钩？是需求变更经常被用来追责？找到源头，从源头改，然后再慢慢恢复流程。这种时候任何流程调整都是治标不治本。

八、总结

回到一开始那句话：小团队需要的不是大厂流程的精简版，而是一套完全不同的协作模型。

你全部工作的核心不是照着 Scrum Guide 往下砍步骤，而是理解你自己的团队，团队有多少人、分布在几个地方、正在解决什么问题、最大痛点是什么性质的、团队成员之间的信任水位有多高。这些就是你的“协作土壤”。大厂的流程是在大厂的土壤里长出来的，你不能把它直接移植到你的土里还指望它活得好。

我最后送你三条具体可做的事，今天就够用：

第一，在下一个迭代结束的时候，把团队拉在一起，用“四问框架”过一遍你们现有的所有流程。让每个人投票：哪些流程你觉得在帮我们、哪些在拖累我们、哪些你其实不理解为什么要这么做。不需要任何工具，白板和便签纸就够了。投完票以后，当场砍掉得票最高的那个“拖累流程”。就砍一个，不需要大动干戈。然后下个迭代观察效果，如果没出问题，说明砍对了；如果出问题了，把它加回来，同时搞清楚为什么它其实是必要的。

第二，找一件团队现在每天或每周都在重复做的“信息同步类”的事，尝试用异步方式替代它一次。比如把下次站会改成“各自在群里写三句话”试试。不是永远改，就是试一次。试完以后收集反馈：谁觉得信息量不够、谁觉得省了时间、谁觉得失去了什么。这些反馈本身比改动更有价值，它会让你看清团队对同步方式的真实需求。

第三，如果你是这个团队的管理者或 Tech Lead，请认真问自己一个问题：我现在用的流程，是我真的相信它对这个团队好，还是因为“别人都这么做”所以我也这么做？把答案诚实写下来，不需要给人看。如果答案偏向后半句，你可能是最需要改变的那个人。

敏捷从来不是一个目标，它是一个过程。而小团队敏捷的过程，本质上是持续理解自己、持续调整自己的过程。照搬大厂流程最大的问题不是流程本身不好，而是它让你跳过了一个团队最宝贵的成长阶段，那个必须自己思考、自己判断、自己取舍的阶段。