第十二章 敏捷不是快

一

云智科技要搞"敏捷转型"了。

消息是在周一的全员大会上宣布的。张总——公司的技术副总裁，一个头发花白但精力充沛的中年人——站在台上，用激昂的语气说：

"各位，市场竞争越来越激烈，客户的需求变化越来越快。我们必须提高交付速度！从本月开始，全公司推行敏捷开发。敏捷的核心就是一个字——快！快速迭代，快速交付，快速响应！"

他在大屏幕上翻到一页 PPT，上面写着：

敏捷 = 快 - Sprint 周期从两周缩短为一周 - 需求评审和设计评审合并，节省时间 - 减少文档，多写代码 - 目标：交付速度提升 50%

台下响起了稀稀拉拉的掌声。

王志远坐在后排，看了一眼旁边的赵北辰。赵北辰的表情很微妙——嘴角微微抽动了一下，像是想笑又忍住了。

散会后，回到工位上，赵北辰对着电脑屏幕摇了摇头，自言自语了一句：

"又来了。"

二

"敏捷转型"的第一周，效果立竿见影——但不是好的效果。

Sprint 周期从两周缩短为一周，意味着每周都要做 Sprint Planning、Sprint Review、Sprint Retrospective。光是这三个会议就占了大半天。再加上每天的站会、需求评审、设计评审（虽然张总说要合并，但实际上根本合并不了），一周五天有两天在开会。

剩下三天写代码，但需求量没有减少——因为张总说了"交付速度提升 50%"，产品经理李想只好往每个 Sprint 里塞更多的需求。

结果就是：大家疯狂加班，代码质量直线下降，bug 数量翻了一倍。

"减少文档，多写代码"这条更离谱。设计文档不写了，直接开始编码。结果两个开发同时做同一个模块的不同功能，因为没有设计文档对齐，接口定义冲突了，联调的时候才发现，又花了两天返工。

王志远在第一周的 Retrospective 上写了一张便利贴：

😐 一周的 Sprint 太短了，光开会就占了两天，实际编码时间不够。

他不是唯一一个这么写的。白板上的"可以改进"列贴满了类似的便利贴。

但周旋经理看了看，说了一句："张总的决定，我们先执行。给一个月时间适应。"

三

第二周更糟糕。

马德华在站会上说："我昨天的任务没做完，因为下午在开需求评审会。今天的任务估计也做不完，因为上午要开设计评审会。"

苏薇直接说："一周的 Sprint 根本不够用。需求拆不到那么细，硬拆就没意义了，不拆就做不完，每次都延期。"

陈锐难得说了一句实话："我上周的 PR 没有人 Review，因为大家都在赶自己的任务。代码质量在下降。"

赵北辰一直没说话。他在站会上听完所有人的反馈，然后说了一句："今天下午我约了张总，聊聊敏捷转型的事情。有什么想法，可以跟我说。"

下午，赵北辰去了张总的办公室。

没有人知道他们聊了什么，但第二天，张总在管理层群里发了一条消息：

各团队的 Sprint 周期可以根据实际情况调整，不强制一周。但要保持迭代节奏，不能回到瀑布模式。

赵北辰把 Sprint 周期调回了两周。

四

那天下班后，王志远在茶水间遇到了赵北辰。

"赵哥，你跟张总说了什么？他怎么突然改主意了？"

赵北辰倒了一杯茶，靠在饮水机旁边："我跟他说了一个故事。"

"什么故事？"

"2001 年，十七个软件开发者在美国犹他州的一个滑雪度假村开了一个会。他们来自不同的公司，用不同的开发方法——XP、Scrum、DSDM、Crystal——但都有一个共同的感受：传统的瀑布式开发太笨重了，需要一种更灵活的方式。"

"他们讨论了两天，最后写了一份只有 68 个英文单词的文档。这份文档后来改变了整个软件行业。"

"敏捷宣言？"王志远说。

"对。"赵北辰点头。"你知道敏捷宣言的四条价值观是什么吗？"

王志远想了想："个体和互动高于流程和工具？"

"对，这是第一条。四条完整的是：

1. 个体和互动 高于 流程和工具
2. 工作的软件 高于 详尽的文档
3. 客户合作 高于 合同谈判
4. 响应变化 高于 遵循计划

"注意，宣言说的是'高于'，不是'取代'。右边的东西也有价值，但左边的更重要。"

他喝了一口茶："张总把'工作的软件高于详尽的文档'理解成了'不写文档'，把'响应变化'理解成了'快'。这是对敏捷最常见的误解。"

五

"那敏捷到底是个啥？"王志远问。

赵北辰想了想，说："敏捷啊，说白了不是让你跑得快，是让你转弯转得灵。"

他在茶水间的白板上（是的，云智科技的茶水间有一块白板，程序员的茶水间都有白板）画了一个对比：

瀑布模式：
需求 ──→ 设计 ──→ 编码 ──→ 测试 ──→ 上线
│←──────────── 6 个月 ──────────────→│
（6 个月后才知道做的对不对）

敏捷模式：
Sprint 1: 需求→设计→编码→测试→交付
Sprint 2: 需求→设计→编码→测试→交付
Sprint 3: 需求→设计→编码→测试→交付
│←─ 2周 ─→│←─ 2周 ─→│←─ 2周 ─→│
（每 2 周就能得到反馈，及时调整方向）

"瀑布模式的问题是：你花六个月做了一个东西，上线后才发现客户不想要这个。六个月的努力白费了。"

"敏捷模式的好处是：每两周交付一个可用的增量，客户看了之后给反馈，你根据反馈调整下一个 Sprint 的方向。即使方向错了，最多浪费两周，不会浪费六个月。"

"所以敏捷的核心压根不是'快'，是'别跑偏了还不知道'。你隔两周就让客户看一眼，方向不对赶紧掉头，总比闷头跑半年发现跑反了强。"

王志远想了想："那张总说的'交付速度提升 50%'呢？"

赵北辰笑了："敏捷可没承诺让你写代码更快。它承诺的是——你做的东西更靠谱。两周确认一次方向，不至于在错路上狂奔半年。最后看起来好像快了？那是因为返工少了，不是因为手速快了。"

六

"那 Scrum 呢？Scrum 和敏捷是什么关系？"王志远问。

"敏捷是一种理念，Scrum 是实现这种理念的一个框架。"赵北辰说。"就像'健康饮食'是理念，'地中海饮食法'是具体的方法。"

他在白板上画了 Scrum 的 3-5-3 框架：

Scrum 框架：3-5-3

3 个角色：
├── Product Owner（PO）：决定做什么，管理 Product Backlog
├── Scrum Master（SM）：确保 Scrum 流程顺畅，移除障碍
└── Development Team：决定怎么做，自组织

5 个事件：
├── Sprint：固定时长的迭代（通常 2 周）
├── Sprint Planning：Sprint 开始时，确定做什么、怎么做
├── Daily Scrum：每天 15 分钟，同步进度
├── Sprint Review：Sprint 结束时，展示成果，收集反馈
└── Sprint Retrospective：Sprint 结束后，团队反思改进

3 个工件：
├── Product Backlog：所有待做的需求（PO 维护）
├── Sprint Backlog：本次 Sprint 要做的需求（团队承诺）
└── Increment：Sprint 结束时交付的可用产品增量

"我们组一直在用 Scrum，你已经体验了大部分。但有一个角色我们一直缺失——Scrum Master。"

"Scrum Master 是干什么的？"

"Scrum Master 不是项目经理，不是技术负责人。他的职责是确保 Scrum 流程被正确执行，移除团队的障碍。比如，如果团队发现一周的 Sprint 不合理，Scrum Master 应该去跟管理层沟通，而不是让团队硬扛。"

"那我们组的 Scrum Master 是谁？"

赵北辰笑了："理论上应该有一个专职的。但咱组一直是我兼着干。今天去找张总掰扯，就是 Scrum Master 该干的活儿——帮团队把路上的石头搬开。"

七

"敏捷宣言还有十二条原则。"赵北辰说。"我不一条一条讲了，你自己去看。但有几条我觉得特别重要：

第一条：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

"注意这俩字：'有价值的'。不是做得越多越好，做十个没人用的功能，还不如踏踏实实做一个大家真需要的。"

第三条：经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

"注意：'可工作的'。不是半成品，不是 demo，是真正可以用的软件。每个 Sprint 结束时交付的增量，应该是可以上线的。"

第八条：敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

"这条啊，张总最该听。"赵北辰说。"敏捷可不是让大家拼命加班赶进度。你得找到一个跑得动、跑得久的节奏。Sprint 一个接一个地加班，要么是活儿塞太多了，要么是估算不靠谱，要么是流程有毛病。人又不是机器，跑太猛迟早趴窝。"

第十二条：团队定期地反思如何能提高成效，并依此调整自身的举止表现。

"这就是 Retrospective 的理论基础。敏捷不是一成不变的——团队要不断反思和改进。如果发现一周的 Sprint 不合适，就改回两周。如果发现站会太长，就想办法缩短。敏捷本身也要敏捷。"

八

王志远听完，觉得自己之前对敏捷的理解太浅了。

他以为敏捷就是 Scrum，Scrum 就是站会 + Sprint + 看板。但实际上，Scrum 只是一个框架，敏捷是一种思维方式。

框架可以照搬，但思维方式需要理解和内化。

他想起张总在全员大会上说的"敏捷 = 快"，突然觉得这个误解很有代表性。很多公司推行敏捷转型，最后变成了"形式上的敏捷"——有站会、有 Sprint、有看板，但本质上还是瀑布式的思维：需求一次性确定，计划不允许变化，交付日期不能调整。

这种"假敏捷"比不敏捷更糟糕——因为它增加了会议和流程的开销，却没有获得敏捷的好处。

赵北辰好像看出了他在想什么，说了一句："敏捷转型这事儿，最难的不是改流程，是改脑子。流程一天就能改，脑子嘛……可能得一年。"

九

那天晚上，王志远打开电脑，搜索了"敏捷宣言"的原文。

十七个签名者的名字列在页面底部。他一个一个地看过去——Kent Beck、Martin Fowler、Robert C. Martin、Ken Schwaber、Jeff Sutherland……

这些名字他在各种技术书籍里见过。原来他们不只是写书的人，还是改变了整个行业工作方式的人。

他想起赵北辰今天做的事——去找张总沟通，硬是把"一周 Sprint"这个拍脑袋的决定给顶了回去。这才是真正的 Scrum Master，不是照本宣科念流程，而是敢替团队挡子弹。

软件工程不只是写代码。它是一群人在不确定的世界里，试图找到一种更好的协作方式。代码是工具，协作才是核心。

:::{admonition} 小胖的笔记 :class: tip

本章知识卡片：敏捷开发

1. 敏捷宣言（Agile Manifesto, 2001）

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

常见误解：

2. 敏捷十二原则（精选）

3. Scrum 框架详解（3-5-3）

3 个角色：

5 个事件：

3 个工件：

4. 瀑布 vs 敏捷

瀑布：做完再验证（风险后置）
需求 ──→ 设计 ──→ 编码 ──→ 测试 ──→ 上线
                                      ↑
                              6个月后才知道对不对

敏捷：边做边验证（风险前置）
[Sprint 1] → 反馈 → [Sprint 2] → 反馈 → [Sprint 3]
每 2 周验证一次方向，及时调整

核心区别：敏捷通过"短反馈循环"降低风险，不是通过"加速"降低风险。

:::