第四章：敏捷开发与效率提升：Scrum框架的核心实践、看板方法、迭代节奏的设定
说到产业化开发中的效率提升，我第一个想到的就是敏捷。说实话，早些年我做传统瀑布模型的时候，最怕的就是需求变更。一个需求改下来，文档要重写，设计要重来，测试用例要推翻。那叫一个痛苦。
后来我接触了敏捷开发，才真正体会到什么叫「拥抱变化」。今天我们就聊聊敏捷开发中最实用的两个工具：Scrum和看板。嗯，这两个东西，说白了就是帮你把混乱的开发过程变得有序、可控。
4.1 Scrum框架的核心实践
Scrum不是一种方法论，它是一套轻量级的框架。我个人的理解是，它给了你一个「最小可行管理结构」。你不需要搞一堆复杂的流程，只需要抓住几个关键点。
4.1.1 三个角色
- 产品负责人（PO）：负责定义需求，排优先级。说白了就是「决定做什么」的人。
- Scrum Master：不是项目经理，是服务型领导。帮团队扫清障碍，确保流程顺畅。
- 开发团队：自组织的，通常5-9人。没人告诉你具体怎么做，你们自己商量。
关键点：Scrum Master和传统项目经理最大的区别是——他不分配任务，他只帮团队「自己分配任务」。我在项目中遇到过很多项目经理转型Scrum Master时很不适应，总想插手。嗯，这个习惯得改。
4.1.2 五个事件
Scrum的节奏感很强，靠五个固定事件来驱动。你想想看，如果没有这些事件，团队很容易陷入「一直在做，但不知道做到哪了」的状态。
| 事件 | 时间限制 | 目的 |
|---|---|---|
| Sprint计划会 | 2小时/周 | 确定本轮迭代要做什么 |
| 每日站会 | 15分钟 | 同步进度，暴露问题 |
| Sprint评审会 | 1小时/周 | 展示成果，收集反馈 |
| Sprint回顾会 | 1.5小时/周 | 复盘改进，优化流程 |
| 待办事项梳理 | 不超过Sprint的10% | 细化需求，估算工作量 |
我记得有一次，团队刚开始用Scrum，每日站会开了40分钟，变成了「汇报大会」。后来我强制要求每个人只说三件事：昨天做了什么、今天打算做什么、遇到了什么障碍。15分钟搞定。为什么会这样？因为站会的核心是「同步」，不是「汇报」。
4.1.3 三个工件
- 产品待办列表：所有需求的集合，由PO维护优先级。
- Sprint待办列表：本轮迭代要完成的任务，团队自己认领。
- 增量：每个Sprint结束时交付的可用的产品功能。
我的习惯：产品待办列表一定要保持「DEEP」原则——Detailed appropriately（适当详细）、Estimated（已估算）、Emergent（涌现的）、Prioritized（已排优先级）。别把列表搞成几百条，没人看得完。
4.2 看板方法
看板方法比Scrum更轻量。它不规定角色、不规定事件，只给你一个核心工具——看板。说白了，就是把工作流可视化。
4.2.1 看板的五个核心原则
- 可视化工作流：把任务写在卡片上，贴在白板上。每个人都能看到全局。
- 限制在制品（WIP）：每个列最多放几个任务。超过就停，先完成再开始新的。
- 管理流动：关注任务从「待办」到「完成」的流动速度。
- 明确流程规则：比如「测试通过才能移到完成列」。
- 持续改进：定期回顾，优化流程。
我曾经在一个硬件团队推行看板，一开始大家觉得「贴卡片太幼稚了」。结果用了两周，团队自己就发现了瓶颈——测试环节总是堵着。为什么？因为开发人员只管写代码，测试人员忙不过来。后来我们限制了开发列的在制品数量，倒逼开发人员帮测试做自动化。效率提升了一倍。
4.2.2 看板 vs Scrum
| 维度 | Scrum | 看板 |
|---|---|---|
| 迭代周期 | 固定时间盒（如2周） | 持续流动 |
| 角色 | 明确定义 | 无强制要求 |
| 变更 | Sprint内不允许 | 随时可以 |
| 度量 | 速度（Velocity） | 前置时间、吞吐量 |
| 适用场景 | 需求相对稳定 | 需求频繁变化 |
避坑指南：我曾经见过一个团队把Scrum和看板混着用，结果搞出了「四不像」。我的建议是——要么纯Scrum，要么纯看板。如果非要结合，可以用Scrum的节奏+看板的可视化，但别把两套规则都套上。
4.3 迭代节奏的设定
迭代节奏，说白了就是「多久交付一次」。这个节奏设得好，团队效率翻倍；设得不好，大家累死还不出活。
4.3.1 迭代周期的选择
常见的迭代周期有1周、2周、3周、4周。我个人最推荐2周。为什么？
- 1周太短：刚开完计划会，还没写几行代码，又要评审了。团队压力大。
- 4周太长：反馈周期太长，容易走偏。你想想看，一个月后才发现方向错了，那得多浪费。
- 2周刚刚好：有足够的时间做有价值的功能，又能快速获得反馈。
我记得有一个项目，客户要求每两周交付一次。刚开始团队觉得「怎么可能做得到」。后来我们拆小了需求，每个迭代只做2-3个用户故事。结果呢？半年下来，交付了12个版本，客户满意度极高。
4.3.2 如何设定迭代节奏
- 根据团队成熟度调整：新团队先用3周，稳定后缩短到2周。
- 固定发布日：比如每周五下午发布。雷打不动。
- 预留缓冲：每个迭代留出20%的时间处理突发问题。
- 度量并调整：用速度图（Burndown Chart）跟踪进度，发现节奏不对就调。
我的习惯：每个迭代的第一天做计划，最后一天做评审和回顾。中间的日子，除了每日站会，尽量不打断团队。你会发现，团队最怕的不是工作量大，而是「被打断」。
4.4 知识体系图：敏捷开发核心逻辑
下面这张图展示了Scrum、看板和迭代节奏之间的关系。你可以看到，三者不是孤立的，而是相互支撑的。
你看，Scrum提供了节奏和结构，看板让工作流透明化，迭代节奏则是两者的粘合剂。三者结合，才能实现真正的效率提升。
总结一下：敏捷开发不是银弹，但它给了你一套「快速试错、持续改进」的机制。我做了十几年产业化开发，最大的体会就是——没有完美的流程，只有不断优化的流程。Scrum和看板只是工具，关键是你怎么用。