本书通过一个关于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团队的故事，介绍团队成员如何一起面对共同的挑战，从而交付有价值的产品增量。书中讨论他们在使用Scrum时所学到的知识，以及他们如何优化合作方式。在叙述上，本书结合案例研究与相关讨论，首先介绍Scrum团队遇到的特定挑战，然后探索应对该挑战的替代方案。
你应该从头读到尾，跟随书中的故事学习。各章遵循以下大纲：
第1章　介绍Scrum团队并描述它是如何运转的。本章重点介绍开发团队（Development Team）和产品负责人之间的协作。产品待办列表、Sprint待办列表与产品增量是在快速变化的环境中保证透明度所需的工具。本章将演示这些工具如何帮助Scrum团队成员计划和组织他们的工作。
第2章　讨论为什么在Scrum方面已经积累了一些经验的新手Scrum团队有时会认为Scrum不起作用。得出此结论的大部分原因在于其实现Scrum的方式死板。团队虽然在践行这些方法，但对Scrum的特定规则或某些工具的认识不到位。
第3章　讨论策略和产品待办列表精化，以及跨职能与不断变化。《Scrum指南》描述了团队解决复杂适应性问题的框架。Scrum团队必须找到并定义自己的工作方式以及想要成功所使用的工具。
第4章　描述DevOps的理念、DevOps与Scrum的关系，以及它可以如何进一步改进Scrum团队的工作。Scrum团队最重要的成果是产品—《Scrum指南》称之为“可发布的产品增量”。这是最低要求。
第5章　探讨一个不可避免的事实，即当人们密切合作时就会产生冲突。某种程度的冲突是正常的、健康的，但是，它可能会升级并成为团队和组织的问题。本章描述冲突的来源和解决方法。
第6章　讨论Scrum团队可以使用的度量标准，以及度量标准可能被滥用而因此失去价值。组织要想知道各部门的工作效果，绩效和成功的度量是必不可少的。
第7章　重点介绍管理的角色及其对Scrum团队的重要性。本章将描述传统管理在敏捷环境中面临的常见挑战及其解决方案。
第8章　描述Scrum团队需要在什么样的组织中运转。本章将讨论传统组织和Scrum团队之间的常见冲突领域，例如层级制度，以及对项目而非产品的思考。你将看到Scrum团队要想成功协作需要什么条件。
第9章　强调Scrum中的改进被描述为 “持续的”是有原因的。成为一个Scrum团队的道路永远没有尽头，向Scrum的过渡也永远不会结束。
请不要把书中讲的故事当作Scrum“模样”的蓝图，它不是这样的。我们的团队探索Scrum，并做出与我们在真实团队中看到的相同或相似的决策。这些决策有时是错误的，之后必须改正。Scrum需要去探索与体验，其实现方式并不是唯一的。
我们希望你能从本书中得到更多的乐趣，也希望你能从Scrum中得到更多的乐趣。

Acknowledgements?致　　谢
养育一个孩子需要全村的力量。
—非洲谚语
我认为这句谚语适用于全天下的孩子。在过去的几年里，我发现这句谚语也同样适用于图书。一本书的诞生真的需要很多人。在此我想特别感谢几个人，他们对这本书至关重要。
首先，我要感谢Uwe M. Schirmer的合作支持。从本书最开始的想法到结尾，我们一直在一起工作。我和他一起写了这本书的初稿（你应该庆幸没有读过），在这个过程中，我们学到了很多写书的禁忌。遗憾的是，由于他日程繁忙，因此无法全身心地投入到这本书的第二稿中。我很感激他付出的时间和给我的支持。
接下来，我要感谢Kurt Bittner对本书的指导与贡献。他帮助Uwe和我起草第一稿，然后在创作第二稿的过程中给予我很大帮助。我从他那里学到了很多关于写作和英语语言的知识。我很惊讶他竟能如此快地看完书稿，并提供建设性的、有帮助的、切中要害的反馈。感谢他在写作的最后阶段更加积极地参与，感谢他对有关管理和组织的章节所做的贡献。
我还要感谢Scrum.org的所有支持，尤其是Ken Schwaber、Dave West、Sabrina Love和Eric Naiburg。感谢Dave和我分享这个系列丛书的想法，特别感谢他为本书作序。非常感谢Ken给予第一稿的评价，不然Uwe和我就无法改进我们的成果，也就无法有效地了解早期反馈的好处。感谢他们共同创建Scrum并为我们带来了灵感。非常感谢Sabrina的设计，不仅仅是她对本书的设计，还有每次Scrum.org的培训师冒出新的视觉想法却不知道如何实现时的设计。我特别喜欢她设计的封面。非常感谢Eric对本书内容与阅读人群划分的帮助。
没有我们的专家评审，这本书就不会是今天的样子。他们提供了很多很好的建议，给的反馈也很准确直接。非常感谢Helen Sedlmeier、Oliver Hankeln、Jürgen Mohr、Mikkel Toudal Kristiansen、Thomas Barber、Svenja Trampisch、Thomas Schissler、Marc Kaufmann和Kim Nena Duggen。他们为那些我认为已经“完成”的部分输入的许多有价值的东西总是令我感到惊喜。
我的同事Stefan Toth慷慨地允许我们使用他的视觉设计来制作架构饼图。非常感谢他的这个隐喻，我只敢在快到饭点的时候用，因为它会让我感到很饿。
特别感谢Pearson和每一位助力本书成形和完善的人。我想他们应该是帮助孕育此书的“村民”主力，而我只能想到那些与Uwe、Kurt和我直接合作的人。因此，我要感谢我们的原始编辑Chris Guzikowski和现任编辑Haze Humbert，他们给予我们建议与支持，也是我们与Pearson的直接联系人。
最后，我要特别感谢我的妻子和三个孩子在我写作本书的过程中给予我的耐心。原来“工作量应该不大”是个谎言，谁会想到呢？

Peter G?tz是一名顾问、培训师和教练。他于2001年开始从事Java软件开发工作，并于2006年进入咨询行业。他也是Scrum.org的专业Scrum培训师，自2008年以来一直以Scrum教练的身份协助团队。作为专业Scrum开发人员培训的负责人之一，他负责维护、开发课程材料和学习路径。他对软件架构和DevOps充满热情，喜欢讨论如何使用现代架构风格和工程实践来改进Scrum团队的工作流程。
Uwe M. Schirmer是一位认证的Scrum专家、软件架构师、项目经理和需求工程师。他于 20 世纪 80 年代开始从事计算机方面的工作。经过两次职业教育后，他在德国富尔达应用技术大学学习计算机科学。他自1996年起担任培训师，自2000年起担任不同客户和项目的顾问。如今，他在埃森哲解决方案智库（Accenture SolutionsIQ）担任敏捷教练和软件架构师，在帮助组织实现现代化的同时，兼顾其应用程序和基础设施的产品、质量和体系结构。他的主要兴趣是敏捷软件开发、浮现式设计和架构、软件架构编档、DevOps、开发团队和组织文化的演进。
Kurt Bittner在帮助团队在短反馈驱动周期内交付软件方面（作为开发人员、产品经理、产品负责人、行业分析师以及组织变革代理人）拥有超过35年的经验。除了发布许多博客和文章外，他还与人合著了许多有关软件工程的书籍。他目前是Pearson出版的Scrum.org系列图书的丛书主编。

序
前言
致谢
作者简介
第1章　成为一个高效的Scrum团队　001
1.1　产品负责人与开发团队之间的协作　003
1.1.1　不要把业务和IT分开　005
1.1.2　为有价值的产品负责　006
1.1.3　协助管理产品待办列表　007
1.1.4　Sprint范围不是固定的　008
1.1.5　产品负责人参与　010
1.2　创建Scrum团队的透明度　011
1.2.1　假设驱动的产品待办列表　012
1.2.2　产品待办列表驱动对话　013
1.2.3　着眼于大局　016
1.2.4　产品待办事项需要创造价值　 017
1.2.5　Sprint待办列表不仅仅是一个任务板　019
1.2.6　应该由谁来更新Sprint待办列表　020
1.2.7　Sprint待办列表不应该被隐藏　021
1.2.8　Sprint待办列表作为进度报告　022
1.2.9　工作燃尽图很少是完美的　023
1.2.10　防止Sprint待办列表过时　024
1.2.11　完成代表着可发布　026
1.2.12　度量和验证产品的价值　027
1.3　总结　028
第2章　常见问题　029
2.1　缺少基础知识　031
2.1.1　Scrum的早期失误　032
2.1.2　缺少共同的价值观　034
2.1.3　缺少产品愿景　037
2.1.4　缺少跨职能特质　038
2.1.5　缺少自组织特质　040
2.2　对Scrum的常见误解　041
2.2.1　封闭的Sprint　042
2.2.2　承诺范围　043
2.2.3　会议太多了　045
2.2.4　Sprint评审会中没有利益相关者　047
2.2.5　Scrum不是一种宗教　050
2.3　可以避免的错误　051
2.3.1　只是名义上的Scrum Master　052
2.3.2　太多的产品待办事项　053
2.3.3　舔饼干　055
2.3.4　找不到的产品负责人　057
2.3.5　每周开两次站会　058
2.4　总结　059
第3章　光有Scrum是不够的　060
3.1　战略：顾全大局　061
3.1.1　谁在Scrum中解决战略问题　062
3.1.2　什么是涌现的结构　064
3.1.3　为什么没有文档是个坏主意　067
3.2　策略：从想法到结果　068
3.2.1　产品待办列表的不同抽象层级　069
3.2.2　如何进行有意义的估算　072
3.2.3　当我们有看板时，还需要Scrum吗　075
3.2.4　如何度量成功　077
3.3　如何改进跨职能　079
3.3.1　协作是改进的驱动力　079
3.3.2　每个人都需要做所有的事情吗　081
3.3.3　使用测试先行的方法　084
3.4　应对不断的变更　086
3.4.1　为什么重构是必选项　086
3.4.2　在变成大问题之前解决它们　089
3.4.3　根据原则而不是规则工作　090
3.5　总结　092
第4章　“可发布”小于“已发布”　094
4.1　什么是DevOps　095
4.1.1　它是一个角色……它是一种工具……它是DevOps　096
4.1.2　DevOps与工具有何关系　097
4.1.3　DevOps就够了吗　099
4.2　如何结合Scrum和DevOps　100
4.2.1　DevOps正在取代Scrum吗　101
4.2.2　Scrum允许持续部署吗　102
4.2.3　Scrum原则和DevOps文化是相辅相成的　105
4.2.4　如何使用DevOps改善流动　108
4.3　总结　110
第5章　解决冲突　111
5.1　可以由当事人解决的冲突　112
5.1.1　并非所有的分歧都会导致冲突　112
5.1.2　谁有最终发言权　114
5.1.3　冲突应该由当事人来解决　117
5.2　需要外部干预的冲突　118
5.2.1　升级的健康冲突　119
5.2.2　有些冲突需要暴露出来　123
5.2.3　忠于Scrum团队还是你的部门　125
5.3　需要更强干预的致命冲突　126
5.3.1　给Scrum团队施加压力　127
5.3.2　换一支队伍来保护它　129
5.4　总结　131
第6章　度量成功　133
6.1　朝着目标努力　134
6.1.1　我们需要更快地交付　134
6.1.2　我们是否在交付价值　137
6.1.3　什么是价值　140
6.1.4　实验回路　143
6.2　改进团队成果　146
6.2.1　速率不是绩效　146
6.2.2　如何（不）提升绩效　148
6.2.3　你改进不了你无法度量的东西　152
6.2.4　监控改进，而不是指标　155
6.3　总结　156
第7章　Scrum和管理　157
7.1　Scrum中的管理角色　158
7.1.1　透明不是监视　158
7.1.2　负责不是控制　160
7.2　如何实现自组织　162
7.2.1　领导不是指导　163
7.2.2　自组织并不缺乏管理　164
7.2.3　自组织并不容易　166
7.3　总结　167
第8章　敏捷组织　169
8.1　组织架构既可能帮助Scrum也可能阻碍Scrum　170
8.1.1　新工作，旧环境　170
8.1.2　职能型组织可能阻碍团队发展　172
8.1.3　职能型组织提供了职业发展路径，但要付出代价　173
8.2　复杂的组织需要彻底的简单　176
8.2.1　Scrum可以帮助实现彻底的简单　176
8.2.2　彻底的简单需要彻底的透明　178
8.2.3　用透明取代汇报链和治理流程　179
8.2.