内容简介本书取材于国际知名敏捷教练的真实经历，展示了她们在辅导团队进行敏捷实践过程中所积累的辅导技巧，凝聚着她们对敏捷辅导的真知灼见，每章还针对特定主题总结了在转型过程中教练和团队可能面对的障碍及其应对方案。本书具有较强的实用性和指导性，适合项目经理、技术总监和敏捷团队的所有成员阅读与参考。推荐序(一)
如果对敏捷软件开发或者是整个软件开发很感兴趣，我有个好消息要告诉你，Rachel和Liz这本书肯定能帮助你。它不仅仅是讲教导，还会讲如何做好整件事情。当我们认真对待一件事情的时候，不管是打高尔夫、弹钢琴、绘画还是瘦身美体，有教练从旁指导通常都会很有帮助。优秀教练熟悉相关领域，可以评估我们现在的进展程度，告诉我们下一步如何继续提升。在我们遇到困难而停滞不前的时候，教练可以帮我们保持积极的心态和气势。
我们大多数人花在工作上的时间，远远比花在副业(例如高尔夫或仰卧起坐)上的时间多。然而，我们却很少甚至得不到帮助以提升自己。事实上，帮助他人、被帮助以及帮助自己的机会就在我们身边。本书将帮助大家发现这些机会并加以充分利用。
敏捷软件开发看似简单，其实不然。它的核心无非是先选择一些东西进行开发，短时间内快速完成，回顾已发生的事情，然后再重复上述过程直至产品完成。没什么东西嘛，对吧？其实，这里面大有文章。大多数尝试使用敏捷方法的团队在很早期就能尝到甜头。最出色的敏捷团队，则能够实现翻倍甚至更高的生产力。这些高绩效团队并不见得比你的团队更聪明，只不过是工作方式更好罢了。每一个团队都需要找到行之有效的更好方式，而这本书讲的就是“发现更好的方式并付诸实践。”
如果是独立敏捷教练，本书能帮助你更好地为客户提供服务。如果是内部教练、ScrumMaster或者是客户/产品负责人，本书能帮助他们为团队提供服务。即使“只不过”是一名团队成员，本书也能够帮到你，因为我们所有人多少都会有些教导他人的机会。
Rachel和Liz带我们把敏捷循环中关键的地方都走了一遍，从组建团队、估计和规划到追踪和演示，再到最后主持回顾会议以提高自己。她们帮我们想办法，例如如何改善“完成”的定义，用什么样的方式测试和构建软件有助于更快完工。她们帮助我们理解整洁代码的重要性以及怎样才能做到这一点。
如今，软件开发相当昂贵且复杂，团队协作也如此。不可能一本书就能包罗万象记录我们需要知道的一切，就是十几本书也不行。Rachel和Liz为我们指明了团队流程最重要的几个方面，提供了很多关键建议帮我们理解并形成自己的实践。她们在每一章列出了我们成长过程中可能会遇到的障碍，还提供了我们需要留意的关键事务检查表。
Rachel和Liz还从她们自己帮助团队的丰富经验中挑出实例与大家分享。真实的故事有助于我们更清楚明白地认识其中的道理，能够知道别人面临相似处境时能够挺过来，我们也会感到更轻松一些。只要知道问题总有解决办法，我们就能冷静下来并做出明智的选择。
这些故事、检查表和障碍足以让你物超所值，更何况还有其他收获？！在“自我成长”这一章，Rachel和Liz还给出了一些进行自我提升的好建议。其中一条建议是，每个月都要阅读一本专业相关的书籍。我建议从这本书开始读。你会为自己的选择深感庆幸的。Ron Jeffries
www.XProgramming.com
2009年7月推荐序(二)
去年，我在公司内部担任敏捷教练时，买了《敏捷教练》的英文版。这本深受无数软件开发专家的赞誉和好评的亚马逊五星级好书，我一读就上瘾，深感相见恨晚。
书中广泛涉猎敏捷软件开发的方方面面，核心是如何教导开发团队适应敏捷开发方式。它是对两位作者多年来丰富实践经验的总结。书中呈现的很多东西，我们在日常开发过程中已经司空见惯，更不觉得有问题。但通过作者的讲解，立即恍然顿悟，心有戚戚焉之余，更有知音的感觉：“哦，原来问题的症结在这里！”在引导我们发现问题后，作者还提供了很多辅导技巧让我们动手实践，轻松自如地破除软件开发中的许多障碍。
这本书最适合软件开发团队的经理和团队组长或ScrumMaster阅读。它指出了敏捷开发中各个角落可能存在的问题，介绍了如何引导团队和组织着手改进，同时还穿插了许多实用性很强的教导技巧。很少有书能像这样讲得丝丝入扣，耐人寻味。最后，作者还告诉我们如何在敏捷教导领域实现持续成长。
如果是刚开始接触敏捷软件开发的新手或项目经理，这本书会帮助你拨开敏捷开发的云雾，发现以前没有注意的许多地方。对读者而言，会觉得书中的很多实例似曾相识，所以很容易产生共鸣。
如果你和我一样，已经在敏捷软件开发领域摸打滚爬很多年，肯定也喜欢总结，而且也总结了不少东西。在这本书中，我们不仅可以找到适合自己的实践，还能学会像作者那样以系统方式讲解敏捷教导的幕后机理，学到更多实用性很强的辅导技巧。
得知本书由徐毅和袁店明负责翻译时，我感到非常欣慰，看来我们将有一本原汁原味的高品质中译本了。两名译者有很良好的语言和翻译功底(徐毅翻译过《管理3.0：培养和提升敏捷领导力》和《Scrum要素》)，是国内敏捷开发一线浸染多年的实践者和布道者，他们不仅积极组织参与国内敏捷活动，还具有高度的热情和责任心，这样的译者是高品质专业图书的绝对保证，因为，他们的专业素质就摆在那里，结果当然是可以预料的了。
最后，我想说的是，如果是团队软件开发，这本书绝对值得珍藏。教导，是一辈子的事情，永远不会过时，因为，时不时地温故知新，实乃人生一大幸事！
蔡煜
新浪微博：@larrycaiyu
2013年6月
译 者 序
初次结识Rachel，是在2007年。她来到杭州诺西，有一场“回顾会议引导师”的培训，还参与引导了我们团队的一次回顾会议，当时我是ScrumMaster。再次见面，已是2009年在葡萄牙里斯本举办的ACME诺西内部敏捷教练大会，她协助组织、引导了这次会议。当时，我已经加入内部名为“Flexible Company”的团队，成为一名专职敏捷教练，我们负责在全球范围内推动诺西产品研发向敏捷转型。作为敏捷教练必读书籍，我们把它推荐给公司内部的所有ScrumMaster和敏捷教练，今年的ACME大会更是直接给参会者每个人都发了一本。
我一读这本书就喜欢上了，爱不释手。它从教练基础讲起，介绍了如何融入敏捷团队，如何着手逐步地推动团队的敏捷实践，如何建立一个持续改进的团队，最后针对敏捷教练如何提高自己给出了很多的建议。我觉得这就是任何一个敏捷教练都应该要阅读的书。于是我开始积极地联系Rachel，主动请缨想把这本书翻译成中文引进国内，Rachel积极回应并联系出版社牵线搭桥。但很遗憾国内出版社认为当时国内敏捷氛围还不够浓厚，敏捷教练这种角色尚未得到大众的关注、了解和认可，未能出版。
如今，敏捷在国内发展得如火如荼，在不同领域都有应用，包括互联网和移动互联网等行业。各种各样的敏捷教练也层出不穷，使用谷歌搜索 “敏捷教练”可以找到近250万条结果，业内关于敏捷教练的各种抱怨声同样不绝于耳。业界急需这样一本专门针对敏捷教练进行指点的书籍。
敏捷教练的工作，并不是做过敏捷开发就能够做好的。自己做得好和教别人做好，根本就是两回事。获得亲身实践敏捷的经验，只是敏捷教练之路的第一步；还要能学会如何讲解帮助人们理解敏捷；还要能通过言传身教等方式指导人们学会如何进行敏捷实践；等等。
在书中，Rachel和Liz将教练工作分为五大不同的活动类型，包括支持、教育、引导、反馈和留意，进行了深入细致地描述。教练工作的本质是与人共事，转变人们的思想和观念，并辅导他们学会使用某些具体的实践、工具和方法，两位作者也在书中分享了很多她们自己的经历和故事，栩栩如生。教练工作中有可能会遇到的各种难题，作者们也都在书中专门罗列出来，还给出了应对这些难题的意见和建议。以敏捷教练辅导团队实践敏捷的时间为顺序，两位作者逐步地指引着读者从介入团队、构建敏捷团队、共同计划、每日站会、保持可见、做到“完成”、以测试驱动开发、整洁代码一直到演示结果、以回顾会议驱动变革，最后则是如何不断地提高自身能力的诸多建议。
这本书必将能帮助国内的敏捷实践者更深入地了解敏捷实践，以及如何以敏捷教练的身份辅导其他实践者和团队学习敏捷。敏捷教练和顾问的工作，做过这么多年之后，我越发觉得这本书实属敏捷教练的必备之选。作为实践性很强的工作，只看书是绝对不行的，务必一边看书一边实践，并不断反思回顾、持续改进，还要与大家多多交流、分享。
徐毅
敏捷教练
2013年5月
前 言
敏捷的宗旨是团队成员齐心协力产出伟大的软件。作为一名敏捷教练，你可以帮助你的团队迈出第一步，而后与敏捷共舞，直到所有团队成员完全释放出敏捷潜力。
这本书会告诉你怎么帮助团队激发敏捷的潜能。本书专注于各种实用的建议、小窍门和技术，用于教导团队以提高他们的成效。这本书适合所有想辅导团队进行敏捷开发的人，不管你是项目经理、技术主管，还是软件团队成员，都适合。
敏捷教导的艺术在于理解所处环境和敏捷软件开发潜藏的价值，知道如何把它们糅合到一起。敏捷教练自己并不需要知道所有的答案，找到正确办法需要时间和少量尝试。每次和团队合作我们都很有收获，因为有些团队能够想出非常棒的解决方案。
我们将全方位讲解敏捷实践，从创建计划到部署软件。我们并不局限于少量敏捷方法，而是探究更广泛的一系列实践，例如规划和技术的实践，因为两者结合能带来一个越来越稳固的系统。然而，根据我们的经验，敏捷实践的机理并不难，难在如何辅导人们接受和采纳它们。这正是本书的内容。
通用敏捷
我们共事过的团队多数都混合使用极限编程、精益和Scrum，因此在整本书中，我们所说的敏捷指的就是这个“混血儿”。
图中显示的是敏捷流程的简化版生命周期，一个团队按迭代方式交付软件的过程。迭代最开始是基于用户故事进行规划，最后以评审和回顾会议结束。团队共用同一片工作区域，一天的工作始于团队任务板前的每日站会。他们以测试驱动开发和持续集成的方式创建软件。一些团队采用一周的短迭代，也有一些团队选择一个月的时间间隔。
敏捷教练致力于帮助跨职能开发团队及其业务干系人建立起一种健康的协作关系。不同组织中“客户”的意义各不相同，我们在此用来指代和团队一起工作的业务代表(等同于Scrum中的产品负责人角色)，他们并不承担团队角色的职责。
这个生命周期图展现了敏捷实践相互衔接的方式。不过，并不是非得从最上面的地方开始实施敏捷。团队可以选择从该循环中的任何一个实践处开始起步，随后再逐步地采纳更多实践。
本书的目标
教导工作就是要与人共事。人们属于不同的项目和团队，又都归属于同一个组织。由于每个人、每个项目、每个团队和每个组织都各不相同，所以我们也无法确切地指点你在具体环境下应该怎么做。
我们只告诉你有哪些通用法则是需要遵循的，哪些不同观点的建议需要采纳。
我们没有永远有效的神奇公式，因为环境都是不一样的。取决于团队所处的不同环境，我们可能会给两个团队完全相反的建议。例如，我们通常会建议项目经理参加每日站会，但有时我们也会建议他们别搅和。需要考虑的因素包括团队的规模、承受的压力以及团队成员的经验水平。
整本书里都讲我们应对不同环境的故事，介绍很多有针对性的技巧，大家一旦碰上相似的情形就可以派上用场。你得替团队决定要不要采纳我们的建议。
时间和经验是成为合格敏捷教练的必要条件。读好这本书能丰富你的知识。它能帮你识破教导的圈套，教你提高自己教导水平的窍门。它能给你灵感和想法，帮你学以致用，服务于团队。本书阅读指南
本书各章相对独立。可以随意挑选阅读，也可以按顺序阅读。我们先探讨常规的教导原则，然后介绍如何运用这些原则辅导特定的敏捷实践。留点时间看看每章末尾的检查表，仔细想想该怎样将它们用于团队。辅导敏捷团队需要跨越重重难关。我们在各章末尾和大家分享了这些故事，还建议了一些清理障碍的方法。不是想做一个巨细无遗的清单，只希望能够给你提供一些灵感，帮助你克服难关。
致 谢
感谢我们双方的家人，在他们的支持下，本书才得以面世。本书大部分内容都是在周末和晚上完成的，我们长时间地聊Skype，他们则静候一旁以免打扰我们。
感谢我们双方家庭为我们所做的一切：Don，Alex，Abby和Josh还有Ian，Sapphire和Stephanie。
感谢我们的正式评审：Mike Cohn，Frank Goovaerts，Ben Hogan，Leigh Jenkinson，Colin Jones，Allan Kelly，Turner King，Simon Kirk，Lasse Koskela，Andy Palmer，Timo Punkka，Xavier Quesada-Allue，Dan Rough，Russ Rufer，Karl Scotland，Bas Vodde，Leah Welty-Rieger，Matt Wynne，和Silicon Valley Patterns Group。
还要感谢其他帮我们评审本书并锦上添花的朋友：Esther Derby，Willem van den Ende，Ellen Gottesdiener，Julian Higman，Ron Jeffries，Norm Kerth，Antony Marcano，Richard Lyon，Ivan Moore，Linda Rising，Jerry Weinberg和Rebecca Wirfs-Brock.
同时，还要感谢Ron Jeffries，Michael Feathers，Lasse Koskela，Antony Marcano，Ivan Moore和Karl Scotland为本书贡献的内容。
最后，我们要感谢Pragmatic Bookshelf出版社的Andy Hunt, Dave Thomas和Jackie Carter，尤其感谢我们的编辑Jackie，在过去的一年中，他耐心地辅导我们，帮助我们去芜存精。谢谢你们的支持！目 录
第Ⅰ部分 教导基础
第1章 起步 3
1.1 敏捷教练的职责 3
1.2 养成教导的态度 5
1.3 预备，辅导！ 8
1.4 如何开始教导 11
1.5 保持速度 13
1.6 难关 17
1.7 检查表 18
第2章 与人合作 19
2.1 倾听 19
2.2 给予反馈 23
2.3 化解矛盾 25
2.4 达成共识 27
2.5 难关 28
2.6 检查表 30
第3章 领导变革 31
3.1 引入变革 31
3.2 提问 35
3.3 鼓励学习 40
3.4 引导会议 43
3.5 难关 44
3.6 检查表 46
第4章 建设敏捷团队 47
4.1 帮助团队形成凝聚力 47
4.2 营造团队空间 50
4.3 角色平衡 52
4.4 激励团队 53
4.5 难关 57
4.6 检查表 59
第Ⅱ部分 集体规划
第5章 每日站会 63
5.1 站立 64
5.2 始于团队，服务于团队 65
5.3 处理问题 69
5.4 设定时间 71
5.5 择机辅导 72
5.6 难关 73
5.7 检查表 77
第6章 理解构建目标 79
6.1 用户故事的生命周期 79
6.2 鼓励交谈 80
6.3 与卡片共舞 81
6.4 确认细节 84
6.5 难关 88
6.6 检查表 90第7章 提前计划 91
7.1 为规划做准备 92
7.2 理解优先级顺序 92
7.3 明确工作规模 93
7.4 审查并承诺 97
7.5 追踪注意 102
7.6 难关 103
7.7 检查表 107
第8章 公示进展情况 109
8.1 团队板 109
8.2 大型可视化图表 115
8.3 维护团队板 118
8.4 难关 119
8.5 检查表 120
第Ⅲ部分 关心质量
第9章 做到“完成” 125
9.1 谁来做测试？ 125
9.2 定义“完成”的意义 126
9.3 测试的规划 128
9.4 缺陷管理 129
9.5 尽早得到反馈 134
9.6 从未完成中复苏 135
9.7 难关 137
9.8 检查表 138
第10章 测试驱动开发 139
10.1 引入测试驱动开发 139
10.2 持续集成 146
10.3 保持使用TDD 150
10.4 难关 152
10.5 检查表 153
第11章 代码整洁 155
11.1 增量式设计 155
11.2 集体代码所有权 160
11.3 结对编程 165
11.4 难关 168
11.5 检查表 170
第Ⅳ部分 倾听反馈
第12章 演示成果 175
12.1 准备演示会议 176
12.2 每个人都要上场 180
12.3 发布软件 183
12.4 难关 184
12.5 检查表 186
第13章 以回顾驱动变革 187
13.1 引导回顾会议 188
13.2 策划回顾会议 197
13.3 更大范围回顾 199
13.4 难关 200
13.5 检查表 201
第14章 自我成长 203
14.1 增长见识的方式 203
14.2 制定计划 207
14.3 构建自己的人脉 207
14.4 个人反思 209
14.5 放松，要淡定 212
14.6 检查表 214
关于作者 215
关于译者 216
