描述
开 本: 大32开纸 张: 胶版纸包 装: 平装是否套装: 否国际标准书号ISBN: 9787302363859
Scrum精髓，一点就通，一本就够
揭示同类书不告诉你的主题和秘笈
适用于大多数敏捷过程的实用指南
适合团队成员、经理和执行负责人阅读的知识读本
如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。作为业内领先的敏捷教练和培训师，KennethRubin用通俗易懂的语言和丰富的实例与我们分享他十多年的实践经验，诠释Scrum的价值观、原则和实践，描述一些灵活、可行的方法帮助我们用好Scrum。
针对Scrum新手和达人，本书从团队、产品和产品组合这三个层面来介绍、澄清和深化Scrum的相关原则和应用。Rubin曾帮助数百个组织成功应用Scrum，积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶，本书图文并茂，通过通俗易懂的描述和两百多幅图对Scrum进行了阐述，这些图采用的是一种全新的视觉图标语言，用于描述Scrum的角色、工件和活动。
本书可以帮助团队成员、经理和执行主管了解Scrum常识，掌握可以拿来即用的通用词汇表，充分攫取Scrum的潜力，*终实现优秀团队能够做到持续、稳健发展的目标。
推荐序—Ron Jeffries
推荐序—李国彪
前言
致谢
第1 章引言
什么是Scrum？
Scrum 的起源
为什么要用Scrum？
Genomica 取得的成果
Scrum 能给你带来帮助吗？
复杂域
繁杂域
简单域
混乱域
无序
常常被打断的工作
结语
第Ⅰ部分 核心概念
第 2 章 Scrum 框架
概述
Scrum 角色
产品负责人
ScrumMaster
开发团队
Scrum 活动与工件
产品 Backlog
冲刺
制定冲刺计划
目录
冲刺执行
每日例会
完成
冲刺评审
冲刺回顾
结语
第 3 章敏捷原则
概述
可变性和不确定性
积极采用有帮助的可变性
采用迭代和增量开发
通过检查、调整和透明性充分利用可变性
同时减少各种形式的不确定因素
预测与适应
保持选择开放
承认无法一开始就把事情做对
偏好适应性、探索式的方法
用经济合理的方法接受变化
平衡预测性的事前工作和适应性的刚好及时工作之间的关系
经过验证的认知
快速验证重要的假设
利用多个认知循环并行的优势
组织妥善工作流程以获得快速反馈
在制品
批量大小要经济、合理
识别并管理库存以达到良好的流动
考虑延迟成本
进度
根据实时信息来重新制定计划
通过验证工作结果来度量进度
聚焦于以价值为中心的交付
执行
快速前进，但不匆忙
内建质量
采用最小够用的仪式
结语
第 4 章冲刺
概述
时长限定
设定在制品数量限制
强制排列优先顺序
展示进度
避免不必要的完美主义
促进结束
增强可预测性
持续期短
容易制定计划
快速反馈
提高投入产出比
有限的错误
重新焕发活力
频繁的检查点
一致的持续期
节奏感的好处
简化计划过程
所做的变化不允许改变目标
什么是冲刺目标？
共同的承诺
是变更，还是澄清
变更所引起的后果
注重实效
异常终止
完成的定义
什么是完成的定义
完成的定义可以随时间演变
完成的定义与验收标准的比较
完成还是完成-完成
结语
第 5 章需求与用户故事
概述
利用对话
逐步细化
用户故事是什么
卡片
确认
细化程度
好故事的INVEST 原则
独立
可协商
有价值
可估算
大小合适（小）
可测试
非功能性需求
目录
知识获取型故事
收集故事
用户故事编写研讨会
绘制故事地图
结语
第 6 章产品 Backlog
概述
PBI
哪种方法更适合好的产品Backlog 有何特征
详略得当
涌现的
做过估算的
排列好优先顺序的
修整
什么是修整
由谁来修整？
何时修整？
就绪的定义
工作流管理
版本工作流管理
冲刺工作流管理
有哪些产品Backlog，有多少个？
什么是产品？
大型产品——层级式Backlog
多个团队，一个产品Backlog
一个团队，多个产品
结语
第 7 章估算与速率
概述
何时估算，估算什么
产品组合Backlog 条目的估算
产品 Backlog 的估算
任务估算
PBI 估算的概念
团队估算
估算不是承诺
准确相比精确
相对大小估算
PBI 估算单位
故事点
理想天数
规划扑克
估算规模
活动规则
好处
什么是速率？
计算速率范围
预测速率
影响速率
速率的误用
结语
第 8 章技术债
概述
技术债的后果
目录
不知何时爆发
交付时间增长
缺陷数量可观
开发支持成本上升
产品萎缩
可预测度降低
表现欠佳
普遍的挫败感
客户满意度降低
技术债的起因
按期完工的压力
尝试错误地提速
误区：减少测试可以提速
债累债
技术债必须加以管理
管理技术债的增长
使用良好的技术实践
使用强完成标准
正确理解技术债的经济效果
让技术债可见
让技术债在业务层面可见
让技术债在技术层面可见
维护技术债
并非所有技术债都应偿还
行将就木型产品
即扔原型
短命型产品
应用童子军规则（即遇技术债即维护）
增量地偿还技术债
先偿还高利息技术债
边做有客户价值工作边偿还技术债
结语
第Ⅱ部分 Scrum 的角色
第 9 章产品负责人
概述
主要职责
管理经济因素
版本发布层面的经济情况
冲刺级的经济情况
产品 Backlog 的经济因素
参与制定计划
修整产品Backlog
定义验收标准并验证这些标准是否得到满足
与开发团队协作
与利益干系人协作
特征∕技能
领域能力
人际交往能力
决策力
责任心
日常一天
谁应当成为产品负责人？
内部开发
商业开发
外包开发项目
组件开发
目录
产品负责人兼任其他角色
产品负责人团队
产品负责人代理
首席产品负责人
结语
第 10 章 ScrumMaster
概述
主要职责
教练
服务型领导
过程专家
屏蔽干扰（在Scrum 中通常说“保护团队”）
移除障碍
变革推动者
特征/技能
知识渊博
善于提问
有耐心
有协作精神
给予保护的
透明
日常一天
履行角色
谁应该成为ScrumMaster
ScrumMaster 是全职工作吗？
ScrumMaster 兼任其他角色
结语
第 11 章开发团队
概述
专门角色的团队
主要责任
冲刺执行
每日检查和调整
修整产品Backlog
规划冲刺
检查和调整产品和过程
特点和技能
自组织
跨职能的多样化和全面化
T 型技能
火枪手态度
高效沟通
透明沟通
大小合适
专注与承诺
可持续的工作节奏
保持团队持久
结语
第 12 章 Scrum 团队结构
概述
特性团队与组件团队
多个团队的协调
Scrum of Scrums
版本火车
结语
目录
第 13 章经理
概述
塑造团队
定义边界
提供一个清晰而鼓舞人心的目标
组建团队
改变团队的组成
授权团队
培育团队
激励团队
发展团队能力
建立职能领导力
保持团队完整性
调整并改造环境
传播敏捷价值观
移除组织层面的障碍
协调内部多个团队合作
使外部合作伙伴保持一致
管理价值创造的流程
采用系统性视角
管理经济状况
监控测量和报告
项目经理
Scrum 团队中项目管理的职责
保留单独的项目经理角色
结语
第 14 章 Scrum 的规划原则
概述
前期做不好计划
少量前期规划仍有益
最后责任时刻前仍可改变规划
关注适应与重新规划多过遵循计划
正确管理规划库存
偏好更小、更频繁地发布
必要时为快速学习与关键转折作规划
结语
第 15 章多层次规划
概述
产品组合的规划
产品规划（愿景）
愿景
高层次产品Backlog
产品路线图
制定版本计划
制定冲刺计划
制定每日计划
结语
第 16 章产品组合规划
概述
时机
参与者
流程
进度安排策略
为生命周期利润而优化
计算延期成本
目录
准确估算，而不用精确估算
流入策略
应用经济指标
平衡到达日期和离开日期
快速拥抱新涌现的机会
为更小、更频繁的发布做计划
流出策略
关注闲置工作，而非闲置人员
设定在制品限制
等待一个完整的团队
在制品策略
使用边际效益
结语
第 17 章构想（产品规划）
概述
时机
参与者
流程
SR4U 实例
愿景
建立概要产品Backlog
定义产品路线图
其他活动
以经济合理合理的方式建立构想
瞄准切实可行的信心门槛
关注短期范围
快速行动
为经验知识付出代价
使用递增的/暂行资金
快速学习和调头（也称快速失败）
第 18 章版本计划（长期计划）
概述
时间安排
参与者
过程
版本限制条件
固定全部特性
固定范围和日期
固定范围
固定日期
可变质量
更新限制条件
修整产品Backlog
细化最小可发布特性（MRF）
冲刺映射（插入PBI）
固定日期的版本计划
固定范围的版本计划
计算成本
沟通
对固定范围版本的进展情况进行沟通
对固定范围版本的燃尽图进行沟通
固定范围版本的燃烧图
结语
第Ⅳ部分 冲刺
第 19 章冲刺计划
概述
时机
参与者
流程
冲刺计划的方法
两段式冲刺计划
一次性冲刺计划
确定生产能力
什么是生产能力？
用故事点表示的生产能力
用工时表示生产能力
选取 PBI
获得信心
优化冲刺目标
敲定承诺
结语
第 20 章冲刺执行
概述
时间安排
参与者
流程
冲刺执行计划
工作流动管理
并行工作和蜂拥式
从哪项工作开始
如何安排任务
需要完成什么工作
谁来做具体的工作？
每日例会
任务执行——技术实践
沟通
任务板
冲刺燃尽图
冲刺燃烧图
结语
第 21 章冲刺评审
概述
参与者
准备工作
确定邀请谁参加
安排活动日程
确认冲刺工作完成了
为演示做准备
确定谁做什么
方法
总结
演示
讨论
调整
有关冲刺评审的问题
签字验收
断断续续地参与
大型开发工作
结语
第 22 章冲刺回顾
概述
参与者
准备工作
定义回顾的重点
选择需要完成的任务
收集客观数据
安排回顾工作
方法
营造氛围
共同的上下文
事件的时间线
情绪测震仪
找出见解
确定措施
选择见解
确定行动
见解 Backlog
结束回顾
进行到底
有关冲刺回顾的问题
结语
第 23 章前进的道路
终极状态是不存在的
找到自己的道路
共享最佳实践
使用 Scrum 发现前进的道路
心动不如行动__
什么是Scrum精髓?
Scrum的基石是一套轻量级的核心价值观、原则和实践（统称为Scrum框架）。使用Scrum的组织要全身心拥抱Scrum框架，不过也许并不是一次性在整个组织全面展开，但打算采用Scrum的最初（几个）团队在内部一定要做到这一点。然而，全面拥抱Scrum并不意味着组织在实施Scrum的时候必须得照着某个一刀切、放之四海皆准的公式生搬硬套。它实际意味着组织在为Scrum实施过程选择合适自己的一套方法体系时，应该一直不折不扣地坚守Scrum框架。
《Scrum精髓》综合介绍了Scrum价值观、原则和实践以及一套实践证明有效的方法体系，这些方法与Scrum框架一致但又不受制于Scrum。其中有些方法对具体的组织环境很适用，有一些则不然。任何方法都需要根据独特的组织情况进行检视和调整。
本书的缘起
作为敏捷/Scrum教练和培训师，经常有人请我推荐Scrum参考书，最好是同时提供Scrum框架综述并介绍Scrum主流用法的书。因为我找不到任何一本书能够同时把这两个主题讲得足够深刻，能够为时下的实践者提供实际帮助，我发现自己推荐的书大致有几种情况：有少数几本书讨论的是Scrum框架但内容已经过时或不完整；有几本书主要讲敏捷，但没有单独关注Scrum；还有几本书重点关注Scrum某个特定方面或具体方法但并没有深入覆盖整个Scrum框架的；如果就想通过一本书了解Scrum精髓，选择余地就比较多了，市面上这样的书很多!
Scrum之父(Jeff Sutherland和Ken Schwaber)写过一本书“Scrum指南”（The Scrum Guide）。这个简短的文档（大约只有15页）被作者描述为“Scrum 的金科玉律，Scrum的专有文档” (Schwaber and Sutherland 2011)。他们把它比作象棋游戏的游戏规则说明“描述棋子（各个部件）的行走规则，顺序如何，输赢如何定义，等等。”尽管它的用途是Scrum综述或Scrum规则手册，但在“Scrum指南”设计之初，并不想成为供大家全面了解Scrum相关基础的知识宝库。延伸两位作者的比喻，它的目的只是充当新建Scrum团队的“Scrum指南”，期望能得到一个好的结果，即能够为不熟悉象棋规则的新人提供一个15页的象棋规则说明并期望他们能够在读完这个指南之后更好在象棋游戏中起到不错的作用。它真的不是一个独立的资源。
《Scrum精髓》这本书尝试补全Scrum基础知识体系缺失的那部分资源。它对Scrum原则、价值和实践进行深入的讨论（大多与其他敏捷思想领袖和“Scrum指南”的看法一致），但这本书另辟蹊径，提供了一个独特的视角，我把相关的观点提出来并解释了具体原因。本书还描述了其他实施方法，这些方法与Scrum框架一致，也和我及我辅导过的团队成功应用的方法一致。我无意于用这本书替代其他深入探讨特定Scrum 实践或方法的书。这些书与本书相辅相成。可以把《Scrum精髓》作为使用Scrum 来取悦用户的一个起点。
读者对象
对于我的数千名学员（Scrum团队、认证ScrumMaster和认证Scrum产品负责人等培训课程）和我辅导过的许多团队，这本书有助于大家重新认识和澄清我们在之前课程中讨论过的主题。对于更多我还没有开始愉快合作的读者，这本书可以作为你的第一本Scrum／敏捷入门书，让你有机会从不同的角度认识Scrum，说不定它还能帮助你更好地提升Scrum实施效果。
写这本书的时候，我并没有针对任何一个具体的角色，它并不是专门为产品负责人、ScrumMasters或开发团队写的。相反，它的目的是让Scrum所牵涉的每个人，从所有Scrum团队成员到组织中与他们互动的任何人，都能够基于一套核心的概念体系与（便于讨论的）清楚的词汇表，共同认识和理解Scrum。有了这样的共同基础，我希望每个组织都能够有一个更好的起点，成功运用Scrum交付商业价值。
我想象着，每个Scrum 团队成员的案头都有这本书，正好翻到与她手边工作相关的内容。我还憧憬着，组织机构中每个层级的经理都在读这本书，因为他们想知道Scrum是如何有效管理工作的，想了解哪些类型的组织变更才是保证Scrum取得成功的必要前提。正在用或者打算使用非Scrum的其他敏捷方法的组织也能从中得到一个结论：有很多信息与其特定的敏捷导入是有关联和帮助的。
本书的结构
本书首先对Scrum 进行简要的介绍（第1章），最后讨论成功导入Scrum 之后的下一步行动（第23章）。其余各章分为四个部分进行描述。
第I部分“核心概念”(第2~8章)，涉及的主题有：Scrum框架，敏捷原则，冲刺，需求与用户故事，产品backlog，估算与速率，技术债。
第II部分“角色”(第9~13章)，涉及的主题包括：产品负责人、ScrumMaster、开发团队、Scrum团队构成和经理。
第III部分“规划”(第14~18章)，主题包括：Scrum规划原则、多层级规划活动、产品组合规划、构想/产品规划以及版本规划。
第IV部分“冲刺”(第19~22章)，主题包括：冲刺规划，冲刺执行，冲刺评审和冲刺回顾。
如何使用本书
正如大家期待的一样，我写这本书时假设大多数读者都会从头到尾顺序阅读。如果你是Scrum新手，就应该采用这种方法，因为各章之间本来就是承上启下，前后连贯的。也就是说，如果想找到一个合适的起点从头到尾了解Scrum框架（一个非常清楚的Scrum扫盲读本），请阅读和参考第2章。
熟悉Scrum的人，则可以把这本书用作Scrum参考指南。如果对冲刺回顾感兴趣，则可以直接翻到第22章开始阅读。如果对探究产品backlog的细枝末节，可以直接阅读第6章。不过，我强烈建议每个人都完整读一读第3章，即便是熟悉Scrum的人。这一章介绍的原则是Scrum框架和本书其余内容的基础，其他大多数文献都只是简单而泛泛地重复敏捷宣言中提到的价值观和原则(Beck et al. 2001)，这一章却不是。
视觉图标语言
我很自豪，这本书采用了一种新的视觉语言来描述Scrum。这种语言由一系列图标构成，这些图标被设计为体现基本的Scrum角色、工件和活动。这个Scrum视觉语言是一种有效的沟通工具，有利于团队成员之间交流想法并增强对Scrum的共识。如果你很想得到和使用这些让人耳目一新的彩色版的Scrum插图，请访问www.innolution.com了解更多信息。这个网站还有各种资源和本书相关讨论。
心动不如行动
好吧，不管什么角色，处于什么状况，你已经因为某种原因而拿起了这本书。在字里行间，找到一个适合自己的强大框架，以可持续的步调改善开发方式（方法和流程），交付让客户欣欣然点赞的产品和服务吧！
序言
推荐序：Mike Cohn
代表作：《Scrum敏捷软件开发》、《敏捷估算与规划》与《用户故事与敏捷方法》）
我今天的午餐是在汉堡王餐厅吃的。墙上贴着一幅“皇堡之家”的海报，告诉人们皇堡可以有很多种点法。泡菜、番茄、生菜和奶酪可以多要一点，也可以不要，各种各样的组合，能做出很多种汉堡包。实施Scrum的可行方法也必然有很多很多种。不过，虽然条条道路通罗马，但不同的方法还是有好坏之分的。
在《Scrum精髓》中，Ken Rubin帮助读者找到了更好的方法。他的书讲述的不是规范——他没有说，“你必须得这样做。”相反，他传授的是帮助Scrum取得成功的幕后的基本原理。比如说，在制定冲刺计划时并不存一个在对所有团队来说都正确的方法。适用于某个公司或项目的方法在另一个公司或项目中却行不通。Kenny给我们提供了一些选择。但是最终的决定权在每个团队。幸运的是，这些团队现在有了这本书的帮助。
《Scrum精髓》我们带来的一个意外好处是Kenny引入的、用于表达Scrum的视觉语言。这些图对理解文字内容非常有帮助，我估计今后人们在讨论Scrum时会常常使用这些图像。
我们早该有这样一本书了。Scrum最初是一个小概念。第一本讨论它的书Wicked Problems, Righteous Solutions（DeGrace和Stahl合写）只有6页。但在它面世20多年后，Scrum得到扩充，引入并细化了新的角色、会议和工件。每增加一个内容，我们都面临着丢掉Scrum核心内容的风险——部分核心内容阐述的是团队如何规划工作，如何先做一小部分，然后反思团队完成的工作，看看在一起做得怎么样。
在《Scrum精髓》一书中，Kenny把我们带回到Scrum的核心内容。在这个基础上， Scrum团队可以开始做出实施Scrum所需要的决策，做出适合自己的决策。本书是一个不可或缺的指南，可以帮助团队在林林总总的Scrum实施方法中选择并找到一种能够带来成功的方法。
推荐序—Ron Jeffries
当Kenny邀请我为他的《Scrum精髓》写一篇序的时候，我就在想：“这事儿做起来快，简单，它肯定是一本很直白的、简单描述Scrum的书。”我对Ken的简洁明快的工作风格非常了解，所以知道他的作品肯定也是这样的，甚至比我想象的肯定还好！
所以呢，当我看到这本书几乎涵括Scrum“处女航”的全部精髓时，你可以想像我的感受，简直是又惊又喜！而且，Kenny还更进一步。他从核心的理念入手，包括所有敏捷方法底层的敏捷原则，概览了Scrum框架。他还深入到细节进一步探究更多细节。这本书可读性强，而且内容丰富，耐读。Kenny 对规划的详细描述是恰到好处的，他还谈到需求、故事和backlog估算、速率。随后还带我们深入敏捷原则，帮助我们处理所有级别的规划和所有时间范围。他描述了如何规划、执行、回顾和改进冲刺过程。贯穿全书，他在介绍基础知识之外，还重点强调了我们在Scrum导入初期可能会遇到的重要问题。
对于Scrum和敏捷，我个人关注的是必要的开发技能，这些技能可以确保团队能够通过一个接一个的冲刺，交付真正的、可运行的、以业务为中心的软件。Kenny帮助我们理解了如何以安全、合适的方式使用速率和技术债等概念。速率和技术债这两个主题都非常关键，我推荐您重点关注它们。
速率向我们表明团队随着时间打退役要交付多少价值。我们可以用它来感觉我们要完成多少任务以及我们的工作方式比原来是否有所改善。然而，Kenny警告我们把速率用作一个绩效考核指标会对业务造成伤害，而且他还有理有据帮助我们认识到个中缘由。
技术债这个说法现在已经非常普遍，泛指会导致代码出问题的所有东西。Kenny帮助我们捋清它的个中含义，并帮助我们认识到为什么我们要关注这些偏技术性的细节。我特别希望他对这方面的详细描述：让团队在压力下工作注定会使一个好的产品无法如期按时交付。
就像所有敏捷方法一样，Scrum依赖于快速反馈来进行探索。Kenny给我们讲了他当年用穿孔卡的故事，这让我想起自己早期的计算机生涯，比Kenney看到他平生第一张穿孔卡还要久远得多。作为一名大学生，我非常幸运，有机会到美国战略空军司令部奥马哈总部（SAC HQ）实习。在那些日子里，所有计算都是通过穿孔卡来做的。我的卡片得发送到SAC HQ地下好几层并在那台能发起战争的计算机上（如果要发起战争的话）。我很幸运，一天可以有一两次跑程序的机会。
只要一通过安检，就会大半夜下楼到计算机面前。我还会对Sergeant Whittaker甜言蜜语，让他准许我坐在计算机终端面前跑我自己写的程序，是的，那台主要工作就是发动核攻击的机器。不过，放心，那个房间里是没有红色按钮的。
在计算机面前忙活儿，我可以做十倍的工作（相较于我不得不等着我的索引卡被传下来，然后我的代码清单被回传到楼上）。反馈来得快，我就学得快，我的程序也能早些跑起来。这就是Scrum的本事。用不着等上好几个月甚至好几年才知道程序员们都在干什么，通过Scrum，我们每两周就知道他们的动态。Scrum产品负责人在优秀团队的支持下，每个几天就能看到有实际的产品特性被打磨成形！
而且，这也是Kenny这本书的主旨。如果是Scrum新手，就从头到尾仔细阅读，然后把它放在案头。如果做Scrum已经有了一些时日，那就全书浏览一遍，把它留在手边随时参考。如果发现自己开始认真思索团队的事儿或者寻思着搞点儿创新，不妨拿起这本书，从字里行间寻找突破点。总能找到金子（有价值的东西）。
推荐序—李国彪（Bill）
Scrum联盟认证培训师（CST），UPerform优普丰顾问机构
代表作：《Scrum敏捷项目管理》（国内第一本Scrum相关译著）
一本非常不错的介绍Scrum核心及相关实践、打造敏捷交付能力的参考书！
自2007年我有幸引入和翻译第一本Scrum书籍《Scrum敏捷项目管理》（Ken Schwaber著）之后，我们见证了敏捷和Scrum在中国软件及产品研发行业的应用和演进，业界人士和许多团队的不断深入实践及锲而不舍的多样化尝试，也目睹许多组织和团队的迂回之路和成功发展敏捷能力的成就感，但同时也对他们的困惑和挣扎感同身受。Scrum框架是强大的，其生命力来源于其简洁性，但要想获得成效，难也难在此！
感谢业界同行的热情与努力，此数年间陆续有新的Scrum相关书籍进入市场。每一本书都有其独到之处。这本《Scrum精髓》也给我们带来惊喜，在业界需要的时候来到中国。感谢清华大学出版社和译者的付出！
条条大路通罗马。Scrum框架不变，彰显其精髓和价值观的实践和形式确实是在不断得到探索和演进。有许多的实践和招式是基于具体上下文、有针对性地以落地试验的方式得出来的。这些何尝不是敏捷精神和本质的体现呢？
若是Scrum新手，你会收获这本书带来的扎实的Scrum基础和本质；若已有相当的实操经验，你会发现丰富且有参考价值的实例。我相信其中一些能为你指点迷津；若你的工作环境非常关注规划，则可以参考本书针对不同层面的敏捷计划和多种商业情景中所介绍的应对方式、相关推荐及详实的分析。
另外，若是管理者，想通过自己的影响力推进Scrum和敏捷，则可以从单独针对管理者角色和思路设计的这章内容中获得新的思路和方向，这在同类文献中可能是写得最好的。因为作者Ken本人曾经有过同样的中高层领导力经历，他对管理者角色在Scrum环境中的转型感同身受。而且，Ken也亲历过早期面向对象技术的发展，具有深厚的敏捷工程实践背景。本书里的分享都是源自Ken的亲身经历和反思。毫无疑问，对大多数人而言，这是一本值得收藏在案头随时翻阅的Scrum参考书。
另外，令人眼前一亮的是书中使用的敏捷视觉化图标语言，这是Ken原创的，相信会使大家的阅读体验和Scrum应用体验更上一层楼。
通过这本书，让我们一起帮助自己、团队与组织继续发扬及发展频密交付和持续改进的精神和能力。
“Agile coaches, you’re gonna be happy with this book. Kenny Rubin has created
an indispensable resource for us. Do you have a manager who just doesn’t ‘get it’? Hand them this book and ask them to flip to Chapter 3 for a complete explanation of how Scrum is less risky than plan-driven management. It’s written just for them—in management-speak. Want to help the team come to a common understanding of Scrum? The visual icon language used throughout this book will help you help them. These are just two ways this book can aid you to coach Scrum teams. Use it well.”
— Lyssa Adkins，敏捷教练总教练，Agile Coaching Institute，《如何构建敏捷项目管理团队》合著者
“One of the best, most comprehensive de*ions of the core Scrum framework
out there! Essential Scrum is for anyone—new to or experienced with Scrum—who’s interested in the most important aspects of the process. Kenny does an excellent job of distilling the key tenets of the Scrum framework into a simple format with compelling visuals. As a Scrum coach for many teams, I continually reference the material for new ways to help teams that are learning and practicing the framework. I’ve seen Scrum continually misinterpreted and poorly implemented by big companies and tool vendors for more than ten years. Reading this book will help you get back to the basics and focus on what’s important.”
— Joe Balistrieri，流程开发经理，罗克韦尔自动化公司
“Corporate IT leadership, which has been slow to embrace agile methods, would benefit immensely from giving a copy of this book to all of their project and delivery managers. Kenny Rubin has laid out in this book all the pragmatic business case and process materials needed for any corporate IT shop to successfully implement Scrum.”
— John F. Bauer III，总能及时交付技术方案的老兵
“Kenny’s extensive experience as a consultant, trainer, and past managing director of the Scrum Alliance is evident in this book. Along with providing the basics and introduction to Scrum, this book addresses the questions of masses—what happens to project managers? Essential Scrum helps us understand the big picture and guides how organization leaders can support and be involved with their Scrum teams for successful agile transformations.”
— Sameer S. Bendre，CSM，PMP，高级顾问，3i Infotech公司
“If you’re new to agile development or to Scrum, this book will give you a flying start. The examples and de*ions are clear and vivid, and you’ll often find yourself asking a question just before the book addresses that very topic.”
— Johannes Brodwall，解决方案总架构师，Steria Norway
“Kenny’s well-structured explanations have a clarity to them that echoes the sensibilities of Smalltalk—the development environment with which he worked for years and from which both Scrum and Extreme Programming were born. This book pulls together a thorough set of agile management principles that really hit the mark and will no doubt guide you toward a more effective agile approach.”
— Rowan Bunning，创始人，Scrum WithStyle
“There are lots of books on Scrum these days, but this book takes a new angle: a
reality check for software practitioners. Kenny uses real-world examples and clear illustrations to show what makes a solid foundation for successful agile development. Readers will understand the value of building quality in, and the reality that we can’t get everything right up front; we must work incrementally and learn as we go. It might have ‘Scrum’ in the title, but the book leverages effective practices from the larger agile universe to help managers and their teams succeed.”
— Lisa Crispin，《敏捷测试》合著者
“Kenny Rubin managed to write the book that I want everyone associated with
Scrum development to read! He covers everything you’ll need to know about Scrum and more!”
— Martine Devos，欧洲Scrum先驱和认证Scrum培训师
“I’ve reviewed a number of agile books in the past few years, so the question of ‘Do we really need another one?’ always comes to my mind. In the case of Kenny’s book, I very much believe the answer is ‘yes.’ Getting the benefit of different, experienced perspectives on commonly encountered and needed material is valuable. Kenny has one of those valuable perspectives. One unique aspect of the book is an interesting ‘iconography’—a new icon language for Scrum and agile that Kenny has created. I believe you’ll find value-added material in this book to expand your ideas for how Scrum can be applied.”
— Scott Duncan，敏捷/Scrum教练兼培训师
“Anyone who has had Scrum training or has been part of a Scrum team will find Essential Scrum to be a great follow-up read. It dives into the details of how to become more agile through implementing Scrum processes, and it explains exactly how to break down complex projects into manageable initiatives (or ‘sprints’). Kenny Rubin provides a wealth of relevant case studies on what worked—or what didn’t—in a variety of organizations. The simple layout and businesslike graphics make it easy to scan quickly and find specific topics. Any organization that is seeking to evolve from a traditional waterfall approach toward a more agile methodology will find Essential Scrum a definitive guidebook for the journey.”
— Julia Frazier，产品经理
“Developing software is hard. Adopting a new way of working while in a project is even harder. This book offers a bypass of many of the pitfalls and will accelerate a team’s ability to produce business value and become successful with Scrum. I wish I had this kind of book when I started using Scrum.”
— Geir Hedemark，开发经理，Basefarm AS
“I am convinced that Essential Scrum will become the foundation reference for the next generation of Scrum practitioners. Not only is it the most comprehensive introduction to Scrum available today, but it is also extremely well written and easy on the eye with its fantastic new visual Scrum language. If that isn’t enough, Kenny shares a range of his valuable personal insights and experiences that we can all certainly learn from.”
— Ilan Goldstein，敏捷方案经理，Reed Elsevier，《Scrum捷径》作者
“Scrum is elegantly simple, yet deceptively complex. In Essential Scrum, Kenny Rubin provides us with a step-by-step guide to those complexities while retaining the essential simplicity. Real-world experiences coupled with enlightening illustrations make Scrum come to life. For senior managers and team members alike, this is a must-read book if you are starting or considering whether to implement Scrum in your organization. This will certainly be a book recommended to my students.”
— John Hebley, Hebley & Associates
“Kenny unpacks a wealth of wisdom and knowledge in Essential Scrum, providing valuable and comprehensive insights to the practical application of agile/Scrum. Whether you’re new to agile or are looking to reach a greater maturity of continuous improvement in your organization, this is a definitive handbook for your toolbox.”
— David Luzquios，敏捷启动主管，敏捷教练，Betfair
“Kenny Rubin continues to provide clarity and insight into adopting agile in a pragmatic way. In one hand he holds the formal or ideal Scrum definition, and in the other, the pragmatic application of it. He brings the wisdom of his workshops and years of experience to the table for you to read in his latest book. If you are ab
在使用Scrum时，经常需要平衡预测性的事前工作与适应性的适时工作之间的关系。下面五个敏捷原则与这个主题相关：
保持选择开放
承认无法一开始就把事情做对
偏好适应性、探索式的方法
用经济合理的方法积极主动接受变化
在预测性的事前工作和适应性的适时工作之间做出平衡
保持选择开放
对于需求或设计，计划驱动的顺序开发方式要求在当前这个阶段就做出重要的决策并进行审批。而且，在进入下一个阶段之前必须先做出决策，即使这些决策依据的知识有限。
Scrum认为，不该单单因为通用过程要求此时做出决定，我们就得做出不成熟的决定。相反，在使用Scrum时，我们倾向于“保持选择开放”这个策略。这个原则常被称为“最后责任时刻”（LastResponsibleMoment，LRM）（PoppendieckandPoppendieck，2003），意思是推迟做出承诺，直到最后责任时刻再做出重要的、不可逆转的决定。那么，最后责任时刻是什么时候呢？这个时刻就是不做决定的成本大于做决定的成本时（参见图3.6）。此时，就需要做出决定了。
图3.6在最后责任时刻做出决定
为了领会这个原则，我们考虑下面这种情况。在产品开发工作的第一天，我们对自己的工作内容了解得最少。随后的每一天，我们的了解都能多一点点。既然如此，为什么要在第一天或者很早就做出所有最关键且（也许）无法逆转的决定呢？大多数人都倾向于等有更多信息之后再做出更明智的决定。在处理重要的或不可逆转的决定时，如果决策太早且有错，就会处于图3.6中决策成本的指数部分。更好理解决策之后，决策成本会下降（因为市场和技术的确定性增加，做出错误决策的可能性降低了）。这说明我们应该在掌握更多信息之后再做决策。
承认无法一开始就把事情做对
计划驱动的过程不仅要求有完整的需求和全面的计划，还想当然地认为事先就能“把事情做对”。但实际情况是我们基本上不可能事先就能以正确的方式得到所有需求，也不可能基于这些需求以正确方式得出详尽的计划。更糟糕的是，一旦需求有变，还得修改需求和计划基线以适应当时的实际情况（详情参见第5章）。
在Scrum中，我们承认自己不可能事先确定所有需求或计划。事实上，我们认为这样做可能很危险，因为可能漏掉重要的知识而产生大量低质量的需求（参见图3.7）。
图3.7计划驱动的需求获取与产品知识积累
图3.7表明，在使用计划驱动的顺序过程时，在早期产品知识积累有限的时候就产生了大量需求。这样做是有风险的，因为它使我们产生错觉，认为自己已经消除了结果不确定性。一旦了解得更多或事情有变，可能还会造成巨大的浪费（详情参见后文）。
在Scrum中，我们也会预先产生需求和计划，但原则是够用就好，一旦了解更多在建产品的相关知识，我们就会填充需求和计划的细节。毕竟，在开始构建前，即使我们笃定要以什么方式构建哪些特性，但在把早期的增量可交付物放到目标使用环境之后，还是会发现不对劲儿的地方。此时，种种实际情形都会推动我们改变初衷，去做真正适用、适时的东西。
偏好适应性、探索式的方法
使用（或利用）现在已知的东西并对未知的东西进行预测，这是计划驱动的顺序过程关注的重点。Scrum则更倾向于恰当运用探索式方法，在此基础上采用适应性的试错法。
探索指的是通过某些活动来获得知识，例如构建原型、创建概念验证、实施研究或进行试验。换句话说，则是面对不确定，我们通过探索来获取信息。
工具和技术对探索成本有很大的影响。在过去，软件产品开发的探索成本很高，因而采用预测性的、尽量一开始时做对的方法是有利的（参见图3.8）。
图3.8过去的探索成本
举个例子，我在佐治亚理工学院读大一时（上世纪80年代初），我用过几次打孔卡——跟打字机似的，如果出错或需要修改，是很烦人的。必须非常小心地为所有解决方案逐个做打孔卡，然后再排队等待使用大型机，可能得等上24小时才能验证解决方案是否正确，在这样的背景下，“快点试一试，看情况”这个理念是让人很难接受的。即使微不足道的排版错误，也至少得耽误一天的工夫。瀑布过程在面对不确定性时可以仔细考虑当前知识并做出预测，以求找到优化的解决方案，这种做法在经济上是合理的。
幸运的是，现在的工具和技术越来越好，探索成本也随之下降。从经济层面上不再是探索的阻碍。事实上，到如今，快速构建少量内容并根据用户反馈进行调整，其成本往往低于事先投入精力试图一次性做对所有事情。解决方案的目标使用环境（技术）如今已变得更加复杂，所以能够采取这种做法也是很值得庆幸的。
在Scrum中，只要具备足够的知识，就可以得出明智、合理的最终解决方案。然而，在面对不确定性时，不要一厢情愿地预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息得出明智、合理的最终解决方案。通过行动所获得的反馈可以帮助我们确定是否还需要进一步探索以及何时进行。
用经济合理的方法接受变化
我们都知道，使用顺序开发方式时，后期变更成本比早期变更成本高很多（参见图3.9，基于Boehm1981）。
图3.9顺序开发方式的变更成本曲线图
举个例子，分析阶段的变更可能只花1美元，但在后期测试阶段，同样的变更却可能花1000美元。为什么会这样呢？如果分析阶段出现的错误能在现阶段被发现，那么修正成本肯定不高。但如果直到设计阶段才发现这个错误，则不仅需要修正错误需求，可能还要修复基于这个错误需求所做的设计。每往后延一个阶段，错误的影响也越大，甚至出现这样的情况：分析阶段的小错误到测试或运行阶段演变成大错误。
为避免后期变更，顺序开发过程的做法是设法提高预测的准确度，澄清系统需求及其实现过程，再加以严格控制，力求最小化需求和设计变更。
不幸的是，早期活动阶段的过度预测往往适得其反。不仅无法消除变更，反而成为交付延期和预算超支的原因之一。为什么会出现这种有悖常理的事实呢？首先，为了消除昂贵的变更，我们被迫在每个阶段进行过度投资，即做一些不必要、不切实际的工作。其次，在尚未得到干系人对工作产品的反馈以验证我们的假设之前，我们被迫在过程早期对重要的假设进行决策。结果，根据这些假设而产生大量工作产品。后来，在这些假设被证实（或被推翻）或发生变更的时候（例如，需求的出现或演变），很可能得修改或放弃原有的工作成果，这样的情况时有发生。自我实现的预言，其经典模式莫过于此（参见图3.10）。
在Scrum中，我们认为变更是很正常的。我们相信，产品开发所固有的不确定性是无法事先通过加班加点来预测的。因此，必须准备好积极主动迎接变更。不过，在出现变更时，我们希望能比传统开发更经济的方式来处理，即使变更发生在产品开发工作后期。
因此，我们的目标是要让变更成本曲线尽可能长期保持平稳——即使在后期接受变更，开销也是经济合理的。图3.11说明了这个观点。
我们可以通过对在制品数量和工作流进行管理来实现这个目标，因此，与顺序开发相比，在使用Scrum时，变更成本受时间的影响更小。
不管使用哪种方式来进行产品开发，我们都希望有这样的关系：小的需求变更所造成的实现方式变更也相应较小，因而成本变更也小（不难想象，大型变更带来的成本显然更高）。我们从这种关系中希望得到的另外一个特征：不管变更请求何时出现，都要保持这种关系。
图3.10自我实现的预言
图3.11让变更成本曲线趋于平稳
在使用Scrum时，很多工作产品（例如详细需求、设计和测试用例）都是以刚好及时的方式产生的，以免创建非必需的工件。这样，在发生变更时，不必丢弃或重新修改的、基于假设而产生的工作或被迫做出的决定要少得多，因此可以让成本和变更请求的大小更加成比例。
使用顺序开发方式时，库存会随着时间的推移而增加，这意味着早期所建的工件和被迫做出的不成熟决定最终造成变更成本快速上升。这导致图3.11中传统开发方式的曲线在早期就出现拐点（曲线突然上升的那个点）。在使用Scrum开发时，到达某个时间点之后，变更成本和变更请求的比例也会变得很离谱，但这个时间点会出现得更晚一些（如图3.11中的Scrum曲线拐点所示）。
平衡预测性的事前工作和适应性的刚好及时工作之间的关系
计划驱动开发有一个基本的理念：事先得到详细需求和计划是至关重要的，并且做事情要有先后。在Scrum中，我们相信前期工作有帮助，但不宜过度。
在Scrum中，我们承认不可能事先精确获得所有需求和计划。这是否意味着不应该事先做需求和计划呢？当然不是！Scrum的要义是找到平衡点，即使平衡预测性的前期工作和适应性的刚好及时工作之间的平衡（参见图3.12，改编自Cohn2009中的图）。
在开发产品时，应该从经济合理的角度来设置平衡点，满足法规、监管和∕或公司的目标的前提下，尽量根据快速反馈持续进行调整，少做事前预测。
究竟怎样才算平衡？这在一定程度上由这几个因素推动：所建产品的类型、待建产品（结果不确定性）和产品构建方式（方法不确定性）的不确定程度以及开发中的限制。过度预测要求我们在普遍存在不确定性的情况下做出假设。过度调整可能会让我们处于动荡中，让人觉得工作效率低下、混乱。为了能够快速开发创新产品，在我们的工作环境中，一方面要调整，一方面也要通过刚好够的预测来取得平衡，以免陷入混乱。Scrum框架在秩序与混乱之间取得了很好的平衡。
评论
还没有评论。