本书客观全面地介绍了全球正在使用的各种敏捷方法的价值、原则、架构、过程和适用场景，包括敏捷方法和瀑布式方法的对比；Scrum、Kanban、XP、Crystal、FDD、Lean、DSDM 等各个敏捷方法之间的对比，需求搜集、规划、评估、跟踪、报告、测试、集成；超越IT 领域的敏捷思想，必需跨越的常见问题及其解决方案等。基于学术研究及亲身经历，通过逼真用例、实际案例以及对先驱实践者发人深思的采访，作者将众多复杂的概念融会贯通，对不同敏捷实践中的关键概念进行了清晰地阐述。
无论你是何角色，也无论你经验如何，《洞悉敏捷》都会为你已经或是即将开启的敏捷之旅打好坚实的基础。
无论你是何角色，也无论你经验如何，《洞悉敏捷》都会为你已经或是即将开启的敏捷之旅打好坚实的基础。
全面介绍敏捷框架|方法论 13位敏捷大咖经验结晶 一线专家联袂推荐
推荐序一
从2001 年2 月17 位签署人在盐湖城雪鸟滑雪场共同推出“敏捷宣言”，从而标志着敏捷方法的诞生开始到15 年后，敏捷方法已经变成了软件开发的主流开发方式。甚至已经不限于软件开发，有数据表明，敏捷方法已经开始从最早的类似于人事系统(注：克莱斯勒的C3 项目是极限编程的源头)，工资系统，互联网软件到传统的核武器系统，编译器，操作系统，实时工业控制，医疗设备系统等。在中国，我们也见到或者帮助大型医疗设备研发团队，石油天然气行业设备研发团队，军工科研向敏捷开发方式转型。
15 年来，随着敏捷方法越来越流行，敏捷方法家族也有了长足的发展，也从最初的Scrum, 极限编程，水晶，DSDM，有发展出了看板、精益以及众多敏捷小工具等等。随着越来越多的组织开始接触敏捷。这些组织不可避免遇到了林林总总的挑战，比如，
? 如何让这些组织了解敏捷方法的关系与区别，从而更好的选择敏捷药方？
? 敏捷方法的背后蕴含的企业文化如何？
? 如何支持传统组织以及传统组织里的各种角色向敏捷工作方式转变？
? 除了教科书上的敏捷，还有那些有用的工具、技巧和方法？
? 敏捷组织里面的各种角色以及他们的职责有哪些？
? 不同敏捷方法中最通用的部分有哪些？
? 在公司发展的不同阶段需要多敏捷？
针对这面这些棘手的问题，您都可以从这本书里面找到一些答案或者启发。
如果您想迅速的了解敏捷方法的概况，并能够快速上手，这本书是一个不可多得的选择。
唤醒者 滕振宇
2015 年·夏
推荐序二
为什么要看这本书
市面上有关敏捷软件开发（下文简称敏捷）的书已经很多了，为什么选择要看这本书呢？这本书非常全面地介绍了敏捷下的各种方法，包括Scrum、看板、极限编程、水晶开发方法、特性驱动开发、精益软件开发以及动态系统开发方法。并且还深入地介绍了每种方法所涉及的团队角色。书中每章最后都会对一名敏捷大牛进行采访，比如Robert C Martin，Alistair
Cockburn，Mike Cohn 等。本书另外一个重要的特色是，在最后一章，专门介绍了IT 之外的敏捷是什么样子的。
敏捷有这么多方法，那么在开始采用某个方法之前，我认为有必要搞清楚为什么要进行敏捷？
为什么要进行敏捷软件开发
敏捷起源于2001 年，有17 位轻量型软件开发的大牛，一起聚集在雪鸟滑雪胜地，最后形成了敏捷宣言和敏捷原则。在随后的十多年里，全球范围内越来越多的企业或组织在进行敏捷的尝试，也有很多成功与失败的案例。那么为什么越来越多的企业或组织要进行敏捷转型呢？
首先，让我们一起来看一下软件开发的本质。软件开发，从根本上来看，是把客户（或用户）的脑袋中的想法，转换成可以工作的软件。这一过程就决定了软件开发的本质是学习与反馈的过程。也就是说，软件开发的第一步是要学习，不断地学习。为了能够真正理解客户（或用户）脑子当中的想法，我们需要不断（在软件开发过程中）去和客户（或用户）沟
通，了解他的行为，学习他的思维模式。从而真正理解客户的需求，而不是只在软件开发前期和后期与客户（或用户）沟通。除了不断学习，软件开发的第二步是反馈。在软件开发过程中，反馈是必需的。在与客户（或用户）不断学习的过程中，我们需要带着可工作的软件去和客户（或用户）学习沟通。只有这样，我们才能得到他们真正的反馈。基于客户（或用户）的反馈，我们再进行调整从而响应变化。因此软件开发的本质就是不断学习和持续反馈。
“新产品开发的规则在发生改变。许多公司已经发现，高质量、低成本和差异化已经很难超越当今市场白热化的竞争。超越市场需要的是速度与灵活性。”为了赢得市场，我们需要足够快的速度和灵活性，也就是说我们需要不断学习客户（或用户）的想法（需求），并且持续获得客户（或用户）的反馈。而敏捷可以完美得符合软件开发的本质。为什么这么说呢？让我们一起看看什么是敏捷。
什么是敏捷
敏捷就是尽早频繁的交付商业价值。具体展开来讲，敏捷是一种带有固定时间盒的迭代增量式软件开发方法。迭代（iterative），指的是需要重构已做的工作（即要改设计）。而增量（Incremental），指的是在现有软件的基础上逐渐增加新功能（不改原来的设计）。固定时间盒，可以使团队在短时间内就获得一些产出，从而可以持续获得客户（或用户）的反馈。因此，敏捷天生就是为软件开发而生的，它和软件开发的本质有机地结合在一起。
最后想要强调的一点是，敏捷不是一种状态，不是说我们到达了某个状态或者地方就代表我们敏捷了。敏捷更像是在路上，我们一直朝着敏捷的方向前进，不断学习与持续反馈。
中国敏捷社区的主要推动者 姜信宝
2015 年·夏
译者序
有人说：没有经历过“焦油坑”项目的软件工程师的人生是不完整的。这当然只是一种调侃，但如果从这个角度来看，我的软件工程师生涯绝对是圆满的。从事软件工作多年来，加班和项目延期一直是那挥之不去的痛。需求的不断变化，每次集成验证都有“惊喜”，大量的缺陷直到项目后期才暴露出来……每次和同事们“战斗”至深夜才离开公司，我都会不停地问自己，解决这些问题的出路在哪里？
寻寻觅觅的探索中，一次偶然的机会我参加了滕振宇的CSM 课程，当我开始了解了敏捷，那一刻犹如闪电划破夜空，真是有一种“一见钟情，相见恨晚”的感觉。多年来的亲身经验告诉我，敏捷这条道路是对的！它让我对未来的软件开发之路又重新燃起了希望和斗志。也正是带着这份希冀，我和我的团队踏上了属于我们的敏捷之旅，而我们这一启程便没有再
停下来。两年来我们的敏捷实践从单个团队、小项目中的试点，扩大到整个部门、大项目中的推广，有力地证明了敏捷方法的有效性。敏捷让我们可以更好的理解需求，响应需求的变化，项目的可控性得到了很大的提升，同时也让身处其中的每位同事都工作的更加开心了。
在享受了敏捷给我们团队带来的收获时，另一份新的希冀也在我的心中渐渐涌动起来：那就是可以让更多的软件从业人员系统的了解敏捷，进而摆脱“焦油坑”项目的魔咒。而《洞悉敏捷》正是这样一本书。
它全面地介绍了目前主流的敏捷方法，包括：Scrum、看板、极限编程（XP）、水晶、特性驱动开发（FDD）、精益软件开发以及DSDM 等。这非常有助于初学者系统的了解敏捷，为后续的实践打好牢固的知识基础。同时，它还提供了目前市面上敏捷相关书籍所不具备的独特视角，那就是在角色、需求、计划、跟踪等维度上横向的对这些主流的敏捷方法进行了客观的比较。这种横向的比较有利于让读者对每种具体的方法产生更加深入的理解，甚至还可能进而激发出一些适合于具体项目的新颖实践。从这方面来讲，即使是有一定经验的敏捷实践者也会从本书中受益良多。本书的还有一个亮点就是囊括了十篇对敏捷先驱者的深度采访，其中不乏像Bob大叔或是Mike Cohn 这样的业界大牛。你想了解敏捷宣言起草的幕后故事？或是业界先驱对敏捷未来发展方向的思考？相信这些采访绝对会令你眼前一亮。
有人说作者对待自己的著作就像对待自己的孩子一样，小心翼翼，倍感珍惜。而译者又何尝不是呢？翻译工作不仅辛苦，同时也是一个良心活儿。为了保证能将本书的内容原汁原味的呈现给读者，译者本人自是不敢放松。对于本书涉及的众多敏捷方法，均参考了已有的翻译著作，结合敏捷实践的经验，力求保证翻译的一致性和正确性。同时，来自敏捷社区小伙伴的帮助也是必不可少的。首先要感谢的是姜信宝（Bob），他是资深的敏捷教练，同时也是《Scrum 精髓》一书的译者。他对本书进行了全面、细致的审校，并提出了很多专业的建议。尤其是在Scrum 方面。我非常佩服他对专业知识的严谨态度和深入的理解。另外，要感谢的是谢钊和杜伟忠。他们热情的对本书进行了初审，提出了很多宝贵的意见。尤其是谢钊，还在Trello 上为本书的翻译建立了任务板，为大家在一起协作提供了很大的便利。还有要感谢的人是滕振宇、姚若舟、张博超和柴峰，他们虽然没有直接参与本书的翻译，但我所在的团队有幸得到了他们的深入指导。借此机会加深了我对很多敏捷实践的理解，进而大大提升了本书的翻译质量。
最后，我要感谢我的家人，尤其是我的太太张燕芳。是你们的理解和支持令我最终完成了这份有富有意义的工作。
谨以此书献给那些敏捷之路上的同行者，让我们一起携手迈入敏捷软件开发的新时代！
黄喆
2015 年·夏
前言
什么是敏捷软件开发？如果一个人说“我们团队开发软件时使用了敏捷的方法”，这意味着什么？从我们的经验来看，很多人都能说出他们曾经用到或听说过的一些敏捷工具，比如Scrum 会议或者结对编程，但很少有人可以指出——敏捷其实是一种完全不同的软件开发方法。
在过去的几年间，我俩都在教授入门级的敏捷软件开发课程（Sondra在爱荷华州立大学教研究生，Kristin 在她的公司中负责员工培训）。我们都在努力寻找一本可以用于课堂教学的敏捷软件开发教材。我们在为一个当地的非营利技术组织做志愿者时遇到彼此，正是那次的交谈使我们萌生了这个想法：自己写一本敏捷方法的教材。
我们接触敏捷的过程很类似。我们都在管理软件开发团队，而团队都已经习惯于使用“瀑布”式的传统软件开发方法。我们的挑战都是在项目中应用一些敏捷软件开发的工具，并把敏捷软件开发组织转型作为终极目标。当我们一头扎进去并最终理解了敏捷软件开发的方方面面时，很快意识到敏捷远远不仅是给员工培训新的工具和方法这么简单。没过多久我们就发现，企业文化必须进行敏捷转型。而因此所遇到的挑战远远出乎我们的预料。正如我们的执行官团队所预料的那样，敏捷转型没有终点，它是一个不断前进的旅程。在这段旅程中，我们不断学习并加深理解，反复咀嚼敏捷的各种概念。
我们坚定地相信敏捷方法会给软件工程师的世界带来真实的好处。我们的目标不是为你面面俱到地介绍敏捷软件开发的一切，而是为你提供基础知识以助你起步。合气道中以“守、破、离”来描述学习技能或技术的过程。第3 章中的特邀嘉宾Alistair Cockburn 将其应用到了敏捷方法的学习过程中。最初在“守”的阶段时，你必须精确地模仿老师以打好基础。接
下来是“破”的阶段，此时你开始从其他老师那里学习以帮助形成自己的技能，进而你开始学习这门技术的历史、原理等相关知识。最后，你到达了“离”的阶段，此时你已进阶为老师，并且对这门技术做出了原创性的贡献。我们希望当你读完这本书后，就已经可以很好地朝“破”的阶段前进了。
本书开篇向你介绍了敏捷软件开发的历史。之后，我们介绍了在敏捷组织中常用的基础工具和技术。最后我们讨论了为市场启动新项目和维护已有项目时，流程是如何融合的。我们收录了对实践者的采访，以便让你感受一下在采用了敏捷方法后组织中会发生什么。每章都包含总结、建议的扩展阅读及复习题。
以下是对每章内容的简要介绍。
第1 章——敏捷软件开发的历史及价值观
本章介绍了敏捷运动的背景，并对敏捷和较传统的瀑布式方法进行了比较。我们探讨了敏捷和瀑布的使用场景，并介绍了二者各自的优缺点。本章介绍了敏捷宣言的内容、价值观及其作者。我们回顾了敏捷的12 条关键原则，并介绍了一家虚构的公司，开曼设计公司，该公司的故事将作为例子贯穿本书。我们还收录了对RobertMartin（Bob 大叔）的采访。
第2 章——敏捷型组织文化的注意事项
从瀑布到敏捷的转变需要文化转型。本章深入探讨了其中的影响、好处及陷阱。我们分别从团队成员、经理及执行官的不同视角探讨了敏捷转型，以让读者理解角色职责和决策机制将会发生哪些变化。我们对于Scott Ambler 的采访会将这些概念整合起来。
第3 章——理解不同类型的敏捷
本章描述了不同的敏捷方法：Scrum、看板、极限编程（XP）、水晶、特性驱动开发、精益软件开发及动态系统开发方法（DSDM）。我们举例描述了每种方法最适合的场景，并对每种方法的有效认证进行了概述。本章还收录了一篇对Alistair Cockburn 的采访，内容很有见地。
第4 章——敏捷方法中的不同角色
不同的敏捷方法有其特有的头衔，本章介绍了它们的角色和职责。我们首先深入介绍了Scrum，探讨了诸如产品负责人、Scrum master及Scrum 团队这些角色间的细微差别。然后我们将这些角色与第3章中提到的方法进行了比较，并且着重强调了它们的共通之处。作为对标准描述的展开，我们探讨了在组织中如何部署这些不同的角色。本章还囊括了对Roman Pichler 和Lyssa Adkins 的精彩采访。
第5 章——收集和记录需求的新方法
本章重点介绍敏捷流程的起始部分，在此我们将客户和市场反馈转化为有意义的需求。我们给出了一些概念和想法的定义，例如用户故事、史诗故事、验收标准、商业价值、优先级、路线图、燃起图等。我们还展示了如何使用诸如人性化和易用性的元素来强化需求。我们深入探究了沟通策略，还探讨了精益软件开发和精益创业运动是如何影响需求的。对Ellen Gottesdiener 和Mary Gorman 的采访给我们带来了巨大的启发。
第6 章——梳理和计划
随着开发过程的推进，需求、用户故事会被梳理成开发团队可用的输入，并对需求排列了优先级。我们会介绍一些排优先级的策略。通过使用一些技术来完成用户故事大小的估算。故事点是其中的一种方法。估算完成后，就会启动Sprint 计划会议或者XP 计划游戏。在这个过程中要考虑到团队的速度、目前的业务情况以及其他一些工作量，比如技术债和缺陷。我们探讨了项目管理三角形理论（范围vs. 时间vs. 资源），以及如何管理它们从而控制开发进度。在我们对Mike Cohn 的采访中，展示了他在实际中应用Scrum 的广泛经验。
第7 章——测试、质量和集成
本章介绍了在使用敏捷工具时如何保持甚至提升质量。敏捷中有一条关键的原则是：对可工作的软件进行频繁地验证和确认。所以我们在本章中会介绍不同的测试方法，比如测试驱动开发、验收测试驱动开发、集成测试、回归测试及单元测试。我们提供了包括参考代码在内的完整的测试驱动开发的例子。对Tim Ottinger 的采访囊括了所有测试方面的知识。
第8 章——跟踪和报告
本章强调了跟踪和报告进度在敏捷流程中的重要性。为了理解跟踪的过程，我们对必需的会议进行了解释，比如每日立会、Sprint 评审或演示会（Sprint review/demo），以及Sprint 回顾会议。我们还深入介绍了看板，因为看板项目中的跟踪和Scrum 相比有很大不同。
我们展示了如何在特性驱动开发中使用燃起图、燃尽图以及停车场（parking lots）等工具。我们讨论了在敏捷中是如何度量成功的。其中包含对客户满意度的度量—这甚至更加重要。我们还收录了一篇对敏捷教练Kent McDonald 的采访。
第9 章——延伸到IT 之外的敏捷
本章阐述了敏捷对IT 之外的部门的广泛影响。不管是全新的项目还是增强特性型的项目，它们的整个发起过程都和以前不同了。应用了敏捷的四条价值观后，项目增强了对市场交付的能力。我们还展示了敏捷原则是如何应用到IT 之外的组织中的。有些人已经在市场部门中全面落实了敏捷，他们甚至还创立了敏捷营销宣言。在本章的最后，我们采访了Travis Arnold，他是敏捷营销宣言的起草者之一。
附录——John Deere 案例研究
附录中是我们对John Deere 智能方案小组的三位领导成员的采访。在他们的领导下，其组织（公司）踏上了敏捷之旅。
我们真诚祝愿你可以享受到探索敏捷软件开发世界所带来的乐趣。我们欢迎你的反馈，欢迎访问我们的网站或者Twitter 来获取更多关于敏捷的信息。
Sondra Ashmore
PMI-PMP/ACP
@Sondra1130
Kristin Runyan
PMI-PMP, CSPO, CSM
http://www.runyanconsulting.com
@KristinRunyan
从2001 年2 月17 位签署人在盐湖城雪鸟滑雪场共同推出“敏捷宣言”，从而标志着敏捷方法的诞生开始到15 年后，敏捷方法已经变成了软件开发的主流开发方式。甚至已经不限于软件开发，有数据表明，敏捷方法已经开始从最早的类似于人事系统(注：克莱斯勒的C3 项目是极限编程的源头)，工资系统，互联网软件到传统的核武器系统，编译器，操作系统，实时工业控制，医疗设备系统等。在中国，我们也见到或者帮助大型医疗设备研发团队，石油天然气行业设备研发团队，军工科研向敏捷开发方式转型。
15 年来，随着敏捷方法越来越流行，敏捷方法家族也有了长足的发展，也从最初的Scrum, 极限编程，水晶，DSDM，有发展出了看板、精益以及众多敏捷小工具等等。随着越来越多的组织开始接触敏捷。这些组织不可避免遇到了林林总总的挑战，比如，
? 如何让这些组织了解敏捷方法的关系与区别，从而更好的选择敏捷药方？
? 敏捷方法的背后蕴含的企业文化如何？
? 如何支持传统组织以及传统组织里的各种角色向敏捷工作方式转变？
? 除了教科书上的敏捷，还有那些有用的工具、技巧和方法？
? 敏捷组织里面的各种角色以及他们的职责有哪些？
? 不同敏捷方法中最通用的部分有哪些？
? 在公司发展的不同阶段需要多敏捷？
针对这面这些棘手的问题，您都可以从这本书里面找到一些答案或者启发。
如果您想迅速的了解敏捷方法的概况，并能够快速上手，这本书是一个不可多得的选择。
唤醒者 滕振宇
2015 年·夏
推荐序二
为什么要看这本书
市面上有关敏捷软件开发（下文简称敏捷）的书已经很多了，为什么选择要看这本书呢？这本书非常全面地介绍了敏捷下的各种方法，包括Scrum、看板、极限编程、水晶开发方法、特性驱动开发、精益软件开发以及动态系统开发方法。并且还深入地介绍了每种方法所涉及的团队角色。书中每章最后都会对一名敏捷大牛进行采访，比如Robert C Martin，Alistair
Cockburn，Mike Cohn 等。本书另外一个重要的特色是，在最后一章，专门介绍了IT 之外的敏捷是什么样子的。
敏捷有这么多方法，那么在开始采用某个方法之前，我认为有必要搞清楚为什么要进行敏捷？
为什么要进行敏捷软件开发
敏捷起源于2001 年，有17 位轻量型软件开发的大牛，一起聚集在雪鸟滑雪胜地，最后形成了敏捷宣言和敏捷原则。在随后的十多年里，全球范围内越来越多的企业或组织在进行敏捷的尝试，也有很多成功与失败的案例。那么为什么越来越多的企业或组织要进行敏捷转型呢？
首先，让我们一起来看一下软件开发的本质。软件开发，从根本上来看，是把客户（或用户）的脑袋中的想法，转换成可以工作的软件。这一过程就决定了软件开发的本质是学习与反馈的过程。也就是说，软件开发的第一步是要学习，不断地学习。为了能够真正理解客户（或用户）脑子当中的想法，我们需要不断（在软件开发过程中）去和客户（或用户）沟
通，了解他的行为，学习他的思维模式。从而真正理解客户的需求，而不是只在软件开发前期和后期与客户（或用户）沟通。除了不断学习，软件开发的第二步是反馈。在软件开发过程中，反馈是必需的。在与客户（或用户）不断学习的过程中，我们需要带着可工作的软件去和客户（或用户）学习沟通。只有这样，我们才能得到他们真正的反馈。基于客户（或用户）的反馈，我们再进行调整从而响应变化。因此软件开发的本质就是不断学习和持续反馈。
“新产品开发的规则在发生改变。许多公司已经发现，高质量、低成本和差异化已经很难超越当今市场白热化的竞争。超越市场需要的是速度与灵活性。”为了赢得市场，我们需要足够快的速度和灵活性，也就是说我们需要不断学习客户（或用户）的想法（需求），并且持续获得客户（或用户）的反馈。而敏捷可以完美得符合软件开发的本质。为什么这么说呢？让我们一起看看什么是敏捷。
什么是敏捷
敏捷就是尽早频繁的交付商业价值。具体展开来讲，敏捷是一种带有固定时间盒的迭代增量式软件开发方法。迭代（iterative），指的是需要重构已做的工作（即要改设计）。而增量（Incremental），指的是在现有软件的基础上逐渐增加新功能（不改原来的设计）。固定时间盒，可以使团队在短时间内就获得一些产出，从而可以持续获得客户（或用户）的反馈。因此，敏捷天生就是为软件开发而生的，它和软件开发的本质有机地结合在一起。
最后想要强调的一点是，敏捷不是一种状态，不是说我们到达了某个状态或者地方就代表我们敏捷了。敏捷更像是在路上，我们一直朝着敏捷的方向前进，不断学习与持续反馈。
中国敏捷社区的主要推动者 姜信宝
2015 年·夏
译者序
有人说：没有经历过“焦油坑”项目的软件工程师的人生是不完整的。这当然只是一种调侃，但如果从这个角度来看，我的软件工程师生涯绝对是圆满的。从事软件工作多年来，加班和项目延期一直是那挥之不去的痛。需求的不断变化，每次集成验证都有“惊喜”，大量的缺陷直到项目后期才暴露出来……每次和同事们“战斗”至深夜才离开公司，我都会不停地问自己，解决这些问题的出路在哪里？
寻寻觅觅的探索中，一次偶然的机会我参加了滕振宇的CSM 课程，当我开始了解了敏捷，那一刻犹如闪电划破夜空，真是有一种“一见钟情，相见恨晚”的感觉。多年来的亲身经验告诉我，敏捷这条道路是对的！它让我对未来的软件开发之路又重新燃起了希望和斗志。也正是带着这份希冀，我和我的团队踏上了属于我们的敏捷之旅，而我们这一启程便没有再
停下来。两年来我们的敏捷实践从单个团队、小项目中的试点，扩大到整个部门、大项目中的推广，有力地证明了敏捷方法的有效性。敏捷让我们可以更好的理解需求，响应需求的变化，项目的可控性得到了很大的提升，同时也让身处其中的每位同事都工作的更加开心了。
在享受了敏捷给我们团队带来的收获时，另一份新的希冀也在我的心中渐渐涌动起来：那就是可以让更多的软件从业人员系统的了解敏捷，进而摆脱“焦油坑”项目的魔咒。而《洞悉敏捷》正是这样一本书。
它全面地介绍了目前主流的敏捷方法，包括：Scrum、看板、极限编程（XP）、水晶、特性驱动开发（FDD）、精益软件开发以及DSDM 等。这非常有助于初学者系统的了解敏捷，为后续的实践打好牢固的知识基础。同时，它还提供了目前市面上敏捷相关书籍所不具备的独特视角，那就是在角色、需求、计划、跟踪等维度上横向的对这些主流的敏捷方法进行了客观的比较。这种横向的比较有利于让读者对每种具体的方法产生更加深入的理解，甚至还可能进而激发出一些适合于具体项目的新颖实践。从这方面来讲，即使是有一定经验的敏捷实践者也会从本书中受益良多。本书的还有一个亮点就是囊括了十篇对敏捷先驱者的深度采访，其中不乏像Bob大叔或是Mike Cohn 这样的业界大牛。你想了解敏捷宣言起草的幕后故事？或是业界先驱对敏捷未来发展方向的思考？相信这些采访绝对会令你眼前一亮。
有人说作者对待自己的著作就像对待自己的孩子一样，小心翼翼，倍感珍惜。而译者又何尝不是呢？翻译工作不仅辛苦，同时也是一个良心活儿。为了保证能将本书的内容原汁原味的呈现给读者，译者本人自是不敢放松。对于本书涉及的众多敏捷方法，均参考了已有的翻译著作，结合敏捷实践的经验，力求保证翻译的一致性和正确性。同时，来自敏捷社区小伙伴的帮助也是必不可少的。首先要感谢的是姜信宝（Bob），他是资深的敏捷教练，同时也是《Scrum 精髓》一书的译者。他对本书进行了全面、细致的审校，并提出了很多专业的建议。尤其是在Scrum 方面。我非常佩服他对专业知识的严谨态度和深入的理解。另外，要感谢的是谢钊和杜伟忠。他们热情的对本书进行了初审，提出了很多宝贵的意见。尤其是谢钊，还在Trello 上为本书的翻译建立了任务板，为大家在一起协作提供了很大的便利。还有要感谢的人是滕振宇、姚若舟、张博超和柴峰，他们虽然没有直接参与本书的翻译，但我所在的团队有幸得到了他们的深入指导。借此机会加深了我对很多敏捷实践的理解，进而大大提升了本书的翻译质量。
最后，我要感谢我的家人，尤其是我的太太张燕芳。是你们的理解和支持令我最终完成了这份有富有意义的工作。
谨以此书献给那些敏捷之路上的同行者，让我们一起携手迈入敏捷软件开发的新时代！
黄喆
2015 年·夏
前言
什么是敏捷软件开发？如果一个人说“我们团队开发软件时使用了敏捷的方法”，这意味着什么？从我们的经验来看，很多人都能说出他们曾经用到或听说过的一些敏捷工具，比如Scrum 会议或者结对编程，但很少有人可以指出——敏捷其实是一种完全不同的软件开发方法。
在过去的几年间，我俩都在教授入门级的敏捷软件开发课程（Sondra在爱荷华州立大学教研究生，Kristin 在她的公司中负责员工培训）。我们都在努力寻找一本可以用于课堂教学的敏捷软件开发教材。我们在为一个当地的非营利技术组织做志愿者时遇到彼此，正是那次的交谈使我们萌生了这个想法：自己写一本敏捷方法的教材。
我们接触敏捷的过程很类似。我们都在管理软件开发团队，而团队都已经习惯于使用“瀑布”式的传统软件开发方法。我们的挑战都是在项目中应用一些敏捷软件开发的工具，并把敏捷软件开发组织转型作为终极目标。当我们一头扎进去并最终理解了敏捷软件开发的方方面面时，很快意识到敏捷远远不仅是给员工培训新的工具和方法这么简单。没过多久我们就发现，企业文化必须进行敏捷转型。而因此所遇到的挑战远远出乎我们的预料。正如我们的执行官团队所预料的那样，敏捷转型没有终点，它是一个不断前进的旅程。在这段旅程中，我们不断学习并加深理解，反复咀嚼敏捷的各种概念。
我们坚定地相信敏捷方法会给软件工程师的世界带来真实的好处。我们的目标不是为你面面俱到地介绍敏捷软件开发的一切，而是为你提供基础知识以助你起步。合气道中以“守、破、离”来描述学习技能或技术的过程。第3 章中的特邀嘉宾Alistair Cockburn 将其应用到了敏捷方法的学习过程中。最初在“守”的阶段时，你必须精确地模仿老师以打好基础。接
下来是“破”的阶段，此时你开始从其他老师那里学习以帮助形成自己的技能，进而你开始学习这门技术的历史、原理等相关知识。最后，你到达了“离”的阶段，此时你已进阶为老师，并且对这门技术做出了原创性的贡献。我们希望当你读完这本书后，就已经可以很好地朝“破”的阶段前进了。
本书开篇向你介绍了敏捷软件开发的历史。之后，我们介绍了在敏捷组织中常用的基础工具和技术。最后我们讨论了为市场启动新项目和维护已有项目时，流程是如何融合的。我们收录了对实践者的采访，以便让你感受一下在采用了敏捷方法后组织中会发生什么。每章都包含总结、建议的扩展阅读及复习题。
以下是对每章内容的简要介绍。
第1 章——敏捷软件开发的历史及价值观
本章介绍了敏捷运动的背景，并对敏捷和较传统的瀑布式方法进行了比较。我们探讨了敏捷和瀑布的使用场景，并介绍了二者各自的优缺点。本章介绍了敏捷宣言的内容、价值观及其作者。我们回顾了敏捷的12 条关键原则，并介绍了一家虚构的公司，开曼设计公司，该公司的故事将作为例子贯穿本书。我们还收录了对RobertMartin（Bob 大叔）的采访。
第2 章——敏捷型组织文化的注意事项
从瀑布到敏捷的转变需要文化转型。本章深入探讨了其中的影响、好处及陷阱。我们分别从团队成员、经理及执行官的不同视角探讨了敏捷转型，以让读者理解角色职责和决策机制将会发生哪些变化。我们对于Scott Ambler 的采访会将这些概念整合起来。
第3 章——理解不同类型的敏捷
本章描述了不同的敏捷方法：Scrum、看板、极限编程（XP）、水晶、特性驱动开发、精益软件开发及动态系统开发方法（DSDM）。我们举例描述了每种方法最适合的场景，并对每种方法的有效认证进行了概述。本章还收录了一篇对Alistair Cockburn 的采访，内容很有见地。
第4 章——敏捷方法中的不同角色
不同的敏捷方法有其特有的头衔，本章介绍了它们的角色和职责。我们首先深入介绍了Scrum，探讨了诸如产品负责人、Scrum master及Scrum 团队这些角色间的细微差别。然后我们将这些角色与第3章中提到的方法进行了比较，并且着重强调了它们的共通之处。作为对标准描述的展开，我们探讨了在组织中如何部署这些不同的角色。本章还囊括了对Roman Pichler 和Lyssa Adkins 的精彩采访。
第5 章——收集和记录需求的新方法
本章重点介绍敏捷流程的起始部分，在此我们将客户和市场反馈转化为有意义的需求。我们给出了一些概念和想法的定义，例如用户故事、史诗故事、验收标准、商业价值、优先级、路线图、燃起图等。我们还展示了如何使用诸如人性化和易用性的元素来强化需求。我们深入探究了沟通策略，还探讨了精益软件开发和精益创业运动是如何影响需求的。对Ellen Gottesdiener 和Mary Gorman 的采访给我们带来了巨大的启发。
第6 章——梳理和计划
随着开发过程的推进，需求、用户故事会被梳理成开发团队可用的输入，并对需求排列了优先级。我们会介绍一些排优先级的策略。通过使用一些技术来完成用户故事大小的估算。故事点是其中的一种方法。估算完成后，就会启动Sprint 计划会议或者XP 计划游戏。在这个过程中要考虑到团队的速度、目前的业务情况以及其他一些工作量，比如技术债和缺陷。我们探讨了项目管理三角形理论（范围vs. 时间vs. 资源），以及如何管理它们从而控制开发进度。在我们对Mike Cohn 的采访中，展示了他在实际中应用Scrum 的广泛经验。
第7 章——测试、质量和集成
本章介绍了在使用敏捷工具时如何保持甚至提升质量。敏捷中有一条关键的原则是：对可工作的软件进行频繁地验证和确认。所以我们在本章中会介绍不同的测试方法，比如测试驱动开发、验收测试驱动开发、集成测试、回归测试及单元测试。我们提供了包括参考代码在内的完整的测试驱动开发的例子。对Tim Ottinger 的采访囊括了所有测试方面的知识。
第8 章——跟踪和报告
本章强调了跟踪和报告进度在敏捷流程中的重要性。为了理解跟踪的过程，我们对必需的会议进行了解释，比如每日立会、Sprint 评审或演示会（Sprint review/demo），以及Sprint 回顾会议。我们还深入介绍了看板，因为看板项目中的跟踪和Scrum 相比有很大不同。
我们展示了如何在特性驱动开发中使用燃起图、燃尽图以及停车场（parking lots）等工具。我们讨论了在敏捷中是如何度量成功的。其中包含对客户满意度的度量—这甚至更加重要。我们还收录了一篇对敏捷教练Kent McDonald 的采访。
第9 章——延伸到IT 之外的敏捷
本章阐述了敏捷对IT 之外的部门的广泛影响。不管是全新的项目还是增强特性型的项目，它们的整个发起过程都和以前不同了。应用了敏捷的四条价值观后，项目增强了对市场交付的能力。我们还展示了敏捷原则是如何应用到IT 之外的组织中的。有些人已经在市场部门中全面落实了敏捷，他们甚至还创立了敏捷营销宣言。在本章的最后，我们采访了Travis Arnold，他是敏捷营销宣言的起草者之一。
附录——John Deere 案例研究
附录中是我们对John Deere 智能方案小组的三位领导成员的采访。在他们的领导下，其组织（公司）踏上了敏捷之旅。
我们真诚祝愿你可以享受到探索敏捷软件开发世界所带来的乐趣。我们欢迎你的反馈，欢迎访问我们的网站或者Twitter 来获取更多关于敏捷的信息。
Sondra Ashmore
PMI-PMP/ACP
@Sondra1130
Kristin Runyan
PMI-PMP, CSPO, CSM
http://www.runyanconsulting.com
@KristinRunyan
相关图书
看漫画学Python：有趣、有料、好玩、好用（全彩修订版）
ython是一门既简单又强大的编程语言，被广泛应用于数据分析、大数据、网络爬虫、自动化运维、科学计算和人工智能等领域。Python也越来越重要，成为国家计算机等...
看漫画学Python 2：有趣、有料、好玩、好用（全彩进阶版）
本书是《看漫画学Python》的进阶版本，继续秉承有趣、有料、好玩、好用的理念，并继续采用《看漫画学Python》一书中3个不同的漫画人物角色，通过这3个角色之...
趣玩Python：自动化办公真简单（双色+视频版）
本书以数据收集→数据清洗→数据分析→数据可视化→根据数据可视化结果（即图表）做决策为脉络，介绍Python在实际工作场景中的应用，侧重于用Python解决工作中...
分布式系统与一致性
一致性是非常重要的分布式技术。众所周知，分布式系统有很多特性，如可用性、可靠性等，这些特性多多少少会与一致性产生关系，受到一致性的影响。要全面研究、掌握分布式技...
￥79.00
人人都是产品经理（案例版）：淘宝十年产品事
做产品经理需要不断成长。然而回顾漫长的产品发展史，我们总会发现：有太多犯过的错误在反复出现，每一次都会有人掉入同样的“坑”。大量看似充满新意的点子、“前无古人”...
￥69.00