《Scrum精髓：敏捷转型指南》（Scrum精髓:敏捷转型指南）

Scrum精髓：敏捷转型指南

Kenneth Rubin     著

姜信宝  米全喜  左洪斌    译

徐  毅   审校

清华大学出版社

北京

本 书 赞 誉

“敏捷教练们，你们会喜欢这本书的。Kenny Rubin为我们创作了一个不可或缺的资源。你们的经理还不理解敏捷吗？把这本书给他们，让他们翻到第3章，这一章全面解释了为什么Scrum的风险比计划驱动管理方式的风险小。这本书正是写给他们看的，而且是以管理人员的套辞来写的。你想帮助团队取得对Scrum的一致理解吗？贯穿全书的可视化图标语言可以帮助你。本书在很多方面都可以帮助你培训Scrum团队，我在这里只是说了其中两方面。好好使用这本书吧。”

—— Lyssa Adkins，敏捷教练总教练，Agile Coaching Institute，

《如何构建敏捷项目管理团队》合著者

“又一本最好、最全面描述核心Scrum框架的书！任何人，不论是否有Scrum经验，只要对过程中最重要的内容感兴趣，都能用得上《Scrum精髓》。Kenny的工作非常出色，用简单的形式和引人入胜的可视化语言提炼出了Scrum框架的关键原则。我在很多团队担任过Scrum教练，我总是能在书中发现新的东西，为学习和应用这个框架的团队带来帮助。在过去的十多年里，我经常看到一些大公司和工具开发商对Scrum有误解，实施效果也不尽如人意。阅读本书将帮助你回归本质，关注重要的内容。”

—— Joe Balistrieri，流程开发经理，罗克韦尔自动化公司

“在采用敏捷方法时总是慢一拍的公司IT领导，应该把这本书发给他们的项目经理和交付经理，人手一册，好让公司受益无穷。Kenny Rubin在本书中展示了公司IT部门成功实施Scrum所需的所有实用案例和过程。”

—— John F. Bauer III，在大型公司IT部门从事技术方案交付工作的一名老兵

“这本书鲜明地体现了Kenny作为顾问、教练和Scrum联盟首任常务董事所积累的广泛经验。书中不但提供了Scrum的基本知识和概述，还论述了大量的问题——那些发生在项目经理身上的事情。《Scrum精髓》帮助我们掌握全局并指导一个组织的领导如何帮助Scrum团队成功实现敏捷转型。”

—— Sameer S. Bendre，CSM，PMP，高级顾问，3i Infotech公司

“如果你是敏捷开发或Scrum新手，这本书能够让你快速入门。书中的示例和描述清晰、生动，你常常会发现自己想问的问题在本书中都已经讲到了。”

—— Johannes Brodwall，解决方案总架构师，Steria Norway公司

“Kenny阐述的内容很有条理，对Smalltalk充满感情的人会感到很清晰——Smalltalk是他们使用多年的开发环境，也是Scrum和极限编程诞生的地方。本书把一套完整的、确信能够成功的敏捷原则组织在一起，肯定能为你你带来更有效的敏捷方法。”

—— Rowan Bunning，Scrum WithStyle公司创始人

“介绍Scrum的书已经很多了，但本书采取了一个新的视角：软件实践者能够对照现实情况进行检查。Kenny使用真实世界的例子和清晰的描述，强调了成功实施敏捷开发的坚实基础。读者将理解内建质量的重要性，理性面对现实：我们无法从一开始就把每件事情都做对。我们必须在这个过程中以方式工作并从中学习。书名中虽然有个Scrum，但本书从范围更广的敏捷领域中吸取有效的实践，帮助经理及其团队取得成功。”

—— Lisa Crispin，《敏捷测试》合著者

“Kenny Rubin写了一本这么好的书，我真希望每个从事Scrum开发的人都好好读一读！书中包含Scrum精髓和其他内容的！”

—— Martine Devos，欧洲Scrum先驱，认证Scrum培训师

“我在过去几年间审读过很多有关敏捷的书，所以总是在想一个问题：我们真的需要另外一本吗？就Kenny的书而言，我确信答案是“需要”。从另一个经验丰富的视角来审视常见到问题及我们需要的材料，这是很有价值的。Kenny就具备这样的视角。本书的独特之处是有趣的图标——Kenny首创的一种新的、用于表达Scrum和敏捷的图标语言。我相信你会发现书中这种插图会扩展你的思维，帮助你理解如何使用Scrum。”

—— Scott Duncan，敏捷∕Scrum教练兼培训师

“任何一个接受过Scrum培训或参加过Scrum团队工作的人都会发现《Scrum精髓》是一本非常好的进阶读物。本书深入探讨了如何通过实施Scrum过程，力求得更敏捷，恰到好处地解释了如何把复杂项目分解为可管理的项目（或冲刺）。对于在各种组织中有效或无效的做法，Kenny Rubin都给出大量相关的案例学习。布局简单、商用风格的图标使得本书更易于快速浏览和查找特定主题。任何一个寻求从传统瀑布方法提升到敏捷方法论的组织都会发现《Scrum精髓》是这个旅程必不可少的行动指南。”

—— Julia Frazier，产品经理

“开发软件的难度很大。一边做项目，一边采取一种新的工作方法，难度更大。这本书让大家能避免很多陷阱，加速产生商业价值的能力，加快成功使用Scrum的过程。我真希望我在开始使用Scrum时能够看到这本书。”

—— Geir Hedemark，开发经理，Basefarm AS公司

我确信《Scrum精髓》将成为下一代Scrum实践者的基础参考书。它不仅是今天能够得到最全面的Scrum的读本，而且写得非常棒，通过新引入的Scrum可视化语言，让读者能够一目了然。本书的优点还不止这些，Kenny还分享了大量可供我们学习的有价值的个人观点和经验。”

—— Ilan Goldstein，敏捷方案经理，励德爱思唯尔公司（Reed Elsevier）

“Scrum看起来简单，但实际上很复杂。在《Scrum精髓》中，Kenny Rubin向我们提供了解决这些复杂问题的行动指南，而且很重要的是，书中的内容非常简洁。实战经验加上发人深思的描述，让Scrum更接近真实世界。高级经理及相关的团队成员，如果你们正在考虑是否实施Scrum，那么这是一本必读书。这本书我肯定会推荐给我的学生。”

—— John Hebley，Hebley & Associates公司

“Kenny在《Scrum精髓》中提供了大量的真知灼见与知识，为敏捷／Scrum实际应用提供了有价值、广泛的见解。不论你是敏捷新手还是希望持续改进以获得更高的成熟度，本书都是工具箱中必不可少的午要参考。”

—— David Luzquiños，敏捷推广主管，敏捷教练，Betfair 公司

“Kenny Rubin再一次清晰地介绍如何以注重实效的方式实施敏捷。一方面，他重视正式的或者说典型的Scrum定义，另一方面，他重视从务实的角度使用这个定义。在这本新书中，他把他们公司多年积累的知识和他多年的经验带给读者。如果你准备开始敏捷之旅或在旅途中需要帮助，这本就够。”

—— Cuan Mulligan, 独立共创式敏捷教练

“在第一本关于Scrum的书出版十年之后，是时候把Scrum框架的基本内容与过去十年间的实际经验和方法结合在一起了。Kenny Rubin以令人欣慰和非教条的方式做到了这一点。对于何时以什么方式实施Scrum以取得商业利益，本书提供了实用的概述和知识。”

—— Yves Stalgies博士，IT主管，www.etracker.com公司

“采用Scrum的最成功的方式是每个参与者——甚至是一些外围参与者——都能很好地理解其基本内容。《Scrum精髓》以通俗易懂的方式完美展示了概貌和细节。本书是当之无愧的标准参考书。”

—— Kevin Tureski，Kevin Tureski咨询公司总裁

推荐序1

Mike Cohn

著作有《Scrum敏捷软件开发》、《敏捷估算与规划》与

《用户故事与敏捷方法》，www.mountaingoatsoftware.com

我今天的午餐是在汉堡王餐厅吃的。墙上贴着一幅“皇堡之家”的海报，告诉人们皇堡可以有很多种点法。泡菜、番茄、生菜和奶酪可以多要一点，也可以不要，各种各样的组合，能做出很多种汉堡包。实施Scrum的可行方式也必然有很多很多种。不过，虽然条条道路通罗马，但不同的方式还是有好坏之分的。

在《Scrum精髓》中，Kenny Rubin帮助读者找到了更好的方式。他的书讲述的不是规范——他不会说 “你必须得这样做。”相反，他传授的是帮助Scrum取得成功的基本原理。比如，在做冲刺规划时没有一个普遍适用于所有团队的套路。适用于某个公司或项目的方法在另一个公司或项目中却行不通。Kenny给我们提供了一些选择。但是最终的决定权在于每个团队。幸运的是，这些团队现在可以求助于这本书。

《Scrum精髓》我们带来的一个意外好处是Kenny引入的、用于表达Scrum的视觉语言。书中这些视觉图标图对理解文字内容非常有帮助，我估计今后人们在讨论Scrum时会常常使用这些图。

我们早就该有这样一本书了。Scrum最初是一个小概念。第一本讨论它的书——DeGrace和Stahl写的Wicked Problems, Righteous Solutions只有6页。但在那本书面世20多年后，Scrum得到了扩充，引入并细化了新的角色、会议和工件。每增加一个内容，我们都面临着丢掉Scrum核心内容的风险——部分核心内容阐述的是团队如何规划，如何先做一小部分，然后反思团队的工作完成情况，看看有哪些值得肯定（改进）的地方。

在《Scrum精髓》一书中，Kenny把我们带回Scrum核心。在这个基础上，Scrum团队可以开始做实施Scrum的必要决策，做出适合自己的决策。本书是一个不可或缺的指南，可以帮助团队在林林总总的Scrum实施方式中选择并找到适合自己的成功之路。

推荐序2

Ron Jeffries

当Kenny邀请我为他的《Scrum精髓》写一篇序的时候，我就在想：“这事儿做起来快，简单，它肯定是一本很直白的、简单描述Scrum的书。”我对Ken简洁明快的工作风格非常了解，所以知道他的作品肯定也是这样的，甚至肯定比我想象的还好！

所以呢，当我看到这本书几乎涵括Scrum“处女航”的全部精髓时，你完全可以想像我的感受，简直是又惊又喜！而且，Kenny还更进一步。他从核心的理念入手，包括所有敏捷方法底层的敏捷原则，概览了Scrum框架。他还深入到细节进一步探究。这本书可读性强，而且内容丰富，耐读。Kenny 对规划的详细描述恰到好处，他还谈到需求、故事和PBI估算、速率。随后还带我们深入敏捷原则，帮助我们处理所有级别的规划和所有时间范围。他描述了如何规划、执行、回顾和改进冲刺过程。贯穿全书，他在介绍基础知识之外，还重点强调了我们在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核心及其相关实践、有助于培养敏捷交付能力的参考书！

自2007年我有幸引入和翻译第一本Scrum书籍《Scrum敏捷项目管理》（Ken Schaber著）之后，见证着敏捷和Scrum在中国软件及产品研发行业的应用和演进，业界人士和许多团队的不断深入实践及锲而不舍的多样化尝试，也目睹许多组织和团队的迂回之路和成功发展敏捷能力的成就感，但同时也对他们的困惑和挣扎感同身受。Scrum框架有强大力量，其生命力来在于其简约，但要想获得成效，何其容易！

感谢业界同行的热情与努力，此数年间陆续有新的Scrum相关书籍进入市场。每一本书都有其独到之处。这本《Scrum精髓》也给我们带来惊喜，在业界需要的时候来到中国。

条条大路通罗马。Scrum框架不变，彰显其精髓和价值观的实践和形式确实是在不断探索和演进中。有许多的实践和招式是基于具体上下文、有针对性地以落地试验的方式得出的。这些何尝不是敏捷精神和本质的体现呢？

若是Scrum新手，你会从本书中收获扎实的Scrum基础和本质；若已有相当的实操经验，你会从中发现丰富且有参考价值的实例。我相信其中一些能为你指点迷津；若你的工作环境非常关注规划，则可以参考本书针对不同层面的敏捷规划和多种商业情景介绍的应对方式、相关推荐以及详细的分析。

另外，令人眼前一亮的是书中使用的敏捷视觉化图标语言，这是Ken原创的，相信会使大家的阅读体验和Scrum应用体验更上一层楼。

通过这本书，让我们一起帮助自己、团队与组织继续发扬和发展频密交付和持续改进的的能力。

译者序

《Scrum精髓》名副其实，从方方面面诠释了Scrum的精髓。在本书中，不仅有敏捷宣言和原则的解读，更有敏捷适用性的探索。Ken首先介绍Scrum的框架和核心概念（Scrum活动、角色以及工件），接下来专门介绍如何解决技术债问题，经理在Scrum中的角色，Scrum的规划应该如何做，包括组合规划、产品规划、版本规划以及迭代计划。

Ken在第3章中从经济学的角度结合精益软件开发对敏捷原则重新进行梳理。分别从可变性和不确定性、预测和适应、经验认知、WIP、进度和执行几个方面进行阐述。

Ken还喜欢将敏捷联系到生活中。在第14章，Ken提到他的朋友John滑雪之前不会预先进行详尽规划，但会提前研究地形，先了解大概路线。这个例子生动说明了在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某个特定方面或具体方法但没有深入覆盖整个Scrum框架；如果就想通过一本书了解Scrum精髓，选择余地就比较多了，市面上这样的书很多!

《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章）。其余各章分为四个部分进行描述。

l  第I部分“核心概念”(第2～8章)，涉及的主题有：Scrum框架，敏捷原则，冲刺，需求与用户故事，产品列表，估算与速率，技术债。

l  第II部分“角色”(第9～13章)，涉及的主题包括：产品负责人、ScrumMaster、开发团队、Scrum团队构成和经理。

l  第III部分“规划”(第14～18章)，主题包括：Scrum规划原则、多层级规划、产品组合规划、构想/产品规划和版本规划。

l  第IV部分“冲刺”(第19～22章)，主题包括：冲刺规划、冲刺执行、冲刺评审和冲刺回顾。

如何使用本书？

正如大家期待的一样，我写这本书时假设大多数读者都会从头到尾顺序阅读。所以，如果你是Scrum新手，建议采用这种方法，因为各章之间本来就是承上启下，前后连贯的。也就是说，如果想找到一个合适的起点从头到尾了解Scrum框架（一个非常清楚的Scrum扫盲读本），请阅读和参考第2章。

熟悉Scrum的人，则可以把这本书用作Scrum参考指南。如果对冲刺回顾感兴趣，可以直接翻到第22章开始阅读。如果想探究产品列表的细枝末节，可以直接阅读第6章。不过，我强烈建议每个人都完整读一读第3章，即使是熟悉Scrum的人。这一章所介绍的原则是Scrum框架和本书其余内容的基础，其他大多数文献都只是简单而泛泛地重复敏捷宣言中提到的价值观和原则(Beck et al. 2001)，这一章却不是。

视觉图标语言

我很自豪，我在书中采用一种新的视觉语言来描述Scrum。这种语言由一系列图标构成，这些图标体现了基本的Scrum角色、工件和活动。我这个Scrum视觉语言是一种有效的沟通工具，有利于团队成员之间交流想法并增强对Scrum的共识。如果你很想得到和使用这些让人耳目一新的彩色版Scrum插图，请访问www.innolution.com了解更多信息。这个网站还有各种资源和本书相关讨论。

心动不如行动

好吧，不管什么角色，处于什么状况，你已经因为某种原因而拿起了这本书。在字里行间找到适合自己的强大框架，以可持续的步调改善开发方式（方法和流程），交付让客户欣欣然的产品和服务吧！

致谢

如果没有很多人的提供的素材，包括我的上万名学员（参加过我的敏捷课程和辅导班），这本书是不可能完成的。我可能没有提到所有人，我想说，尽管有这种可能，但对我而言，我和大家的所有讨论以及邮件往来弥足珍贵，也毫无疑问对本书产生了影响！

有三个人我要特别感谢：Mike Cohn、Rebecca Traeger和Jeff Schaich。如果没有他们每个人的参与，这本书不可能成形。

Rebecca Traeger是我这本书的私人编辑。早在2007年我还在Scrum联盟担任执行总裁时，我们就一起共事。那时Rebecca是Scrum联盟网站的编辑，并通过这份工作（以及后来其他更多的工作）成为业内杰出的敏捷编辑。在刚开始写本书时我找到Rebecca，问她是否愿意再次与我合作，让我感到欣慰的是，她同意了。每一章拿给别人之前，都是Rebecca先过目。她的反馈时不时让我感到羞愧，因为她常常“雕琢”我的说辞，使其更容易理解，读起来更亲切。如果你喜欢书中的某个章节，那肯定是Rebecca润色过的。如果你不喜欢书的某个章节，那可能是因为我愚蠢地忽略了她的建议。

Jeff Schaich是一个才能非凡的艺术家兼设计师。我和他合作的插图项目多得数不清。早在构想本书时我就想创造一种敏捷∕Scrum图标语言作为我的培训材料以及本书200多幅插图的基础。我知道自己需要一个优秀的设计师来完成这一壮举。Jeff接受了这个挑战。这本书一度看上去像是两个不同的项目——一方面是码字儿，一方面进行艺术创作。说实在，我不知道哪部分工作花的时间更长一些。不过可以肯定，没有Jeff的艺术点缀，本书将大为失色。

我非常荣幸地请到敏捷社区的两位名人Mike Cohn和Ron Jeffries为本书作序！他们用各自独特的方式写了很棒的序言，把这本书放到合适的语境中，开启讨论《Scrum精髓》的大门。我想说：“Mike，不要再吃汉堡王了。”“Ron，多谢你没有按下那个红色按钮！”

我还想感谢很多其他在百忙之中抽出时间评审并把反馈意见告诉我的人。首先感谢反馈最多的人：Joe Balistrieri，Johannes Brodwall，Leyna Cotran，Martine Devos，Scott Duncan，Ilan Goldstein，John Hebley，Geir Hedemark，James Kovacs，Lauri Mackinnon，Robert Maksimchuk及Kevin Tureski。

此外，我想感谢其他给出很好反馈意见的人：Lyssa Adkins，John Bauer，Sameer Bendre，Susan Briscoe，Pawel Brodzinski，Rowan Bunning，Josh Chappell，Lisa Crispin，Ward Cunningham，Cornelius Engelbrecht，Julia Frazier，Brindusa Gabur，Caroline Gordon，Drew Jemilo，Mike Klimkosky，Tom Langerhorst，Bjarne Larsen，Dean Leffingwell，Maurice le Rutte，David Luzquiños，吕毅，Shay McAulay，Armond Mehrabian，Sheriff Mohamed，Cuan Mulligan，Greg Pease，Roman Pichler，Jacopo Romei，Jens Schauder，Bill Schroeder，Yves Stalgies，Branko Stojakovi，Howard Sublett，Julie Sylvain，Kevin Tambascio，Stephen Wolfram及Michael Wollin。

我还想感谢培生（Pearson）的工作人员，他们是这个项目优秀的搭档。他们耐住性子容忍我的拖延并始终鼓励我。特别感谢Chris Guzikowski，他自始至终全力负责这个项目。从我和他在麻省莱克星顿一间酒吧的第一次会面开始，直到本书最终出版，都有他的身影。我也要感谢Olivia Basegio熟练负责后勤工作，感谢Julie Nahil在项目管理上的出色表现。此外我还要感谢Barbara Wood帮助我润色书稿，工作做得棒极了。感谢Gail Cocker把所有的艺术元素整理成一个统一、漂亮的体系。

我还要感谢我的助理Lindsey Kalicki，她让我能够把很多重要的任务交给她，让我专注于本书的写作。能够与能力这么强的专业人士共事真是幸运。

最应该感谢我的家庭——Jenine、Jonah和Asher——感谢他们以及他们发挥的重要作用。在本书漫长的写作过程中，他们为我付出太多。我给家庭带来的压力以及我们错过的彼此陪伴时间，千言万语也不足以弥补我的歉意。

Jenine，我挚爱的知己，本书写作过程中的起起伏伏她都挺过来了。如果能在书中把她做出的牺牲都列出来，这本书还要再厚上一倍。如果没有她，我无法完成这本书！

有趣的是，在我们结婚的第二年，也就是1994年，我出版了我的第一本书Succeeding with Objects。那时Jenine要我保证今后再也不写书了。幸运的是，那个保证在15年后慢慢被淡忘，超负荷的工作量现在看来也没有那么可怕，所以当她鼓励我再写一本书时，我的感觉写书这件事儿何足惧哉！她现在还没有要求我不能再写第三本书，不过我估计这段记忆至少会持续15年，然后我们两人中的一个会要求我再写一本！

我还要深深地感谢我的两个儿子Jonah和Asher的爱心支持。他们放弃了父亲的陪伴，让我能够安心写作。他们总是谈论一些想法，提出一些建议。他们在内容和艺术方面的一些建议被纳入书中——因为他们，这本书变得更好！我希望他们理解坚持不懈的价值，一次一步，不轻言放弃，即使是最令人生畏的工作，也能做好。

最后，我要感谢我的妈妈Joyce Rubin（Genesha Esther bat Avrahm），谢谢她对我的全身心的爱和支持。在她的影响下，才有这本书的问世。令人伤感的是，她在生前没有看到本书的出版。她于2012年1月离开人世，给她的家庭和我留下永远无法弥补的遗憾。在所有认识她的人心目之中，她是一个特别的存在。妈妈，千言万语也无法表达我对你的思念之情。

著译者简介

Kenneth S. Rubin

提供Scrum和敏捷方面的培训、辅导，帮助公司以富有成效、经济合理的方式开发产品。Kenny是一名认证的Scrum培训师，为18 000多人做过敏捷和Scrum、Smalltalk开发、面向对象项目的管理以及转型管理方面的培训。他辅导过的公司超过200家，有初创企业，也有《财富》榜排名前十的公司。

Kenny是Scrum联盟的第一任执行总裁，Scrum联盟是全球性的非盈利组织，致力力推广Scrum的成功应用。除了本书，Kenny还是1995年出版的Succeeding with Objects: Decision Frameworks for Project Management的合著者之一。他拥有了乔治亚理工学院的计算机科学学士学位和斯坦福大学的计算机科学硕士学位。

Kenny的技术背景源于面向对象技术社区。他最初是一名Smalltalk开发人员，在1985年参加了NASA资助的一个项目，开发了第一个非LISP语音写的黑板专家系统。他在1988年幸运地加入ParcPlace Systems公司，施乐帕克新成立的一个分公司，该公司的宗旨是让面向对象技术走出实验室，走向世界。Kenny在20世纪80年代末和整个90年代为很多不同的组织做过咨询，他是敏捷实践方法早期的采用者。他第一次使用Scrum是在2000年，用于开发生物信息学软件。

Kenny在职业生涯中从事过很多岗位的工作，包括成功地担任过Scrum产品负责人、ScrumMaster和开发团队成员。此外，他还担任过很多管理角色：CEO、COO、工程部副总裁、产品管理副总裁、专业服务副总裁。他还管理过5个商业软件产品套件的开发工作，产生的总收入超过2亿美元。此外，他还直接参与风险投资融资项目，融资金额超过1.5亿美元，还帮助两家公司在纳斯达克（NASDAQ）上市。

Kenny丰富的背景使他能够从开发团队和管理层等多个角度深入、透彻地理解（并解释）Scrum及其含义。

目    录

第1章  引子... 1

什么是Scrum？... 2

Scrum的起源... 3

为什么要用Scrum？... 5

Genomica取得的成果... 6

Scrum能给你带来帮助吗？... 6

复杂域... 9

繁杂域... 10

简单域... 10

混乱域... 10

无序... 11

事务性工作... 11

结语... 12

第Ⅰ部分核 心 概 念

第2章  Scrum框架.... 17

概述... 17

Scrum角色... 19

产品负责人... 20

ScrumMaster 20

开发团队... 21

Scrum活动与工件... 21

产品列表... 23

冲刺... 25

制定冲刺计划... 26

冲刺执行... 28

每日例会... 29

完成... 31

冲刺评审... 32

冲刺回顾... 33

结语... 34

第3章  敏捷原则.... 35

概述... 35

可变性和不确定性... 37

积极采用有帮助的可变性... 38

采用迭代和增量开发... 39

通过检视、调整和透明充分

利用可变性... 42

同时减少各种各样的不确定

因素... 43

预测和适应... 44

不到最后时刻，不轻易

做决定... 44

承认无法一开始就把事情

做对... 45

偏好适应性、探索式的方法... 46

用经济合理的方法接受变化... 48

平衡预测性的事前工作和

适应性的刚好及时工作

之间的关系... 51

经验认知... 52

快速验证重要的假设... 52

利用多个认知循环并行的

优势... 53

妥善组织工作流程以获得

快速反馈... 54

WIP. 56

批量大小要经济合理... 56

识别并管理库存以达到良好的

流动... 57

关注闲置工作，而非闲置

人员... 59

考虑延期成本... 61

进度... 63

根据实时信息来重新制定

计划... 63

通过验证工作结果来度量

进度... 63

聚焦于以价值为中心的交付... 64

执行... 65

快速前进，但不匆忙... 65

以质量为魂... 65

采用最小够用的仪式... 66

结语... 68

第4章  冲刺.... 71

概述... 71

时长限定... 72

设定WIP数量限制... 72

强制排列优先顺序... 73

展示进度... 73

避免不必要的完美主义... 73

促进结束... 74

增强可预测性... 74

持续期短... 74

容易规划... 74

反馈快... 74

投入产出比高... 75

错误有限... 75

有助于“满血复活”... 75

检查点多... 76

一致的持续期... 77

有节奏感... 78

简化规划活动... 79

锁定冲刺目标... 80

什么是冲刺目标？... 80

共同承诺... 80

是变更，还是澄清？... 80

变更引起的后果... 81

注重实效... 83

异常终止... 84

完成的定义... 85

什么是完成的定义？... 86

完成的定义可以随时间演变... 88

完成的定义还是接收标准？... 89

完成还是完成-完成... 90

结语... 91

第5章  需求与用户故事.... 93

概述... 93

利用对话... 96

逐步细化... 97

用户故事是什么？... 97

卡片... 98

对话... 99

确认... 100

详细程度... 101

好故事的INVEST原则... 104

独立... 104

可协商... 105

有价值... 106

可估算... 107

大小合适... 108

可测试... 108

非功能性需求... 109

知识获取型故事... 110

收集故事... 112

用户故事写作研讨会... 112

绘制故事地图... 113

结语... 115

第6章  产品列表.... 117

概述... 117

PBI 118

产品列表的四大特征... 119

详略得当... 119

涌现的... 120

做过估算的... 121

排列优先顺序的... 122

梳理... 123

什么是梳理？... 123

由谁来梳理？... 124

何时梳理？... 125

就绪的定义... 127

工作流管理... 128

版本的工作流管理... 129

冲刺的工作流管理... 130

产品列表有哪些，应该有多少？... 131

什么是产品？... 132

大型产品，层级化列表... 133

多个团队，一个产品列表... 135

一个团队，多个产品... 136

结语... 137

第7章  估算与速率.... 139

概述... 139

何时估，估什么？... 141

组合列表条目的估算... 141

产品列表条目的估算... 142

任务估算... 143

PBI估算的概念... 143

团队估算... 144

估算不是承诺... 145

准确与精确... 146

估算相对大小... 147

PBI估算的单位... 149

故事点... 149

理想天... 149

规划扑克... 150

估算... 151

活动规则... 152

好处... 155

什么是速率？... 155

计算速率范围... 156

预测速率... 157

影响速率的因素... 158

速率的误用... 160

结语... 161

第8章  技术债.... 163

概述... 163

技术债的后果... 165

爆发点不可预期... 165

交付时间延长... 166

缺陷数量可观... 167

开发和支持成本上升... 167

产品萎缩... 168

可预测性降低... 168

表现越来越差... 168

挫折感四处弥漫... 168

客户满意度降低... 169

技术债的起因... 169

如期完工的压力... 169

试图以错误的方式提高速率... 170

误区：减少测试可以提高

速率... 171

债累债... 172

技术债必须加以管理... 173

管理应计技术债... 174

使用良好的技术实践... 174

使用强完成定义... 175

正确理解技术债经济... 175

让技术债可见... 178

让技术债在业务层面可见... 178

让技术债在技术层面可见... 180

偿还技术债... 181

并非所有技术债都应该偿还... 182

行将就木的产品... 183

一次性原型... 183

短命产品... 183

应用童子军规则

（有债就还）... 184

分期偿还技术债... 185

先偿还高息技术债... 186

一边做有客户价值的工作，

一边偿还技术债... 186

结语... 188

第Ⅱ部分Scrum的角色

第9章  产品负责人.... 191

概述... 191

主要职责... 192

管理经济效益... 193

版本层面的经济考量... 193

冲刺级别的经济考量... 194

产品列表的经济考量... 195

参与规划... 195

梳理产品列表... 195

定义接收标准并验证... 196

与开发团队协作... 196

与利益干系人协作... 198

特征∕技能... 198

领域能力... 199

人际交往能力... 200

决策力... 200

责任心... 201

日常工作内容... 201

谁来担任产品负责人？... 204

内部开发... 205

商业开发... 206

外包开发项目... 208

组件开发... 209

产品负责人兼任其他角色... 210

产品负责人团队... 210

产品负责人代理... 211

首席产品负责人... 212

结语... 213

第10章  ScrumMaster. 215

概述... 215

主要职责... 215

教练... 215

服务型领导... 217

过程权威... 217

“保护伞”... 217

“清道夫”... 218

变革代言人... 218

特征/技能... 218

见多识广... 218

善于提问... 219

有耐心... 219

有协作精神... 220

保护团队... 220

公开透明... 220

日常工作内容... 221

履行角色... 222

谁来担任ScrumMaster？... 222

ScrumMaster是全职

工作吗？... 223

ScrumMaster兼任其他角色... 223

结语... 225

第11章  开发团队.... 227

概述... 227

专职团队... 227

主要职责... 228

冲刺执行... 229

每日检视和调整... 229

梳理产品列表... 229

冲刺规划... 229

检视和调整产品与过程... 230

特征/技能... 230

自组织... 231

跨职能的多样化和全面化... 233

T型技能... 234

***手态度... 236

沟通广泛... 237

透明沟通... 239

规模适中... 239

专注、有责任感... 240

工作步调可持续... 242

团队人员稳定... 243

结语... 245

第12章  Scrum团队结构.... 247

概述... 247

特性团队与组件团队... 248

多团队之间的协调... 253

SoS. 253

版本火车... 255

结语... 258

第13章  经理.... 259

概述... 259

塑造团队... 261

定义边界... 261

提供一个清晰而鼓舞人心的

目标... 262

组建团队... 262

改变团队的人员组成... 263

授权团队... 264

培育团队... 265

激励团队... 265

发展团队能力... 266

建立职能领导力... 267

保持团队的完整性... 267

整改环境... 268

传播敏捷价值观... 268

移除组织层面的障碍... 268

使内部各个团队一致... 269

使外部合作伙伴一致... 269

管理价值创造流程... 270

采用系统化视角... 270

管理经济效益... 270

测量和报告... 271

项目经理... 272

Scrum团队中的项目管理

职责... 272

保留单独的项目经理角色... 274

结语... 278

第Ⅲ部分规    划

第14章  Scrum的规划原则.... 283

概述... 283

假设事先无法制定完美计划... 284

事先规划有帮助，但不宜过度... 284

最后责任时刻才敲定计划... 286

关注适应与重新规划胜于

遵循计划... 286

正确管理规划库存... 288

提倡更小、更频繁发布... 289

计划快速学习并在必要时

调头... 291

结语... 291

第15章  多层级规划.... 293

概述... 293

组合规划... 295

产品规划（构想）... 295

愿景... 295

概要产品列表... 296

产品路线图... 296

版本规划... 298

冲刺规划... 300

日常规划... 301

结语... 302

第16章  产品组合规划.... 303

概述... 303

时间安排... 303

参与者... 304

流程... 304

进度安排策略... 306

优先考虑生命周期利润... 307

计算延期成本... 308

估算要准确，不必精确... 311

流入策略... 312

应用经济过滤器... 313

到达率和离开率要平衡... 314

快速拥抱新涌现的机会... 316

为更小、更频繁发布做计划... 317

流出策略... 318

关注闲置工作，

而非闲置人员... 318

设立WIP限制... 319

等待整个团队一起行动... 320

WIP策略... 321

使用边际效益... 321

结语... 323

第17章  构想（产品规划）.... 325

概述... 325

时间安排... 326

参与者... 327

过程... 327

示例：SR4U.. 329

建立愿景... 330

创建概要产品列表... 333

定义产品路线图... 334

其他活动... 337

从经济合理的角度构想产品... 339

瞄准一个实际的信心阈值... 340

关注短期收益... 341

动作要快... 342

花钱买经验认知... 343

使用递增/暂行的资助方式... 344

快速学习并调头

（即快速失败）... 345

结语... 346

第18章  版本规划

（长期规划）.... 347

概述... 347

时间安排... 348

参与者... 349

过程... 349

版本约束... 351

固定一切... 352

固定范围和日期... 352

固定范围... 354

固定日期... 354

可变质量... 355

更新约束... 355

梳理产品列表... 356

细化最小可发布特性... 357

冲刺映射（PBI归位）... 358

版本规划：固定日期版本... 360

版本规划：固定范围版本... 365

计算成本... 367

沟通进展情况... 368

固定范围版本如何沟通... 369

固定日期版本如何沟通... 371

结语

第Ⅳ部分冲    刺

第19章  冲刺规划.... 377

概述... 377

时间安排... 377

参与者... 378

流程... 378

冲刺规划的两种方式... 380

两段式冲刺规划... 381

一次性冲刺规划... 382

确定生产能力... 382

什么是生产能力？... 382

用故事点来表示生产能力... 384

用工时来表示生产能力... 385

选取PBI 386

获得信心... 386

细化冲刺目标... 388

敲定承诺... 388

结语... 389

第20章  冲刺执行.... 391

概述... 391

时间安排... 391

参与者... 391

流程... 392

冲刺执行规划... 393

工作流程管理... 394

并行工作和蜂拥式... 394

从哪个PBI开始... 397

如何安排任务... 397

需要完成哪些工作？... 398

谁来做具体工作？... 398

每日例会... 399

任务执行：强调技术实践... 399

沟通... 401

任务板... 401

冲刺燃尽图... 402

冲刺燃烧图... 404

结语... 406

第21章  冲刺评审.... 407

概述... 407

参与者... 408

准备工作... 410

确定邀请谁参加... 410

安排活动日程... 411

确认冲刺工作完成... 411

演示准备工作... 412

确定谁做什么... 413

方式（方法）... 413

总结... 414

演示... 415

讨论... 416

调整... 416

冲刺评审的问题... 417

签字接收... 417

断断续续地参与... 417

大型开发工作... 418

结语... 419

第22章  冲刺回顾.... 421

概述... 421

参与者... 423

准备工作... 424

定义回顾重点... 425

选择练习活动... 425

收集客观数据... 426

安排回顾日程... 426

方式（方法）... 427

营造氛围... 429

建立共同背景... 429

事件时间线... 431

情绪测震仪... 431

得出见解... 432

确定采取行动... 437

回顾结束... 438

贯彻执行... 438

冲刺回顾的问题... 439

结语... 442

第23章  前进之路.... 443

Scrum，有完？没完！... 443

修行靠个人... 444

分享最佳实践... 444

使用Scrum探明未来之路... 446

整装待发！... 447

后记.... 449

词汇表.... 453

参考文献.... 475

云学院 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。