企业官网建设流程全解析

1. 会议不是敏捷的负担，而是迭代的节奏器

做敏捷做了快十年，带过十几个团队，也旁听过不少团队的敏捷会议，我发现一个特别普遍的现象：一说起敏捷，大家第一反应就是站会、评审会、回顾会这些仪式感很强的会议，然后紧接着就是抱怨——“会太多了”“站会开成了汇报会”“评审会没人愿意来”。慢慢地，敏捷就从一个开发方法论，变成了一个“开会方法论”，而真正的价值反而没人关注了。

我先说一个反直觉的结论：敏捷开发的问题，大多数时候不是会议太多，而是会议设计得太粗糙。会本身不是负担，真正拖垮团队的是那些开完等于没开、开了也没有结论、结论落不了地的会。如果你把会议当成迭代的节奏器——每个会承担一个明确职责，时间盒严格卡住，输入输出都清晰，那你会发现，会议其实是敏捷落地最省力的抓手，甚至是唯一把所有人拉到同一个节奏上的机制。

这篇文章我不想讲那些教科书里的官话，也不想给你一份“五天培训PPT”。我想把敏捷开发全流程里最重要的几类会议，一个一个掰开揉碎讲清楚：每个会解决什么问题、会前要准备什么、会议上具体怎么带、会后又该留下什么，以及我这些年踩过的最典型的坑。你如果是第一次接触敏捷，照着我这套流程完全可以开起来；如果是老手，我也希望能给你一些可以直接拿去用的实操细节。

补充一句，现在很多团队一提敏捷就想到看板、燃尽图、各种工具，其实工具反而是最不重要的。工具撑不起会议，会议才能撑起工具。我见过不少团队买了昂贵的敏捷管理平台，但站会还是开成一言堂，评审会还是领导发话，回顾会还是走形式——这在任何工具上都救不回来。所以这篇文章的核心思路是：先把人聚在一起的方式搞对，再去谈工具和流程的优化。

2. 迭代规划会：一场把“目标”翻译成“承诺”的共创会

迭代规划会（Sprint Planning）是整个敏捷流程里最重的一场会，它的价值在于把产品负责人脑子里的需求，变成开发团队手里有明确边界、可估算、可交付的工作承诺。说白了，就是解决“接下来这段时间，我们到底要做什么、能做多少”的问题。

2.1 会前准备：产品代办事项必须达到“可讨论”状态

很多团队开规划会翻车，不是因为开会本身，而是会前根本没准备。产品负责人带着一肚子想法进来，开发团队一脸懵，最后变成了产品负责人现场讲需求、团队现场点头，规划会硬生生开成了两小时的宣讲会。

我的建议是开会前48小时，产品负责人必须把候选需求放进产品代办列表（Product Backlog），并且达到“可讨论”状态。所谓可讨论，不是简单写一行标题，而是至少包含三样东西：

• 需求的用户价值说明——为什么要做，不做的代价是什么
• 验收标准的草案——完成到什么程度才算真的做完
• 优先级排序的逻辑——为什么是这周做而不是下周做

这三样东西缺了一样，我建议直接把这个需求打回重写。你可能会觉得这个要求太高了，但实操下来你会发现，绝大多数需求写清楚这三件事之后，团队在规划会上根本不需要再花40分钟追问“这个功能到底是干嘛的”，效率能提升一大截。

还有一个细节我特别想提醒：规划会前的产品代办梳理会（Backlog Refinement）要单独开，不要和规划会合并。梳理会解决的是“把模糊需求变清楚”，规划会解决的是“把清楚需求变成承诺”。两件事的节奏完全不同，硬合并在一起，只会让两个会都半吊子。

2.2 会中的节奏把控：先定目标，再拆任务，最后算容量

规划会通常建议控制在4小时以内（一周迭代的话，2小时也够），但这4小时怎么分配有讲究。我惯用的节奏是三个段落：明确目标、估算与任务拆解、承诺与容量确认。

第一段，明确迭代目标。产品负责人先讲清楚这个迭代要达成什么业务目标，不是逐条过需求，而是讲一个连贯的“这轮我们要完成的叙事”。什么是一个好目标？不是“完成登录模块”这种功能堆砌，而是“让用户可以用手机号完成注册并正常登录，从而提升注册转化率”。这两种表述的区别在于，前者是任务清单，后者是有用户价值的成果。

第二段，团队把候选需求逐个过一遍，拆成可执行的开发任务，并现场估算。估算方式我强烈推荐规划扑克（Planning Poker），不要靠嘴说“这个差不多2天吧”。注意，我说的不是让大家掏出扑克牌玩得多正式，而是在估算的机制上要避开一个陷阱：团队里最资深的人先开口报价，剩下的全跟着点头。规划扑克的价值在于让大家同时亮牌，每个人在不受干扰的情况下独立估算，然后针对差异大的条目展开讨论。这种机制很简单，但是真的能挡掉大量“拍脑袋估工期”的情况。

第三段，容量确认。这里有个很多团队都会犯的错误：只看需求复杂度，不看团队实际可用工时。一个新迭代里，团队成员可能有休假、有技术支持任务、有非本项目的琐事，这些都要从容量里先扣掉。举个例子，团队5个人，一周迭代，理论人力是5人×5天×8小时=200人时，但去掉每人2小时的琐事、1天的支持工作，真实的可用容量可能就是140人时。如果你按200人时去承诺交付，那这个迭代一开始就注定要延期。这个账务必要在规划会上当面算清楚，不要私下偷偷算，因为算完往往要让产品负责人现场做取舍——砍掉哪些优先级低的需求，这时候就得有个能拍板的人在。

2.3 规划会的输出物：不是计划书，而是一个可校验的承诺

规划会散会之前，团队必须能清晰回答两个问题：第一，这个迭代的目标是什么；第二，我们要交付哪些用户故事，验收标准分别是什么。我建议顺手做三件事：

• 把迭代目标写在白板上方的显著位置，整个迭代期间都能看到
• 把用户故事按优先级排进迭代队列，每个故事附带验收标准
• 记录估算结果，后续燃尽图要用

很多团队规划会开完很热闹，第二天开始开发，等到了评审会才发现做出来的东西和预期不一致。核心原因就是规划会只定了“做什么”，没有把“做成什么样”同步到位。验收标准这件事，一定要在规划会的时候就写出来，哪怕写得很粗略，也比完全没有强。后续开发过程中再逐步细化，这是允许的，但初始版本必须存在。

3. 每日站会：如何把15分钟用出战略价值

站会是敏捷会议里最被滥用，也最被忽视的一个。说它被滥用，是因为很多团队把它开成了“向领导汇报进度”的例会；说它被忽视，是因为它虽然天天开，却几乎没有人认真设计过它的结构。

3.1 三个问题的底层逻辑，不是背诵模板

标准的站会三问——你昨天做了什么、今天打算做什么、遇到什么阻碍——几乎人人都会背，但真正理解这三问背后逻辑的团队不多。我换个角度解释一下：

• 你昨天做了什么，这句话不是让你向项目经理记账，而是让团队成员之间同步彼此的进度和依赖，谁做完了、谁卡住了、谁的技术方案和谁的有冲突，这些信息只有互相听到才有价值。如果你的站会上，团队成员之间几乎不对话，所有人都在对着Scrum Master轮流说话，那说明站会已经跑偏了。
• 今天打算做什么，目的是确认每个人的工作计划与迭代目标是否对齐，避免有人忙了半天，做的却不是当下的关键路径。
• 遇到什么阻碍，这是站会最核心但最容易被草草带过的问题。不少团队成员不好意思在公开场合暴露问题，或者一句“暂时没有”就带过了。Scrum Master要特别关注这一点，敢于追问，但注意不要在站会上当场展开解决——站会只负责暴露问题，不负责解决问题。

这四个字我必须强调：站会不是解决问题的地方。一旦某个技术问题在站会上展开讨论，其他七八个人就站在旁边听着，15分钟很快就变成45分钟。正确的做法是识别出这个阻碍，然后拉相关的人会后单聊。

3.2 时间盒：15分钟就是15分钟，没得商量

站会15分钟这个时间盒，我认为是敏捷会议里最不能被突破的底线之一。为什么这么严格？因为站会之所以叫“站会”，就是让你站着开、快速开、不想多待。如果你坐下来开着开着也就算了，它就慢慢变得像周会一样冗长。

控制时间的常用招数有这么几个，我用下来比较有效：

1. 按照顺序轮流发言，不要点名式发言。点名式发言会让每个人都处于被动状态，变成“等领导叫到我再说”，而轮流发言可以让团队主动思考自己要说什么。
2. 会后迅速组局。如果站会上有某两个人的问题需要深入讨论，Scrum Master当场指定一个问题小组：“这事你们俩会后留下继续讨论，其他散会。”这既保护了大多数人的时间，也保证了问题不会被遗忘。
3. 白板上只保留阻碍列表。站会时在白板上专门留一栏叫“阻碍/依赖”，谁提到问题就往那栏里加，会议结束后就一目了然地知道今天有哪些事项要跟进。

我见过一些团队把站会开成了“燃尽图评论会”，每个人说完之后，Scrum Master还要点评一下燃尽图的走势，整个过程就变得非常死板。其实燃尽图在站会上的作用应该是一个背景参照，而不是主角。站会的主角永远是团队成员之间实时的信息同步，而不是图表本身。

3.3 站会最大的坑：团队越大，越难开

一个必须直面的事实是，站会这套机制适用于5到9人的团队。如果你的团队超过12个人，我劝你认真考虑拆分问题，而不是硬着头皮开全体站会。大团队站会最典型的现象就是：每个人说话的时候，其他人都在刷消息、写代码，根本没有人听。信息同步的目的完全落空了。

我处理过大团队的站会，有两种比较有效的做法：一种是把大团队按业务模块拆成两三个小团队，各开各的站会，再通过Scrum Master或技术经理会后同步；另一种是把站会改成两层结构，第一层是各小组内部的15分钟，第二层是跨组核心人员碰头。这两种都比硬开一个30人的大站会强一百倍。

站会还有一个我后期才琢磨透的细节——时间盒不应该是Scrum Master一个人看表，而是每个成员自己心里都有表。如果团队每个人都花30秒说自己的部分，15分钟足够12个人说完。但一旦有人讲3分钟，就会有人讲5分钟，这事情就会崩掉。所以我会在团队里反复强调一个原则：站会发言不是述职，讲清楚关键信息就够了，不要展开细节，细节留给会后的自组织小组去谈。

4. 迭代评审会：怎样让相关方真正“参与”而不是“围观”

迭代评审会（Sprint Review）是最容易被搞砸的敏捷会议。很多团队的评审会，实际就是开发团队给产品负责人和领导做一轮演示，领导点几个头，说几句“不错不错”，然后散会。这种会开着有什么意义？本质上和一个进度汇报没有区别。敏捷里的评审会，核心任务是四个字：检验价值。

4.1 评审会不是成果发布会，而是反馈收集会

拉开评审会和发布会之间的差距，首先要改变团队的默认心态。开发团队做完了功能，带着一点“求表扬”的心情来展示，这太正常了，但如果这种心情主导了评审会，整个会议就会变得虚假——所有人都挑好的展示，回避不够完善的部分。而评审会在敏捷框架里的定位，恰恰是给团队一个正式的、低频的、能直接收到相关方反馈的机会。

我建议在评审会上引入一个具体做法：评审会不做“演示流水账”，而是围绕迭代目标逐项验收。开场的第一个环节直接对照规划会上写下的迭代目标，逐条问大家：这个目标实现了吗？实现到什么程度？然后才是功能的实际操作演示，演示的目的是让相关方基于真实体验给出反馈，而不是听团队念PPT。

4.2 实操演示的细节：让相关方动手，而不是看你表演

关于演示这一部分，我踩过最大的坑是：开发人员兴高采烈演示了一个完美路径上的完美操作，相关方也看得津津有味，但在真实使用中最重要的边界场景一个没展示，结果相关方拿回去一用就发现问题。从那以后，我定了两条规则：

• 演示的时候，相关方可以打断、可以要求“那你试试如果……怎么办”
• 至少留出一半的评审时间，让相关方在测试环境里亲手操作

让用户亲手操作，这句话说起来容易，做起来很需要勇气。因为这几乎等于把团队不完美的地方直接暴露在相关方面前。但你要知道，这恰恰是敏捷评审会的目的——早失败、快反馈、低成本修正。与其等上线后用户兜了一圈回来提一堆改动，不如在评审会上就现场收集好。

4.3 一个常见误区：把评审会当成验收门

有些团队把评审会看成一个“验收门”——相关方在会上一句“通过”，团队就认为这个迭代彻底结束了；一句“不完全满足”，就认为功能被拒收了。这种思维把评审会变成了一个紧张的裁判场景，完全违背了反馈循环的本意。

我在实践中更倾向于把评审会的输出定义成三样东西：

• 相关方对已交付功能的真实反馈清单，包括认可的和不满意的
• 基于反馈产生的产品代办事项更新——比如新发现的需求、需要调整的缺陷
• 下一个迭代的输入线索，比如相关方提到的一个重要方向，可以放进待办列表

记住，评审会的目标是让相关方和团队一起看“这个世界有没有因为我们做的事情而变得好一点”，不是检查“你有没有按我说的做完”。

4.4 评审会的邀请范围：宁可多叫，不要少请

评审会应该让哪些人参加？很多团队只叫产品负责人和几个领导，这太窄了。与这个产品相关的运营、客服、销售、技术支持，甚至上一轮的种子用户，都应该在邀请范围里。原因很简单，不同角色对功能的感知完全不同——产品负责人关注业务逻辑对不对，运营关注功能能不能支撑活动，客服关注用户会遇到什么疑问。一个看起来“完成得很完美”的功能，在客服视角可能藏着大量用户体验隐患。

当然，人越多，时间掌控越重要。我习惯把评审会控制在60到90分钟，其中演示不超过20分钟，剩下的时间全留给反馈和讨论。如果相关方超过10个人，我会准备一份结构化的反馈表，让大家写下“你最满意的点”和“你最不满意的点”，避免所有人都在闲聊，最后没留下任何记录。

5. 迭代回顾会：从“吐槽大会”到“改进引擎”的关键转变

很多团队说“我们每周也开回顾会”，但实际效果接近于零。原因特别简单：回顾会开完了，什么也没变。下周还是同样的流程，同样的坑，同样的加班。如果回顾会不能带来行为的改变，那它就不是一个敏捷会议，而是一个情绪宣泄会。

5.1 回顾会的第一原则：只谈我们可控的事

我组织回顾会这么多年，最有效的开场方式不是问“大家觉得我们这周哪里不好”，而是直接在白板上画两个区域：“我们做得好，想继续做”和“我们做得不好，想改进”。然后给每个人5分钟，写在便签纸上，一张纸一件事。

有一条规则我会在开场的时候明确地跟团队讲：只谈我们可控的事。“公司给的资源不够”“其他部门不配合”“需求总变”——这类问题，如果团队自己无法推动，讨论再多也只会积累怨气，不会产生任何行动。真正值得讨论的，是自己能改变的事情。这听起来有点反直觉，但高效的回顾会恰恰是这种有限范围内的深挖，而不是对公司流程的全面控诉。

5.2 深挖问题的工具：五个为什么和影响地图

在团队找出“做得不好”的事项之后，最忌讳的就是直接跳到解决方案。比如说“测试总在最后一刻才介入，导致上线前手忙脚乱”——如果团队直接说“那以后测试提前介入”，这其实是正确的废话，因为大家根本没有想清楚“为什么测试总在最后一刻介入”。

我常用的方法是对选定的问题做五个为什么，用生活化的例子解释就是：为什么测试总在最后一刻介入？因为开发没有提前给测试版本。为什么开发没有提前给测试版本？因为开发在迭代后期才完成功能。为什么开发在迭代后期才完成功能？因为任务拆解的时候把复杂的、不确定的模块放到了最后。走到这一步，问题才真正露出了面目：不是测试介入晚，而是任务排序和风险前置出了问题。这时候再讨论解决方案，团队会自动想到“把最不确定的技术难点排在迭代前期先做验证”，比“让测试提前介入”靠谱得多。

这就是我反复强调的一个点：回顾会要改进的是系统性问题，不是表面问题。表面问题的解决方案说出来都正确无比，但往往治标不治本。五个为什么不复杂，但它是撕掉表面答案、找到行为根源的利器。

5.3 回顾会的收尾：三个“停、做、测”

回顾会不能开成头脑风暴大会，必须收敛出行动项。我习惯用“停（Stop / 简化）— 做（Start / 继续加强）— 测（Try / 实验新方法）”三栏来收敛：

• 停：哪些行为/流程我们要收敛或停止？比如“停止在周五下午安排联调”。
• 做：哪些行为/流程我们保持并且要做得更彻底？比如“继续调研用户，但要更早引入”。
• 测：我们下一个迭代想尝试哪个新改进？比如“尝试把任务拆小到半天一个”。

这里有个容易踩的坑：一个回顾会总结出七八条行动项。我的经验是，每个迭代最多挑两到三个行动项，而且要明确谁负责、什么时候确认结果。人的行为改变需要时间和专注，行动项太多等于没有行动项。我会在下一个回顾会的第一件事就是检查上一个迭代的行动项完成情况——如果没完成，先讨论为什么没完成，再决定下一步，而不是继续叠加新的行动项。

5.4 回顾会的时间与形式：搞点花样，但别为了花样

回顾会的标准时间是一个小时，如果迭代是两周，一小时我觉得是底线，低于这个时间很难产生有效讨论。也有团队把回顾会和评审会连着开，上午评审、下午回顾，这样一次到齐，省时间，效果也不差。

关于形式，我见过帆船图、情绪曲线、Glad/Sad/Mad、KALM等十几种玩法。形式的本质是创造不同的讨论视角，偶尔换换花样能让团队保持新鲜感，但千万不要为了换花样把回顾会变成了手工课。如果你团队是第一次做回顾会，直接用最简单的“好、坏、改进”三张便签纸就足够了，先把流程跑起来，再逐步丰富方法。

6. 辅助性会议与机制设计：怎样让整条敏捷链路严丝合缝

规划会、站会、评审会、回顾会，是敏捷迭代的标准四会，但这四个会之间的衔接如果没设计好，中间就会出现大量灰色地带。这就像一台机器有四个核心部件，但传动轴没接上，整台机器还是转不起来。

6.1 产品代办梳理会：规划会的饲料工厂

前面我提到过梳理会需要单独开，这里再展开说。产品代办梳理会（Backlog Refinement / Grooming）的频率通常是每周一次，每次半小时到一小时，规模不需要全员参与，产品负责人、开发代表、关键技术人员参会即可。

梳理会要解决的核心问题是：让下一两个迭代可能需要做的需求，从“有”变成“清楚”。具体动作包括：

• 拆解大型需求——一个能撑三周的大需求，要在梳理会上拆成多个能支撑一周迭代的用户故事
• 补全验收标准——没有验收标准的故事，不开工
• 重新排序优先级——根据市场反馈、技术依赖、业务紧迫度，调整待办事项的先后顺序
• 淘汰过期需求——有些需求放了两三个月，业务背景可能已经变了，该删就删

我非常推荐每条用户故事都包含一个明确的价值描述格式，最简单的是“作为……我想要……以便……”。这个句式看似简单，但能逼着需求方去思考用户是谁、痛点是什么、价值在哪里。如果一个需求讲故事讲不出来，那大概率这个需求本身也是个伪需求。

6.2 迭代边界机制：发布的节奏感从哪里来

敏捷开发不是只盯着迭代内的四个会，迭代与迭代之间的衔接同样需要机制保障。我特别强调两个边界动作：迭代起点的“开工前检查”和迭代终点的“完成定义（Definition of Done，DoD）检查”。

开工前检查是指，迭代正式开始前，团队需要确认规划会输出的内容已经具备了开工条件。这一般是Scrum Master的重要职责之一——不要容忍“先做起来再说”的团队文化，因为没有明确的验收标准和可拆解的任务，开发过程中一定会陷入反复沟通和需求澄清的泥潭。

完成定义（DoD）则要明确一个用户故事做到什么程度才算“完成”。我见过最模糊的团队，说是做完了，结果是“代码写完了”，测试没跑、文档没写、还没部署到测试环境。所以我建议团队形成一个统一的DoD清单，比如：

• 代码已完成并通过代码评审
• 自动化测试通过，关键路径手动测试通过
• 功能已部署到测试环境/预生产环境
• 文档/注释已更新
• 验收标准逐条确认

DoD在规划会、评审会上都派得上用场。规划会上用来让团队对“完成”形成共识，评审会上用来确认交付物的完整性。

6.3 发布计划会：让迭代服务里程碑，而不是各自为战

迭代规划会管的是当下这一两个迭代，但如果你的项目周期长达三四个月，那还需要一个更宏观的节奏会——发布计划会（Release Planning）。这个会一般发生在项目启动或大版本规划阶段，目的是把整个发布周期拆成多个迭代，并为每个迭代设定一个粗略目标。

发布计划会不需要太细，因为细节在迭代规划会里补全。它的价值在于让团队和相关方对“大方向”有共识。常见做法是产品负责人把需求池按优先级、技术依赖、市场规模排序，团队给每个迭代分配一个主题，比如“迭代一：基础设施搭建”“迭代二：核心交易链路”“迭代三：体验优化与灰度”。有了这种分配，团队在单迭代规划会上就知道哪些需求该放进哪个迭代，而不是每两周才焦虑一次。

6.4 跨团队协同会：Scrum of Scrums

如果你的项目大到需要多个敏捷团队协同，那在四个标准会之外还必须有一个跨团队协调会，业内一般叫Scrum of Scrums。这个会不需要每个团队的每个成员都来，只需要每个团队派一名代表，通常是Scrum Master或技术负责人，每两三天碰一次，每次15到30分钟。

讨论的内容围绕团队之间的依赖和风险展开。不是各自汇报自己团队的进度，而是围绕一个核心问题：我们团队接下来要做的事情，有没有阻碍到别的团队？有没有依赖别人的交付？如果发现了跨团队的技术接口冲突或者时间依赖，就直接在这个会上解决，实在解决不了的升级到项目层。

我见过一个大项目，四个团队各干各的，集成测试的时候才发现接口对不上，前后返工了三周。后来强制推行Scrum of Scrums，类似的接口类问题基本在开发期就暴露并解决了。这个会看起来不起眼，但在多团队项目里价值极大。

7. 从会议到节奏：我这些年在推行敏捷会议时的几点体会

写到最后，我想把这些年实践中沉淀下来的几条原则，直接分享给正在或者准备推行敏捷会议的团队。

第一条，会议的频次和时长要服从于迭代节奏，而不是反过来。有些团队把站会、周会、月会、迭代会叠在一起，一周开了四五个会，反而没了开发的时间。如果你发现会议占用超过团队工作时间的15%，那一定是会议设计出了问题，要么砍掉，要么合并，要么缩小参与范围。

第二条，Scrum Master的核心工作不是催进度，而是保护和优化团队的注意力。具体到会议，就是严格控制时间盒、确保每个会都有明确输入和输出、会后及时跟进行动项。这个角色如果由技术负责人兼任，容易在评审会上冲进技术细节里出不来，所以每个会都要有意识地把自己抽离到“流程守护者”的视角。

第三条，会议是敏捷文化的放大器。你的团队是不是真的透明、是否真的拥抱反馈、是否真的敢于暴露问题，不用看公司墙上贴了什么敏捷标语，就看站会上大家敢不敢说阻碍、评审会上相关方敢不敢挑毛病、回顾会上团队敢不敢自我批评。机制可以搭得很快，但这三种勇气需要时间培养。作为推进者，你在每一次会议上的反应，都在告诉团队“这里安全”或者“这里不安全”。

还有一个小技巧，是我后期才真正用起来的：每次会议结束前，用最后两分钟让大家各自说一句“今天这个会，你带走了什么”。不需要谈感受，只需要说一个收获、一个行动项或者一个疑问。就这么简单的一句话，能逼着每个人在会议中保持专注，也能让会议偷懒的情况大幅减少。如果你觉得团队开会总是走神，不妨试试这个收尾动作。

敏捷会议不是越多越好，也不是越少越好，而是要让每一个会议都承担明确职责，让团队在合理的节奏里持续交付价值、持续发现问题、持续改进方法。这套流程跑顺之后，你会很明显地感觉到，团队的交付速度提升了，返工减少了，跨角色之间的信息损耗降低了。工具可以慢慢换，流程可以持续调，但会议这个节奏器，一定要先立起来。