软件项目开发全流程 · 第 17 课 · 团队协作机制：敏捷与 Scrum

1、敏捷不是"站会 + 看板 + 故事点"

很多团队说"我们在做敏捷"，实际做的是：

• 每天早上站 15 分钟，轮流说"昨天做了啥、今天做啥"。
• 墙上贴一板子便利贴。
• 每个任务估个"故事点"。

然后就没了。这不是敏捷，这是敏捷的"仪式外壳"。

《敏捷宣言》原文有四句话：

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

注意措辞："高于"不是说右边没价值，而是左边更重要。 敏捷的本质是在不确定中，用短周期迭代 + 快速反馈来降低风险，而不是一套要打卡的流程。

本课解决：

1. 敏捷到底想解决什么问题？
2. 那些"仪式"（站会、看板、迭代、回顾）各自的真实目的是什么？
3. 前 16 课的工程实践（Git/PR/CI/TDD）怎么和敏捷拼在一起？

2、为什么需要敏捷：不确定性

瀑布模型假设需求是清楚的、不变的：

需求 → 设计 → 开发 → 测试 → 交付       （一次走完，中途不回头）

它适合需求明确、变更少的项目（如航天、某些合规系统）。但大多数产品面对的是：

• 需求在变（用户自己也不知道想要什么）。
• 市场在变（做完可能就过时了）。
• 技术在变。

敏捷的回应：别赌"一次做对"，改成小步快跑 + 持续反馈：

① 做一小块（1~2 周） → ② 给用户看 → ③ 听反馈 → ④ 调整 → 回到 ①

核心是缩短"从想法到反馈"的距离。 做得对不对，越早让真实用户告诉你越好——这是第 1 课"迭代"思想的具体落地。

3、Scrum 的角色与事件：各是干什么的

Scrum 是最流行的敏捷框架。它有 3 个角色、5 个事件、3 个产出物。

三个角色

常见误解：SM 不是"催进度的人"，而是帮团队排除障碍、改进流程的人。

五个事件

站会的真正目的：不是让老板听汇报，而是让团队自己发现"谁被卡住了、要不要帮忙"。所以站会应该是开发团队内部的，不是对上级的述职。

回顾会的真正目的：回答"我们怎么变得更好"。产出应该是 1~2 条可执行的改进项，下个迭代跟进——不然就是走过场。

三个产出物

• 产品待办列表（Product Backlog）：PO 管，按价值排序的"想做的事"，持续演进。
• Sprint 待办列表（Sprint Backlog）：本轮要做的子集 + 拆解后的任务。
• 增量（Increment）：本轮结束时可用的、符合"完成定义"的产品增量。

"完成"要有明确定义（Definition of Done）：是"写完代码"就叫完成，还是"代码 + 测试 + 评审 + 通过 CI + 文档"才叫完成？团队必须说清楚，否则"完成 80%"永远做不完（呼应第 4 课与第 23 课）。

4、看板（Kanban）：另一条敏捷路径

Scrum 是按迭代（时间盒）组织的；看板是按流动组织的。

看板的三条实践：

1. 可视化流程：把工作画在板上。
2. 限制在制品（WIP，Work In Progress）：每一列最多放 N 张卡，满了就不许再拉新任务。
3. 管理流动：关注每个任务的"流动时间"，找瓶颈。

┌─────────┬─────────┬─────────┬─────────┐
│ 待办    │ 开发中  │ 评审中  │ 完成    │
│ (不限)  │ (WIP:3) │ (WIP:2) │         │
├─────────┼─────────┼─────────┼─────────┤
│ 卡A     │ 卡D     │ 卡G     │ 卡J     │
│ 卡B     │ 卡E     │ 卡H     │         │
│ 卡C     │ 卡F     │         │         │
└─────────┴─────────┴─────────┴─────────┘

限制 WIP 是最反直觉、也最有用的一条：

一列卡住 5 件事同时做 → 每件要等 5 天才推进一点 → 什么都"快完成了"但什么都交不出。
限制到 2 件 → 集中做完 → 交付更快。

为什么？ 因为切换任务有巨大成本（上下文切换、多任务并行导致等待）。"同时做很多事"是交付速度的敌人。

Scrum 还是看板？

别教条：很多团队是"Scrum 的迭代 + 看板的 WIP 限制"混着用。框架服务于人，不是人服务于框架。

5、敏捷实践与前面课程的拼接

敏捷不是孤立的，前 16 课的东西正好是它的工程底座：

┌──────────────────── 敏捷的「工作方式」层 ────────────────────┐
│  迭代计划 → 站会 → 开发 → 评审 → 回顾     （本课）           │
└──────────────────────────┬──────────────────────────────────┘
                           │ 需要这些工程实践支撑
┌──────────────────────────▼──────────────────────────────────┐
│  用户故事 / 验收标准      （第 6、7 课）                      │
│  Git 分支与 PR 流程        （第 12、13 课）                    │
│  编码规范与静态检查        （第 14 课）                        │
│  TDD 与测试               （第 15、19 课）                    │
│  CI 自动验证              （第 16 课）                        │
│  小步提交、可发布主干       （贯穿）                          │
└─────────────────────────────────────────────────────────────┘

关键洞察：

没有工程实践的敏捷，只是"快速地把 bug 交付出去"。

迭代要 1~2 周就能交付可用增量，前提是代码随时可构建、可测试、可发布——而这正是 Git 流程 + CI + 自动化测试给你的。敏捷的"快"，是靠工程纪律换来的，不是靠取消纪律换来的。

反过来，CI/TDD 等实践没有敏捷的迭代节奏，也容易变成"为了自动化而自动化"。两者是配套的。

6、规模化：多个团队一起敏捷

一个团队用 Scrum 很顺，十个团队怎么办？规模化敏捷（SAFe、LeSS、Spotify 模型等）试图解决跨团队协调。

对大多数团队的建议：

• 别急着上规模化框架。SAFe 之类很重，小团队用了往往官僚化。
• 先做好一个团队：一个团队跑通迭代 + 工程实践，价值远超十个团队跑流程。
• 跨团队靠"接口"协调：团队间定义清晰的服务契约（第 9 课的接口契约），而不是靠无数同步会议。

康威定律：系统的架构会模仿组织的沟通结构。所以组织怎么分组，系统就会长成什么样——想改架构，有时得先改团队划分（这也解释了微服务与团队边界的关系）。想深入了解可延伸阅读。

7、常见误区与反模式

关于故事点：它是估算相对工作量的（第 5 课的规划扑克），用途是团队内部排期，绝不能变成考核指标——一旦和绩效挂钩，团队必然虚报，估算就废了。

8、动手实验 🎯

任务：为一支 5 人团队设计一套落地的敏捷工作方式。

1. 选一种框架（Scrum / 看板 / 混合），说明为什么适合你的场景。
2. 画出你的看板列，并为"开发中/评审中"设 WIP 限制，说明每个数字的理由。
3. 写一份 Definition of Done（至少 6 条：代码、测试、评审、CI、文档、可部署……）。
4. 设计站会与回顾会的简短议程（站会 3 个问题；回顾会产出什么格式的改进项）。
5. 把前 16 课的实践映射到流程里：画一张图，标出"用户故事→分支→PR→CI→评审→合并"每一步用了哪一课的方法。
6. 找一个反模式：从第 7 节的表里挑一个你见过的，写出它的问题和你的改法。
7. 反思：你所在的团队（或课程项目）最该先改哪一条？为什么？

做完这步，你手里就有了一套完整的工作方式——下一课补齐敏捷里最容易被牺牲、却最致命的一环：重构与技术债。

9、今天你带走的三句话

1. 敏捷的本质是"短反馈"，不是站会+看板+故事点的仪式；框架服务于人，别教条。
2. 限制 WIP、明确 DoD、保护迭代：这三点比任何工具都重要。
3. 敏捷的快靠工程纪律换——没有 CI、测试、PR 流程的"敏捷"，只是快速交付 bug。

下一课讲重构与技术债——敏捷要持续快速，就必须持续还债。