本文适合：被瀑布流程拖垮的团队、想落地敏捷但"走形式"的组织、好奇AI时代敏捷怎么变的人。
你将收获：敏捷宣言的4组对比与12条原则、Scrum三步流程实战拆解、敏捷常见问题与解法、AI时代敏捷的BMad方法、开源与敏捷的哲学碰撞。
写在前面
第五章讲了11种团队模式和6种开发流程，其中"渐进交付"已经触及敏捷的边缘。第六章正式深入敏捷流程------这大概是全书被讨论最多、误解也最多的一章。
很多人一听"敏捷"就想到"快"。但读完这一章才发现，敏捷的核心不是快，而是响应变化。快只是结果，响应变化才是手段。
第四版在这一章新增了6.4 AI时代的敏捷流程------BMad方法 和6.6 开源与敏捷：协作哲学的冲突与融合，这两个新增节直接把敏捷从"2010年代的方法论"拉到了"AI时代的前沿讨论"。
01 | 敏捷流程简介：价值观优先于流程
1.1 敏捷宣言：4组对比
敏捷的起点是2001年的《敏捷宣言》，核心是4组价值对比：
|--------------|--------------|-------------------|
| 现有做法 | 敏捷做法 | 我的理解 |
| 流程和工具 | 个人和交流 | 工具是死的，人是活的 |
| 完备的文档 | 可用的软件 | 文档是手段，软件才是目的 |
| 为合同谈判 | 与客户合作 | 合同是底线，合作才能共赢 |
| 执行原定计划 | 响应变化 | 计划赶不上变化，拥抱变化才是竞争力 |
注意：敏捷宣言说的是"右边的价值高于左边的"，不是"左边不重要"。文档还是要写，流程还是要定，但优先级要让位于人和可用软件。
1.2 敏捷12条原则
书中列出了12条原则，我按"核心关注点"做了分组：
交付相关：
1.尽早并持续地交付有价值的软件
2.经常发布可用软件，间隔能短则短
3.可用的软件是衡量项目进展的主要指标
团队相关：
1.业务人员和开发人员每天共同工作
2.以有进取心的人为核心，充分信任
3.面对面交流是最有效的沟通方式
4.自我管理的团队才能创造优秀的架构和设计
质量相关：
1.保持可持续发展步调
2.持续关注技术和设计
3.保持简明------尽可能简化工作量
改进相关：
1.敏捷流程欢迎需求变化，利用变化提高竞争优势
2.时时总结如何提高团队效率，并付诸行动
1.3 Scrum三步流程
敏捷最流行的实现是Scrum，核心三步：
|--------------------|-------------------|------------|
| 步骤 | 做什么 | 类比 |
| 1. Product Backlog | 列出所有需要做的事情，按优先级排序 | 待办清单 |
| 2. Sprint Backlog | 选出当前冲刺要做的事 | 本周计划 |
| 3. Sprint（冲刺） | 在固定时间内（通常1-4周）完成 | 闭关冲刺 |
关键点：团队成员自己估计和分配任务，不是领导派活。这极大激发能动性。
一句话提炼
敏捷不是"做得快"，而是"快速响应变化"。它的底层逻辑是------计划赶不上变化，与其抗拒变化，不如拥抱变化。
02 | 敏捷流程的问题和解法
敏捷不是银弹，落地时会遇到很多问题。书中给出了几个常见问题：
2.1 需求依赖问题
问题：各个需求之间有复杂的依赖关系，不能只按优先级排序。
解法：除了优先级，还要考虑依赖关系。A需求依赖B需求，那B必须先做。这需要技术负责人参与排序，不能只靠PM拍板。
2.2 任务分解问题
问题：把产品层级的需求逐步细化到技术实现层面，需要很强的技术能力和沟通能力。
解法：让有经验的工程师参与分解，不能只靠PM写story。故事点和估算必须由做的人来定。
2.3 每日例会
问题：每日站会容易变成"流水账汇报"------每个人说自己做了什么，但没人关注问题和阻塞。
解法 ：每日站会只回答三个问题------昨天做了什么、今天要做什么、有什么阻塞。第三个问题才是核心。
2.4 敏捷的经验教训
书中列举了8条经验教训，我挑最有感触的几条：
|------------------------|----------------|
| 经验教训 | 我的理解 |
| 敏捷宣言是优先级，不是圣旨 | 不必教条争论，灵活运用 |
| Scrum Master不是官，是沟通者 | 没有行政权力，靠影响力推动 |
| 估计不是合同 | 领导不要把估算当承诺来追责 |
| 不要和管理层谈"流程"，他们只关心"结果" | 跟老板谈交付，不谈Scrum |
| 大型团队、跨地区团队中Scrum没有完美答案 | 敏捷在规模放大时会变形 |
我的踩坑案例
我们团队试过Scrum，结果每日站会开了三个月就流于形式------每个人说一分钟"昨天修了两个bug"，然后散会。没人提阻塞，没人讨论方案，站会变成了"打卡"。
后来我们做了两个调整：一是站会改名为"阻塞会"，只讨论阻塞和需要协调的事；二是估算不再让PM做，而是开发自己用计划扑克估。这两个改变让敏捷从"走形式"变成了"真有用"。
敏捷最大的敌人不是瀑布，而是"走形式的假敏捷"。
一句话提炼
敏捷落地失败，90%不是方法的问题，而是"走形式"的问题。每日站会变打卡、估算变合同、Scrum Master变包工头------形式在，灵魂没了。
03 | 敏捷流程的团队与哲学
3.1 敏捷团队要做三个改变
书中指出，一个团队要从传统模式转为敏捷，需要：
1.自我管理------团队自己决定怎么完成任务
2.自我组织------团队自己分配任务、排优先级
3.多功能型------团队成员具备多种技能，不分工太细
这三点的核心是把决策权从管理层下放到一线。但现实中，很多管理者放不下------名义上敏捷，实际上还是"领导说做什么就做什么"。
3.2 敏捷的哲学
敏捷背后有一套哲学假设：
· 人是可以被信任的------所以不需要严格的流程监控
· 变化是常态------所以不需要完美的预先设计
· 沟通比文档有效------所以面对面优于写文档
· 小步快跑比一步到位安全------所以迭代优于瀑布
这套假设在大多数软件项目中成立，但在某些场景下不成立------比如航天、医疗、核电等对安全性要求极高的领域。书中提到一个案例：用敏捷方法开发登月火箭控制程序，出了严重事故。 这些场景需要的是"重流程、重验证"，敏捷的"拥抱变化"在这里是致命的。
一句话提炼
敏捷的前提是信任和放权。没有信任的敏捷就是"穿着敏捷外衣的瀑布"。
04 | AI时代的敏捷流程------BMad方法（第四版新增）
这是第四版最具前瞻性的新增内容。
4.1 敏捷遇到了什么新问题
AI时代，软件开发的速度和模式都在变化。AI辅助编码让"写代码"更快了，但需求变化也更频繁了------客户看到AI能做更多事，期望值随之上升。
传统的Scrum两周冲刺在AI时代显得太慢了。如果AI能在一天内生成一个功能原型，为什么还要等两周才能看到结果？
4.2 BMad方法的核心思路
第四版引入了BMad方法，这是针对AI时代的敏捷流程调整。核心理念：
· 更短的迭代周期------从两周冲刺缩短到天级别甚至小时级别
· AI作为团队角色------不只是工具，而是参与流程的"成员"
· 人机协作的估算------AI可以快速估算工作量，人做最终判断
· 快速验证替代详细规划------用AI生成原型来验证需求，替代写story
4.3 我的实战体会
做交付项目这一年，我深有感触。以前一个功能从需求到上线，走Scrum至少两周。现在用AI辅助，一天就能出原型让客户看。客户看完说"方向不对"，我们第二天就能改------这在传统Scrum里要等到下个冲刺。
AI没有改变敏捷的价值观（响应变化），但改变了敏捷的节奏（从周到天）。 BMad方法本质上是把敏捷的"小步快跑"推到了极致------步子更小，跑得更快。
但也要警惕：AI生成速度快，不等于质量有保障。越快的迭代越需要代码审查和测试------这正是第四章讲的"代码复审"和第二章讲的"单元测试"的价值。
一句话提炼
AI时代敏捷的本质没变------还是响应变化。变的是节奏------从周到天，从天到小时。但速度越快越要守住质量底线。
05 | 开源与敏捷：协作哲学的冲突与融合（第四版新增）
5.1 冲突在哪
开源和敏捷看似都"拥抱变化、快速迭代"，但哲学上有冲突：
|------------|---------------------|----------------------------------|
| 维度 | 敏捷 | 开源 |
| 决策方式 | 团队共识、Scrum Master协调 | 社区讨论、maintainer决定 |
| 迭代节奏 | 固定冲刺周期（1-4周） | 没有固定周期，看贡献者节奏 |
| 人员构成 | 固定团队、有雇佣关系 | 流动贡献者、无雇佣关系 |
| 文档要求 | 轻文档 | 重文档（README、CONTRIBUTING、Issue模板） |
| 变更管理 | Sprint内冻结需求 | 随时提PR，随时合并 |
5.2 融合的可能
书中讨论了两者能否融合。结论是：不是非此即彼，而是取长补短。
敏捷团队可以学习开源的"文档即流程"------用清晰的CONTRIBUTING.md和PR模板替代部分会议
开源项目可以学习敏捷的"定期回顾"------定期反思流程是否高效
两者都重视代码审查------这是共同的基石
一句话提炼
敏捷靠冲刺节奏驱动协作，开源靠文档和代码审查驱动协作。两者殊途同归------都是让变化可控、让协作透明。
06 | 案例分析：垂直切片
书中用"超算项目"做了案例分析，核心概念是垂直切片：
不是横向切片（先把所有模块的基础层写完，再写业务层，再写UI层），而是纵向切一刀------从UI到底层，先做一个最小的端到端可用功能。
垂直切片的好处：每个切片都是一个可演示的完整功能，客户能立刻看到价值。这比"底层做完了但没有界面给客户看"好得多。
我的实战感悟
我们的项目之前就是"横切"------先做数据库设计，再写后端API，最后做前端。结果数据库和API做了三周，客户什么都没看到，急得天天问进度。后来改成"竖切"------先做一个最小功能从UI到数据库全通，客户看到界面后立刻提了反馈，我们及时调整了设计。
横切让客户等三周，竖切让客户第一天就看到东西。敏捷的"尽早交付"本质上就是竖切思维。
一句话提炼
垂直切片是敏捷的战术落地------先做一条端到端的窄功能，让客户看到价值，再横向扩展。
干货复盘
|----------------|-------------------------------|--------------|
| 本章核心概念 | 一句话理解 | 常见误区 |
| 敏捷宣言 | 响应变化高于执行计划 | "敏捷就是快" |
| Scrum三步 | Backlog→Sprint Backlog→Sprint | 站会变打卡 |
| 敏捷问题与解法 | 依赖排序、任务分解、阻塞会 | 估算变合同 |
| BMad方法（新增） | AI让敏捷节奏从周到天 | AI快就不需要审查 |
| 开源与敏捷（新增） | 冲刺驱动vs文档驱动，取长补短 | "开源不需要流程" |
| 垂直切片 | 先竖切一条端到端功能 | 横切做完底层客户等三周 |
本章 最大收获： 敏捷的本质不是"快"，而是"响应变化"。敏捷落地失败的大多数原因不是方法不对，而是"走形式"------站会变打卡、估算变合同、Scrum Master变包工头。AI时代的BMad方法把迭代节奏推到了天级别，但速度越快越要守住代码审查和测试的底线。开源与敏捷殊途同归：一个靠冲刺，一个靠文档和审查，目的都是让变化可控、协作透明。
下篇分享第七章：实战中的软件工程。如果这篇笔记对你有帮助，欢迎转发给也在学软件工程的朋友。