《Scrum敏捷软件开发》Succeeding with Agile
作者：Mike Cohn（Mountain Goat Software 创始人，Scrum Alliance 联合创始人）
“If you only read one agile book, this is the one.” — Henrik Kniberg
本书不是 Scrum 入门书，而是从入门到精通的组织级转型指南。Mike Cohn 基于数十年咨询经验，系统回答了：如何在真实组织中推动 Scrum 落地、如何克服阻力、如何扩展到大型项目、如何衡量成效。全书 5 大部分 22 章，覆盖从个人到团队再到整个组织的完整转型路径。
核心观点
- Scrum 转型是组织变革，不是技术工具替换。失败的转型往往只培训了开发者，却忽略了 Scrum 对整个组织（HR、PMO、管理层、法务）的深远影响。
- 没有终点状态。敏捷是持续改进之旅——“there can be no end state in a process that calls for continuous improvement.”
- 自下而上 + 自上而下必须同时进行。只有开发者热情不够，只有管理层推动也不够。
- 不要把 Scrum 变成最佳实践清单。Scrum 是一个框架，需要结合具体情境去调整和适应。
- 先成功，再扩展。找到合适的试点项目，做出可见成果，用成功的故事感染更多团队，胜过大规模强制推广。
全书结构
Part I: Getting Started（起步）——第 1-5 章
解决”为什么要变、怎么开始变”的问题。
| 章节 | 主题 | 核心内容 |
|---|---|---|
| 第1章 | 为什么敏捷转型困难（但值得） | 转型失败的常见原因；Scrum 的可衡量收益（生产力、质量、上市时间、员工士气） |
| 第2章 | ADAPT 模型 | 转型的 5 个阶段：Awareness → Desire → Ability → Promotion → Transfer |
| 第3章 | 采用模式 | 从小处开始 vs. 大爆炸式转型；渐进式 vs. 一次性切换 |
| 第4章 | 迭代迈向敏捷 | 改进待办列表（improvement backlog）；改进社区（improvement communities）；企业转型社区（ETC） |
| 第5章 | 第一个项目 | 理想试点项目的 4 个特征；何时开始（新项目 / 失败项目 / 行将失败的项目） |
Part II: Individuals（个人）——第 6-9 章
聚焦个人层面的角色转变和阻力克服。
| 章节 | 主题 | 核心内容 |
|---|---|---|
| 第6章 | 克服阻力 | 阻力来源（个人得失、权力转移、不确定性）；应对策略 |
| 第7章 | ScrumMaster 新角色 | ScrumMaster 的特征、职责、权威来源；从项目经理到 ScrumMaster 的转变 |
| 第8章 | 变化的角色 | 产品负责人、分析师、测试人员、项目经理等传统角色如何适应 Scrum |
| 第9章 | 技术实践 | TDD、持续集成、结对编程、重构、代码集体所有权——Scrum 团队的技术基石 |
Part III: Teams（团队）——第 10-16 章
从团队视角看 Scrum 如何运转。
| 章节 | 主题 | 核心内容 |
|---|---|---|
| 第10章 | 团队结构 | 特性团队 vs. 组件团队；团队规模（两个披萨原则）；通才 vs. 专才 |
| 第11章 | 团队协作 | 全员责任制（whole-team responsibility）；团队问责 |
| 第12章 | 领导自组织团队 | 自组织的 3 个条件；领导者的 7 种影响方式 |
| 第13章 | 产品待办列表 | 从文档到对话；用户故事；待办列表渐进式细化 |
| 第14章 | 每个 Sprint 交付可用软件 | DoD（完成定义）；跨功能团队；为下个 Sprint 做准备 |
| 第15章 | 渐进式完善计划 | 敏捷规划的不同层次；发布规划；迭代规划 |
| 第16章 | 将测试融入过程 | 为什么传统测试模式失效；测试自动化的不同层次；持续测试 |
Part IV: The Organization（组织）——第 17-20 章
将 Scrum 扩展到整个组织。
| 章节 | 主题 | 核心内容 |
|---|---|---|
| 第17章 | 扩展 Scrum | 首席产品负责人；Scrum of Scrums；大型项目的组织方式 |
| 第18章 | 分布式团队 | 分布式团队的组织模式；沟通挑战；面对面会议的重要性 |
| 第19章 | 与其他方法共存 | 三种交互场景：前置瀑布、后置瀑布、混合模式；合规与治理要求 |
| 第20章 | HR、设施与 PMO | 绩效评估、薪酬、职业路径；办公空间设计；PMO 的转型 |
Part V: Next Steps（下一步）——第 21-22 章
衡量进展，持续改进。
| 章节 | 主题 | 核心内容 |
|---|---|---|
| 第21章 | 衡量进展 | 平衡计分卡；敏捷成熟度评估；有用的和无用的度量 |
| 第22章 | 永无止境 | 敏捷转型没有终点；持续改进的文化 |
关键模型与概念
ADAPT 转型模型（第 2 章）
Mike Cohn 基于 Prosci ADKAR 模型改造，更贴合 Scrum 转型：
- A - Awareness（认知）：意识到当前流程无法交付满意结果
- 常见障碍：看不到全局、拒绝面对现实、把忙碌当进步、听惯了内部宣传
- D - Desire（意愿）：产生采用 Scrum 解决问题的意愿
- 意愿不能被强迫，只能被激发；展示收益而非灌输理念
- A - Ability（能力）：具备成功实施 Scrum 的能力
- 培训、教练、试点项目、访问标杆企业
- P - Promotion（推广）：分享成功经验，让更多人看到成果
- 口口相传是最好的推广方式；像病毒营销一样传播 Scrum
- T - Transfer（传递）：将 Scrum 的影响传递到整个组织
- 影响 HR、财务、法务、PMO 等职能部门
Awareness、Desire、Ability 是重叠递进的，而 Promotion 和 Transfer 贯穿整个转型过程。
改进待办列表 + 改进社区（第 4 章）
把 Scrum 方法本身用于推动 Scrum 转型：
- 改进待办列表（Improvement Backlog）：像产品待办列表一样，列出组织在 Scrum 实践上所有可以改进的事项，按优先级排序
- 改进社区（Improvement Communities）：由对某个领域有热情的人组成的自组织团体，负责推动该领域的改进
- 例：产品待办列表改进社区、测试改进社区
- 企业转型社区（Enterprise Transition Community, ETC）：在更高层面协调和推动整体转型工作
ScrumMaster 角色（第 7 章）
ScrumMaster 像健身教练——权威来自团队的授权，而不是职位赋予。
优秀 ScrumMaster 的特征：
- 精通 Scrum 框架和敏捷原则
- 擅长引导（facilitation）而非指挥
- 有耐心，允许团队从错误中学习
- 能看到团队的盲点并巧妙指出
- 服务型领导（servant leader）
从项目经理到 ScrumMaster 的转变：
- 从”分配任务”到”团队自组织”
- 从”跟踪进度”到”移除障碍”
- 从”对结果负责”到”帮助团队对结果负责”
技术实践五件套（第 9 章）
Scrum 要成功，技术实践是地基。没有技术实践支撑的 Scrum 只会变成快速产出烂代码的机器。
| 实践 | 核心思想 | 价值 |
|---|---|---|
| 测试驱动开发（TDD） | 先写测试，再写代码 | 内建质量、可重构的安全网、设计驱动 |
| 持续集成（CI） | 频繁集成，每次集成都通过自动化验证 | 及早发现集成问题、可随时发布 |
| 结对编程 | 两个人共用一台电脑写代码 | 知识共享、实时代码审查、更高质量 |
| 重构 | 在不改变外部行为的前提下优化内部结构 | 保持代码健康、适应变化、降低技术债务 |
| 集体代码所有权 | 任何人可以修改任何代码 | 消除知识孤岛、提高团队韧性 |
特性团队 vs. 组件团队（第 10 章）
- 特性团队（Feature Team）：跨功能、跨组件，端到端交付一个完整特性
- 优点：减少等待和依赖、更快交付价值、更有成就感
- 挑战：需要更多通才、需要更多沟通
- 组件团队（Component Team）：按系统组件/技术栈划分
- 优点：专业化深、效率高（在组件层面）
- 缺点：依赖多、集成晚、端到端交付慢
推荐方向：逐步向特性团队转型。可以先混合，再逐步增加特性团队比例。
两个披萨团队（第 10 章）
团队规模以”两个披萨能喂饱”为宜（约 5-9 人）。小团队的优势：
- 沟通成本低（n² 问题）
- 决策快
- 责任感强
- 更容易自组织
扩展 Scrum 的模式（第 17 章）
- 首席产品负责人（Chief Product Owner）：负责整体愿景，下管各团队产品负责人
- 产品负责人团队：多个产品负责人协作维护统一的产品待办列表
- Scrum of Scrums：每个团队派代表参加，协调跨团队依赖
- 不是”每日站会的放大版”，而是聚焦跨团队依赖和集成
- 特性团队 + 组件团队混合：核心平台用组件团队，业务功能用特性团队
分布式团队模式（第 18 章）
两种组织方式：
- 按特性分布：每个地点是一个完整的特性团队，端到端负责
- 按层次/组件分布：不同地点负责不同层次或组件（风险更高）
建议：尽量按特性分布，减少跨地点依赖。定期面对面聚会非常重要（至少每个季度一次）。
可行动点
如果你正准备启动 Scrum 转型
- 先找一个理想的试点项目：有可见的重要性、有合适的团队、有愿意支持的管理层、有经验的 ScrumMaster
- 用 ADAPT 模型评估组织状态：当前在哪个阶段？下一步需要什么？
- 建立改进待办列表：把转型本身当作一个 Scrum 项目来做
- 不要从”两周培训”开始——培训只是 Ability 的一小部分，先建立 Awareness 和 Desire 更重要
如果你的团队已经在用 Scrum 但效果不好
- 检查技术实践：没有 TDD、CI 等技术实践的 Scrum 很快会撞上质量墙
- 审视团队结构：是不是组件团队导致了太多依赖和等待？
- 评估产品待办列表质量：是不是还在用需求文档代替对话？
- 回顾你的 ScrumMaster：TA 是在移除障碍，还是在做项目经理的事？
如果你想在更大范围推广
- 用成功故事驱动，而不是行政命令——最好的推广方式是”隔壁团队用了之后效果很好”
- 成立改进社区——让有热情的人来带动更多人
- 提前考虑 HR/PMO/财务等职能部门的转变——这些是转型失败的隐形杀手
- 建立平衡计分卡衡量进展——不要只用速度（velocity）衡量敏捷成效
金句摘录
“Understanding the mechanics of an agile process is just not enough.” 理解敏捷流程的机制是远远不够的。
“There can be no end state in a process that calls for continuous improvement.” 在一个要求持续改进的过程中，不存在终点状态。
“The best architectures, requirements, and designs emerge from self-organizing teams.” 最好的架构、需求和设计来自自组织团队。（敏捷宣言原则之一）
“If everyone is responsible then no one is responsible.” 如果每个人都负责，就等于没人负责。——但 Mike Cohn 认为这是错的，全员责任制是可行的。
“Scrum is not a list of best practices.” Scrum 不是一份最佳实践清单。
与其他知识的关联
- 《程序员修炼之道》-从小工到专家——都强调持续改进和务实主义
- 《重构》-改善既有代码的设计——本书第 9 章技术实践的重要基础
- 《实现模式》-Implementation Patterns-Kent Beck——编码层面的模式，与技术实践相呼应
- 《SICP》-计算机程序的构造和解释-第二版——技术深度的根基
- 《ThoughtWorks实践集锦》-第二册-实效敏捷——更多敏捷实践案例
参考价值
- 推荐指数：★★★★★（敏捷转型必读，Mike Cohn 最权威著作）
- 适合人群：ScrumMaster、敏捷教练、技术负责人、正在推动组织转型的人
- 不适合：完全不了解 Scrum 的纯新手（建议先读《Scrum 指南》入门）
- 阅读建议：前 4 章必读（奠定基础），后面根据自己的问题跳读对应章节