学习敏捷：构建高效团队(txt+pdf+epub+mobi电子书下载)

作者：安德鲁·斯特尔曼 （Andrew Stellman）

出版社：人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

学习敏捷：构建高效团队试读：

O'Reilly Media, Inc. 介绍

O'Reilly Media 通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自 1978 年开始，O'Reilly 一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来，而我们关注真正重要的技术趋势——通过放大那些“细微的信号”来刺激社会对新科技的应用。作为技术社区中活跃的参与者，O'Reilly 的发展充满了对创新的倡导、创造和发扬光大。

O'Reilly 为软件开发人员带来革命性的“动物书”；创建第一个商业网站（GNN）；组织了影响深远的开放源代码峰会，以至于开源软件运动以此命名；创立了 Make 杂志，从而成为 DIY 革命的主要先锋；公司一如既往地通过多种形式缔结信息与人的纽带。 O'Reilly 的会议和峰会集聚了众多超级极客和高瞻远瞩的商业领袖，共同描绘出开创新产业的革命性思想。作为技术人士获取信息的选择，O'Reilly 现在还将先锋专家的知识传递给普通的计算机用户。无论是通过图书出版、在线服务或者面授课程，每一项 O'Reilly 的产品都反映了公司不可动摇的理念——信息是激发创新的力量。

业界评论

谨以此书献给 Nisha 和 Lisa，感谢她们一直以来对我们的耐心。

本书赞誉

又一本来自 Andrew 和 Jennifer 团队的佳作。他们的文字风格引人入胜，他们对敏捷知识的了解深刻透彻。他们的书不仅内容全面，而且很有实践意义。——Grady BoochIBM 院士

对于高效敏捷团队的构建，最大的障碍不在于学习敏捷方式，而在于理解敏捷。要释放团队潜力，让成员全力以赴，并且在合作中寻求创新，关键在于帮助他们了解团队为什么要敏捷。Andrew 和 Jennifer 关注价值观和原则，以极佳的方式帮助你和你的团队发掘敏捷背后的缘由。我等不及要和大家分享这本书了。——Todd Webb国际电子商务公司的技术产品主管

我很热衷于敏捷，而《学习敏捷》教会了我如何在自己的组织中推广敏捷。这本书以引人入胜的方式让你深入了解敏捷原则和实践。这里的故事很有代入感，你很容易借此说服团队成员转向敏捷，然后享受成果。——Mark DenovichCentriq Group公司高级业务顾问兼美国开发部主管

这是一本非常棒的指导书，适合任何想要深刻理解敏捷的团队成员。Stellman 和 Greene 以清楚明了而又引人入胜的笔触讲解了敏捷价值观和原则。这本书中的幽默、例子以及精道的比喻让人耳目一新。不过这本书最大的优点还是明确指出了敏捷团队时常遇到的问题，并且提供了取得进展、获得更多成果的实用建议。——Matthew DundasKatori 公司 CTO

作为一名工程师，我一直认为敏捷实践解决的是行业中的大问题。其实做到敏捷很难，这不仅仅是实践的问题。正如作者所说，零碎的敏捷方法只能带来“聊胜于无”的结果。如果你刚刚开始实践敏捷，或者只做到了“聊胜于无”，那么你可以从这本书中得到很多实用建议，Andrew 和 Jennifer 会告诉你如何深入理解“敏捷宣言”，真正做到敏捷。——James W GrenningWingman 软件公司创始人敏捷宣言起草人之一

Andrew Stellman 和 Jennifer Greene 的这本书写得非常棒。书中全面整合了很多实战资源，想要学习敏捷的人都可以轻松获取。他们在书中谈到了敏捷的诸多方面，而不只是讲解了敏捷团队的理想状态。通过挖掘敏捷的不同要素，他们呈现了敏捷的标准实践和最佳效果，也指出了人们对敏捷的常见误解及对应的结果。此外还讲解了具体的实践和做法会对不同职责的个体造成怎样的影响。对于初学者和有经验的敏捷实践者而言，这本书都是很好的学习资源。——Dave Prior敏捷顾问兼教练

要想学习敏捷的具体方法，你需要阅读相关的书籍。这就意味着你要事先想好自己需要什么。你真有这么敏捷吗？ Andrew 和 Jenny 提供了一套关于敏捷的纲要，实用易懂，可以让你正确理解敏捷的概念。你不用提前确定自己需要什么样的敏捷方法，看看这本书就可以做决定了。你可以通过这本书了解敏捷的体系，以及它是如何运作的。——Johanna Rothman作家兼顾问

在软件开发团队中，相比专业知识和工具，文化氛围对于项目的成功更为重要。关于如何将不同人的割裂视角凝聚成全体成员的统一视角，让团队共享价值观和实践，Stellman 和 Greene 的建议能够为任何组织的项目经理提供帮助。他们比较了 Scrum、极限编程、精益和看板方法，分析了敏捷原则的多种实践方式。书中生动的例子解释了人们在走向敏捷的过程中所遇到的困境以及收获的成果。——Patricia EnsworthHarborlight 管理服务有限责任公司董事长《学习敏捷》这本书很全面、很易懂、很实用、很有趣。书中讲解的价值观、原则和方法非常有启发，我等不及要在团队中实践了。——Sam Kass软件架构师及财务部门的技术负责人

这是一本非常好的书，可以为任何层次的软件专业人士介绍敏捷方法。它可以帮助你了解进而避免开发团队遇到的常见陷阱。——Adam Reeve大型社交网站的工程师和团队主管序

人们似乎总是需要辩论点什么。Van Halen 跟 David Lee Roth 在一起更好，还是跟 Sammy Hagar 在一起更好？百事可乐更好喝，还是可口可乐更好喝？ Lennon 唱得好，还是 McCartney 唱得好？养猫还是养狗？早期，敏捷方法也有原则与实践之争。早期的敏捷倡导者就一组原则达成了共识，并将其庄严载入敏捷宣言（Agile Manifesto），而多个敏捷方法之间也共享了很多具体实践。然而，当时人们就一个问题展开了激烈的争论，即一个团队是应该先理解敏捷软件开发的原则，还是应该先开始具体实践。

支持从实践开始的人认为熟能生巧。按照敏捷的方式行事，团队就会变得敏捷。通过采用敏捷方法的实践，如结对编程、测试和构建自动化、使用迭代、与主要的利益干系人紧密合作等，团队就会逐渐理解敏捷原则。

而支持从原则开始的人则认为没有原则支撑的实践是空洞的。在不明就里的情况下采用敏捷实践不会带来敏捷。敏捷一直关注持续改进。这些人认为，如果不理解自己所做的事情，团队就没法做到持续改进。

在《学习敏捷》这本书中，Andrew Stellman 和 Jennifer Greene 让原则和实践并重。在这一点上，他们是我所见过的人中做得最好的。他们指出，在不了解敏捷的情况下，实践只能带来所谓“聊胜于无”的成功。也就是说，只采用敏捷的实践是有帮助的，但是与真正的敏捷所带来的成功相比，还差得很远。

我第一次与 Andrew 和 Jennifer 见面是在六年前。当时他们为自己的新书《团队之美》（Beautiful Teams）来采访我。尽管那本书的书名中并没有“agile”（敏捷）这样的字眼，但是从很多方面看，那就是一本关于敏捷的书。拥抱敏捷原则、掌握所需敏捷实践并且摒弃不必要敏捷实践的团队确实是出色的团队。在《学习敏捷》这本书中，Andrew 和 Jennifer 集中讨论了当今三种最常见的敏捷方法：Scrum、极限编程和看板方法，并将讨论聚焦于敏捷这一主题。读者将看到基于共有原则的这三种方法如何形成不同的实践。比如，如果想知道为什么 Scrum 需要在冲刺结束时进行回顾而极限编程却不需要，在这里就能找到答案。

通过与 Andrew 和 Jennifer 一起探索 Scrum、极限编程、精益和看板方法，读者将读到很多故事。这样安排是有道理的。毕竟，很多敏捷团队的一个共同实践就是通过用户故事来描述某个系统的用户想要什么。读者将看到这样一些团队，他们费尽周折想要开发出正确的软件功能，为交付去年的需求花费了太长时间，错把敏捷当成另一种形式的上令下行式管理方法，不去拥抱变化而是被变化折磨得死去活来，等等。更重要的是，本书将向读者介绍团队克服这些问题的方法，让读者学以致用。《学习敏捷》这本书彻底结束了“原则和实践哪一个应该在先”的争论。书中引人入胜的故事和鞭辟入里的评论说明了一个简单的真理：在敏捷中原则与实践是不可分割的。通过阅读本书，读者将对如何成为真正出色的团队（或回到成为真正出色团队的正轨上来）有更为深入的理解。Mike Cohn《Scrum 敏捷软件开发》《用户故事与敏捷方法》作者博尔德美国科罗拉多州前言致谢

我们写作本书的目的是帮助读者学习敏捷。本书的完成离不开大家的帮助和支持。首先，我们要感谢优秀的编辑 Mary Treseler。从我们初次在曼哈顿市中心的一家印度餐厅跟她讨论本书的那天开始，一直到今天我们看到这本书，在这过程中，她付出了极大的努力。她在我们与 O'Reilly 出版社的合作中起到了十分重要的作用。没有她的支持，我们就不会有今天的成绩。

我们也要感谢 O'Reilly 出版社的其他工作人员，没有他们就不可能有这本书。他们是 Mike Hendrickson、Laurie Petrycki、Tim O'Reilly、Ally MacDonald、Andy Oram 和 Nicole Shelby，我们尤其要感谢 Marsee Henon、Sara Peyton，以及在塞巴斯托波的所有杰出的媒体人员和公关人员。

我们感谢 Mike Cohn 为本书撰写的精彩序言，同时感谢他多年来给予我们的极好建议。我们还想感谢他撰写了那么多优秀的图书，我们从中真的学到了很多东西！我们还要感谢 David Anderson，针对本书的第 8 章和第 9 章给出了非常好的反馈意见。我们要感谢 Grady Booch、Scott Ambler、James Grenning、Scott Berkun、Steve McConnell、Karl Wiegers、Johanna Rothman、Patrica Ensworth、Tommy Tarka、Keoki Andrus、Neil Siegel、Karl Fogel 和 Auke Jilderda。他们多年来为我们提供了极好的素材，尤其是为《团队之美》一书。而且我们要特别感谢 Barry Boehm，他不仅为《团队之美》贡献了一个非常精彩的故事，更重要的是奠定了敏捷的智力基础。我们还要感谢 Kent Beck、Alistair Cockburn、Ken Schwaber、Jeff Sutherland、Ron Jeffries、Tom Poppendieck、Mary Poppendieck、Lyssa Adkins 和 Jim Highsmith。他们在敏捷领域做出了突破性的工作。可以说，没有他们，我们不可能写出此书。

我们还要感谢所有的技术审阅人：Faisal Jawdat、Adam Reeve、Anjanette Randolph、Samuel Weiler、Dave Prior、Randy DeFauw、Todd Webb、Mickael DeWitt 和 Paul Ellarby。他们的反馈十分到位，审校非常细致。

最后，我们要感谢数百位软件团队成员，感谢他们不吝与我们分享多年来的问题、解决方案、故事以及经历。

Andrew 要感谢 Lisa Kellner。他同时也要感谢卡内基梅隆大学计算机科学系所有启迪过他的人，尤其是 Bob Harper、Mark Stehlik 和 Randy Bryant。他要感谢多年的良师益友 Tony Visconti。他要感谢他的朋友 Sara Landeau、Greg Gassman、Juline Koken、Kristeen Young 和 Casey Dunmore。关于团队合作，他从这些优秀的音乐家身上学到了很多。回头想想，这是多么不可思议。他还要感谢职业生涯中共事过的优秀同事，包括 Dan Faltyn、Ned Robinson、Debra Herschmann、Mary Gensheimer、Lana Sze、Warren Pearson、Bill DiPierre、Jonathan Weinberg 和 Irene O'Brien。最后还要感谢曾工作过的两个最佳软件团队的同事，他们是 Optiron 的 Mark Denovich、Eric Renkey 和 Chris Winters，以及美国银行的 Mike Hickin、Nick Lai、Sunanda Bera 和 Rituraj Deb Nath。

Jennifer 要感谢 Nisha Sondhe。她还要感谢 Christopher Wenger、Brian Romeo、LaToya Jordan、Mazz Swift、Rekha Malhotra、Courtney Nelson、Anjanette Randolph、Shona McCarthy、Ethan Hill、Yeidy Rodriguez、Kyle Mosier、Achinta McDaniel、Jaikaran Sawhny 和 Kit Cole，感谢他们的支持和陪伴。她要感谢家人在她写作本书的将近三年中给予她的耐心和鼓励。她要感谢 Tanya Desai 和 Dilan Desai 夫妇的支持和帮助。最后，她要感谢许多优秀的同事。多年来，她从他们身上学到了很多东西。还需要感谢的人太多，无法一一列举，这里只列出一小部分，他们是 Joe Madia、Paul Oakes、Jonathan Weinberg、Bianka Buschbeck、Thor List、Oleg Fishel、Brian Duperrouzel、Dave Murdock、Flora Chen、Danny Wunder、David San Filippo 和 Rasko Ristic。®Safari Books Online

Safari Books Online（http://my.safaribooksonline.com/?portal=oreilly）是应运而生的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品（http://www.safaribooksonline.com/content）。

技术专家、软件开发人员、Web 设计师、商务人士和创意专家等，在开展调研、解决问题、学习和认证培训时，都将 Safari Books Online 视作获取资料的首选渠道。

Safari Books Online 为组织（http://www.safaribooksonline.com/organizations-teams）、政府机构（http://www.safaribooksonline.com/government）和个人读者（http://www.safaribooksonline.com/individuals）提供了一系列的产品组合（http://www.safaribooksonline.com/subscriptions）和价格体系。订阅者可在一个支持完全搜索的数据库中访问数以千计的图书、培训视频和尚未发行的书稿。发行这些内容的是 O'Reilly Media、Prentice Hall Professional、Addison- Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以及其他数十家发行商（http://www.safaribooksonline.com/publishers）。要想了解 Safari Books Online 的更多信息，请访问我们的网站（http://www.safaribooksonline.com/）。  第1章 学习敏捷对继续学习的渴望是一个人可以形成的最重要的态度。——约翰 · 杜威《经验与教育》

这是一个令人激动的敏捷时代。对于一直困扰软件开发团队的种种问题，IT 行业首次找到了真正可持续的解决方案。以下是敏捷承诺的几种解决方案。敏捷项目可以按时完成，为那些苦恼于交付期限和预算的团

队带去了福音。敏捷项目交付高质量的软件，那些受困于 bug 和低效软件

的团队会迎来巨大的变革。敏捷团队构建的代码结构优良且易于维护，那些常常维护复

杂又混乱的代码的团队会得到解脱。敏捷团队会让用户满意，不再交付无法为用户带来价值的软

件。最重要的是，在出色的敏捷团队中，开发人员不用加班，可

以与亲朋好友共度晚间时光和周末。这在他们的职业生涯中可能

是史无前例的。敏捷之所以流行，是因为很多走敏捷路线的团队都表示收获

颇丰。它们构建出了更好的软件，团队成员间合作更为愉快，用

户的需求也得到了更好的满足，工作环境也更加轻松愉悦。一些

团队在接纳敏捷理念之后终于可以在困扰多年的问题上有所进

展。那么，伟大的团队如何利用敏捷理念构建更好的软件？更准

确地说，我们自己怎样才能利用敏捷理念取得如此好的结果呢？在本书中，读者会学到两种最流行的敏捷方法：Scrum 和极

限编程（eXtreme Programming，XP）。此外，读者还会学习到

精益（Lean）方法和看板（Kanban）方法，了解如何通过它们

理解当前采用的软件构建方法，并改进当前的状况。通过本书，

读者还将明白一点：尽管这四种敏捷学派关注的是软件开发中的

不同领域，但它们有一个重要的共同特点：重视改变团队的思维

模式。正是因为转变了思维模式，一个仅仅接触敏捷实践皮毛的团

队就可以获得提升，从而真正改进其软件构建方式。本书的目标

是帮助读者深入了解敏捷的两个方面：一方面是日常工作中的种

种实践，另一方面是敏捷的价值观和原则。后者能够帮助团队从

根本上改变构建软件的思维模式。1.1　什么是敏捷

敏捷是指能够让团队思考更加有效、工作更为高效，并且作出更好决策的一组方法和相关理念。

这些方法和理念适用于传统软件工程的所有领域，例如项目管理、软件设计、软件架构和流程改进。每种方法和理念都包括实践。这些实践经过了精简和优化，应用起来非常方便。

敏捷也是一种思维模式，思维模式的正确与否会影响团队具体实践的高效程度。正确的思维模式有助于团队成员共享信息，从而共同作出重要的项目决策，而不是让经理独自负责所有的决策。敏捷思维模式涉及整个团队的开工计划、设计和流程改进。在敏捷团队所采用的实践方式中，大家不仅共享信息，而且对实践的应用方式都有发言权。

敏捷在有些团队中还没有取得成功，这造成了现实和承诺之间的差距。这种差距形成的关键往往在于项目团队的思维模式。很多构建软件的公司都尝试过敏捷开发。许多团队尝到了成功的甜头，而一些团队却结果平平。尽管这些团队在项目运作上有所改善，这些改善也足以证明采用敏捷的努力是值得的，但是他们并没有看到敏捷方法承诺的那些实质性改变。这就是改变思维模式的意义所在。走敏捷路线意味着帮助团队找到一种高效的思维模式。

那么，改变思维模式到底意味着什么？如果你是软件团队中的一员，那么你每天的工作就是规划、设计、构建和发布软件。思维模式与这些有什么关系呢？事实证明，你在日常工作中采取的实践很大程度上取决于你和其他团队成员对待实践的态度。

举个例子：每日站立会议（daily standup）是很多团队都采用的一种最常见的敏捷实践。在每日站立会议上，每一位成员都会讲述自己手头的工作以及面临的挑战。为了使会议简短，大家在会议期间全程站立。很多团队在项目中引入每日站立会议，因而获得了很大成功。

假设有一位刚开始学习敏捷的项目经理，他想在项目中引入每日站立会议。令他意外的是，并不是所有人都像他那样对这一新实践欣喜若狂。组里的一位开发人员非常气愤，项目经理竟然要增加一种新的会议，而且他似乎也感觉很不舒服，因为每天都要在会上被问及自己的工作情况。

那么这里到底出了什么问题？是开发人员不讲道理，还是项目经理要求太多？为什么这样一项被广泛接受的简单实践会引发一场冲突？

项目经理和开发人员双方各执一词，言之凿凿。项目经理面临的最大挑战之一是项目规划，这需要投入大量的精力。如果在构建软件时遇到问题，那么团队就有可能偏离当初的计划。项目经理必须努力了解每个人的工作情况，这样才能调整计划，帮助大家解决问题。图 1-1：一个项目经理想要在团队中开展每日站立会议，却惊讶地发现，并不是所有人都立即表示赞同

而从开发人员的角度看，每天的各种会议会频频打断手头的工作，导致任务很难完成。他知道如何构建自己的代码，不需要另一个人在他耳边唠叨什么计划和变化。他只想一个人静静地写代码，他最不愿意做的事就是再多开一个会议。图 1-2：两个人似乎都有充足的理由解释自己为何如此看待每日站立会议。这将对项目产生什么影响呢

设想一下，假设这位项目经理能说服所有人（包括上面那位有抵触情绪的开发人员）参加每日站立会议，那么这个会议会是什么样子？项目经理主要关注实际执行情况与最初计划的差距，因此他会关心每个人的工作情况。而开发人员则希望会议尽快结束，所以根本不注意听其他人汇报，只等自己开口汇报，而轮到自己的时候，则尽可能地长话短说，快点结束。

我们应该清楚，这就是许多每日站立会议的现状。这样的每日站立会议并不理想，但仍然有成效。项目经理能看出自己的计划存在什么问题，而且从长远看，开发人员也能从中受益，因为对他们确实有所影响的问题可以由此尽早解决。从总体上看，这利大于弊，值得付诸实践。

那么要是开发人员和项目经理的思维模式不同会怎么样？如果团队中每一位成员对每日站立会议的态度都截然不同会怎么样？

例如，如果项目经理希望团队中每一位成员都参与到项目计划中，会怎么样？项目经理会真心倾听每一位团队成员，不仅仅是为了检查团队成员是否偏离了自己的计划，还要尝试理解群策群力下的计划可能需要怎样改变。项目经理不会简单地将计划丢给团队并下达命令，然后考核团队执行计划的程度，而是与团队成员一起找出完成项目的最佳方式。每日站立会议就是这样一种合作方式，这有助于确保所有成员时刻保持高效。项目的状况每天都会变化，而团队可以利用每日站立会议作出最有效的决策。由于团队每天都会碰头，所以会议上讨论出来的计划变更可以立即应用于实际工作，这就节省了在错误的道路上渐行渐远的时间。

如果开发人员觉得开会不仅报告了状态，还可以理解当前项目的进展，并且可以每天与大家一起探讨如何更好地工作，会怎么样？果真如此，每日站立会议对他来说就会非常重要。优秀的开发人员不仅对自己的代码有想法，而且常常对整个项目的发展方向怀有见解。通过每日站立会议，他可以确信项目正在以合理高效的方式运行。他还可以确认，从长远看自己的编码工作可以得到更好的回报，因为项目中的其他部分也在正常运转。他还会知道，如果他在会议中对计划提出问题，那么其他所有人都会倾听，项目也会因此更健康地进行下去。

图 1-3：如果团队中每一位成员都觉得自己在项目规划和运行中享有同等地位，那么每日站立会议就会变得更加有价值，而且更加有效

换句话说，即使团队中所有成员都认为“每日站立会议就是一种不得不一起做的进展汇报”，这仍然值得实施，尽管它只比传统的进度报告稍微有效一点儿。要是所有团队成员都明白，每日站立会议的目的是保证每一位成员都在正轨上，大家都在为同一个目标努力，而且每个人都可以对项目的运转方式发表自己的看法，那么每日站立会议就会高效得多，而且所有人都会更加满意。开发人员应该明白，每日站立会议从长远看对他自己和整个团队都是有帮助的。而项目经理应该明白，当团队成员齐心协力完成计划的时候，项目可以得到更好的结果。有了正确的态度，每日站立会议就可以帮助大家更高效地团结协作，更直接地沟通，更轻松地把工作做好。

上面这个例子展示了团队的思维方式和态度对于接纳敏捷实践的巨大影响。本书的一个重要目标是帮助你理解团队的思维方式会对项目和敏捷实践产生怎样的影响。通过探究 Scrum、极限编程、精益和看板方法，你可以从原理和实践两方面学习敏捷，还可以学会如何综合利用这些敏捷方法，构建更好的软件。1.2　本书的读者对象

你和你的团队有没有遇到过下面描述的这些情况？

你尝试了一种敏捷实践，但是并没有成效。也许你们确实实施了每日站立会议，现在团队每天都会碰一次头，但你还是被各种问题所困扰，理不清头绪，而且无法按时完成任务。也许你已经开始编写用户故事，并且与团队和利益干系人一起审核这些用户故事。但是你手下的开发人员仍然在手忙脚乱地添加特性，应付不停变化的需求。也许你的团队尝试采用 Scrum 或极限编程之类的方法进行大规模敏捷化，但似乎总是感觉华而不实，好像所有人都做了必要的事情，但是项目得到的改善却微乎其微。

又或许你们还没有开始尝试敏捷，但是你已意识到你的团队正面临严峻的挑战，而你不知道从哪着手。你希望敏捷方法能帮你应付那些总是在改变想法的严苛用户。用户每次改变需求，你的团队都需要做更多的工作，最终得到的代码打满了补丁，像意大利面一样纠缠不清。于是软件越来越容易出错，也越来越难维护。你的项目可能一团混乱，最终能够发布全靠加班和逞强，而你希望能通过敏捷给团队指一条出路。

你可能是一位担心手下团队无法交付重要项目的高管。你也许听说过敏捷，但是并不知道敏捷到底是什么意思。你能不能直接命令手下的团队采用敏捷？或者说你是否需要跟着团队一起改变思维方式？

如果你面临上述情况中的任意一种，而且想改进团队工作的方式，那么本书可以帮助你。

本书会解释敏捷方法的理念，包括敏捷方法的产生、能解决的问题，以及包含的价值观、原理和思想。本书会讲解敏捷的过程，进而讲解其着眼点，让你能够找出相关原理，以解决团队、公司和项目中遇到的问题。本书会教你如何利用这些信息选择正确的方法和实践。

本书还适合一类人，那就是敏捷教练（agile coach）。公司和团队越来越依赖敏捷教练来指导他们采用敏捷方法和实践，以及为团队中每一位成员树立正确的思维方式。敏捷教练可以通过本书学习一些方法，借此更好地与团队沟通敏捷思想，应对日常敏捷训练的挑战。1.3　本书的目标

我们希望你可以通过本书达成以下目标。理解高效敏捷团队背后的思想动力，以及整合这些思想所需

要的价值观和原则。了解最流行的敏捷流派（Scrum、极限编程、精益和看板），

理解这些各不相同的方法如何实现敏捷。学会可以立即用到项目中的具体敏捷实践，同时熟悉高效实

践所需的价值体系和原则。更好地理解自己的团队和公司，进而选择与你自己的思维方

式匹配（或尽可能匹配）的敏捷方法。让你和你的团队开始学习

一种新的思维方式，从而向更高效的敏捷团队迈进。这些不同的敏捷方法和实践对于构建更好的软件到底有什么

帮助？为什么这些方法可以让团队更好地处理变化？为什么这些

东西是敏捷的？这些具体的做法，比如在规划的时候使用索引卡

或开会的时候站着，真的有用吗？对于刚刚踏上敏捷之路的人来

说，这些问题很难回答，而且往往让人感到困惑。读完本书之后，

你就会有自己的答案了。查找讨论敏捷软件开发的博客和文章，你可能首先会看到这

样的观点：“敏捷开发好，瀑布式开发不好。”为什么敏捷开发

好，而瀑布式开发不好？为什么这两种方式互相冲突？有没有可

能让一个采用瀑布式开发方法的团队敏捷起来？读完本书之后，

这些问题也会有答案。1.4　努力建立敏捷思维

本书名为《学习敏捷》，因为我们真切地希望你学会敏捷。过去二十多年，我们一直在与为真实用户开发软件的团队一起工作。过去十多年，我们也一直在撰写与软件开发相关的图书（包括 O'Reilly Head First 系列中非常成功的两本书，分别是关于项目管理和学习编写代码的）。借助这些经验，我们发现了很多介绍复杂概念和技术概念的方法，可以让枯燥的内容变得平实易懂。

我们尽量让这些材料有趣且吸引人，但这里仍然需要你的配合。下面来介绍一下本书通篇使用的教学技巧，它们可以帮助你牢牢记住书中的知识。故事回想一下你读过的上一本技术书。你能不能回想起那本书涵

盖的所有主要内容，以及这些内容的顺序？你可能做不到吧。那

么再想想你看的上一部电影。你能不能回想起那部电影中的重要

情节，以及这些情节的顺序？你可以做到。这是因为大脑天生擅

长记忆引起情感共鸣的事情。本书充分利用了人脑的这个特点，

以叙事的方式展开，故事中有人，有对话，有冲突，由此表现人

们遇到敏捷时的真实反应。这些人会碰到问题。我们需要你做的是：想象自己和书中人物遇到了同样的情

况，这样可以与敏捷思想建立起情感连接，从而更容易记住并理

解这些概念。对于书中的小故事，请保持开放的心态。如果你不

喜欢看小说，那就更要如此。在每一个叙事场景中你都可以学到

真正的知识，而这些知识就是本书的核心。图示不同的人会采用不同的学习方法。有些人是视觉型学习者，

这些人看到真实画面的时候更容易记忆。我们希望为你提供尽可

能丰富的学习工具，因此本书中穿插了大量的图示。在某些情况

下，我们会大量使用视觉隐喻，例如通过不同的几何形状来表示

不同的特性，或者通过齿轮的形状表示复杂的软件。我们需要你做的是：如果不是视觉型学习者，你可能觉得有

些图示是多余的，而某些图示根本没有意义。但这对你来说是一

个很好的学习机会。如果真有这种感觉的话，你应该花一分钟时

间思考一下视觉型学习者能从图示中学到什么。这有助于更深入

地理解概念。重复大部分技术书都会采用这样的模式：首先介绍一个概念，然

后详细阐述这个概念，接下来讲解下一个概念。这种方法可以有

效地在一本书中尽量塞入更多的信息，但并不契合人脑的工作方

式。有时候，人们需要反复接触才能真正理解一个概念。因此，

本书会在一章或几章中反复提到某个概念。这种重复是有意为之，

目的就是帮助你深入理解概念。我们需要你做的是：当你第二次或第三次看到某个概念的时

候，可能会想：“前面不是提过这个概念了吗？”没错，确实提

到过，能注意到这一点说明你很棒！其他的读者可能没有注意到，

而你也很难发现每一次重复。这些重复的目的就是为了帮助你学

习。由简入繁有时候，为了更轻松地理解一个复杂的主题，你可以先了解

一些浅显的知识，然后再深入进去。本书便时常采用这种方式：

介绍新概念时，首先讲解一个简化的版本（当然，此处并无原理

性漏洞），之后再进行详尽的介绍。这种方式有两个层面的作用。

如果已经深入理解了这个概念，那么你可以认出这种简化，并且

在情感上有反应，这可以让你保持参与。另一方面，如果你还不

了解这个概念，那么简化的版本可以帮助你入门，为接下来深入

的描述打好基础。我们需要你做的是：如果觉得有的内容过于简单，先别急着

跳过，也不用担心我们避重就轻或是忘记了重要的内容。你很可

能会在继续阅读的过程中发现正在寻找的内容。你可以把复杂概

念的简单介绍看作某种“Hello, World!”程序。这些内容可以让

不熟悉这些概念的读者受到一定的鼓励。他们会有步入正轨的感

觉，并且为后面更深入的学习打下基础。对话式的口语文风为了使内容更加吸引人，本书通篇采用轻松随意的文字风

格。我们在写作中使用了幽默，时不时抖一些文化包袱。有时候

我们会用“我们”和“你”这样的代词，表示我们在直接与你对1

话。这种做法背后是有科学依据的，认知研究 表明，如果感觉

自己在进行对话，那么你的大脑就能记住更多东西。我们需要你做的是：尽管大部分人觉得随意一点并没有什么

问题，但是有些人的确讨厌这种风格。例如，有的读者看到缩写

就会气愤，还有一些人看到随意的文风会觉得内容不够权威。我

们理解这些顾虑。不管你信不信，你很快就会接受本书的风格。要点回顾每一章都会随时总结刚刚讲解的要点。这样可以帮你掌握所

有的知识，不会遗漏重要的概念。你的大脑也可以借机稍事休息。我们需要你做的是：不要跳过“要点回顾”部分。花点时间

看看这些要点。看看能不能回忆起其中的每一个点。如果想不起

来的话，往前翻几页增强一下记忆。常见问题我们花费了大量时间与为真实用户构建真实软件的团队一起

工作，也花了很多时间做关于敏捷的演讲，还与很多人沟通过。

在沟通的过程中，有一些问题是大家反复提到的。我们需要你做的是：阅读每一章末尾的“常见问题”部分。

思考一下，这里列出的问题你是不是遇到过？如果是，你觉得这

个答案怎么样？你也许不喜欢我们给出的答案，但是请思考一

下，并找出其中的真理。如果那不是你遇到的问题，也请思考一

下为什么会有人问这样的问题，这种思考可以帮助你从不同的角

度理解书中的内容（在第 2 章，你会明白为什么在团队中这种

思考非常重要）。现在就可以做的事最有效的学习方法就是付诸实践！每一章的结尾都给出了现

在就可以动手去做的事情，包括你可以独立完成的，以及需要与

团队合作的。我们需要你做的是：显然，你最好真的动手去做！不过现实

情况是，并不是每一个团队或公司都对此持开明态度。因此，本

书要教给你的最重要的一件事情就是：不要推行与团队思维方式

相抵触的实践，这样做不会有好的结果。在尝试动手之前，你要

首先考虑一下团队会有什么反应。这与实际动手一样重要。更多学习资源牛顿曾经说过：“我能看得更远，是因为我站在巨人的肩膀

上。”在这样一个时代写作本书是幸运的，因为现在已经有了众

多关于敏捷软件开发的开创性图书。在每一章的末尾，我们会给

出一些与该章内容相关的参考资料。我们需要你做的是：不断学习！本书全面概述了 Scrum、极

限编程、精益和看板方法，但是我们不可能涵盖这些方法的所有

细节。本书介绍的大部分思想都不是我们想出来的；幸运的是，

你可以向想出这些方法的人学习。教练技巧敏捷教练是帮助团队学习敏捷的人。本书为学习敏捷的人而

编写，同时也可以作为一份指南，帮助有经验的敏捷教练向团队

介绍这些概念。如果你是一位敏捷教练，那么可以在每一章末尾

找到教练技巧。教练技巧可以让你理解我们使用的概念和方法，

并且帮助你在自己的团队中使用这些方法。我们需要你做的是：即使不是敏捷教练，你也应该读一读教

练技巧，因为教别人是一种有效的学习方法。如果是第一次学习

这些概念，你可以想象一下自己要怎样利用这些教练技巧帮助团

队更深入地学习敏捷。1如果你想知道对话式文风如何有助于学习，可以看一看

Ruth C. Clark 和 Richard E. Mayer 的著作 E-Learning and the

Science of Instruction。1.5　本书结构

本书讲解了高效软件团队的价值观和原则、包含这些价值观的学派以及具体实践，以此帮助你理解敏捷。

下面两章讲的是接受敏捷思维方式所需要的价值观和原则。借助这两章所介绍的方法，你可以判断团队和公司是否准备好了接受敏捷，以及哪些敏捷方法适合你的团队而哪些方法可能很难实施。第 2 章阐述了敏捷的核心价值观。我们会展示软件开发项

目团队和困难作斗争的例子，帮助你识别问题的主要来源，也就

是“割裂的视角”。我们会讲解敏捷价值观，并且通过一个隐喻

帮你理解这些价值观如何统一整个团队的视角。第 3 章介绍了敏捷团队在进行项目决策时要遵循的原则。

我们会通过一个实际的软件开发项目的例子，展示每一项原则背

后的目的和思想。接下来的 6 章讲解最流行的敏捷学派：Scrum、极限编程、

精益和看板。学完书中讲解的基本应用，你就可以在团队中进行

实践。第 4 章讲解了流行的敏捷方法 Scrum，并且说明了自组织团队如何工作。我们给出了在自己的项目中引入 Scrum 的方法，还给出了帮助团队学会自组织的工具。第 5 章展示了 Scrum 团队规划项目时采用的具体实践，以及如何利用这些实践在团队中整合力量，交付有价值的软件。我们会揭示 Scrum 价值观与团队及公司文化的契合程度，这决定了 Scrum 的接纳程度。我们还会谈到不契合的情形，以及应对方法。第 6 章会教给你极限编程的主要实践及其价值观和原则。你会了解它们如何有助于每一位团队成员建立正确的思维模式，以便写出更好的代码：不要憎恨变化，团队中的每一位成员都要学会拥抱变化。第 7 章讲解了极限编程的最后三个主要实践，以及如何利用这些实践避开严重的代码和设计问题。你会了解所有极限编程实践如何构成一个生态系统，帮助构建更好、更易维护、更灵活以及更可变的软件。第 8 章讲解了精益方法，以及建立精益思维方式所需要的价值观。我们会讲解如何利用精益思考工具帮助团队发现并消除浪费现象，以及如何对构建软件的系统建立全局观。第 9 章介绍看板方法及其原理、看板方法和精益方法的关系，以及看板方法的实践。你会明白强调流和排队论的看板方法如何帮助团队将精益思考用于实践。你还将学会如何利用看板方法帮助团队建立一种持续改进的文化。思维方式、方法和学派并不是敏捷世界的全部。很多公司越发依赖敏捷教练帮助团队接受敏捷方法。因此本书的最后一章献给敏捷教练。第 10 章讲的是敏捷训练：团队怎样学习敏捷方法；敏捷教练怎样帮助团队改变思维方式，以便更轻松地采用敏捷方法；敏捷教练怎样帮助你和你的团队变得越来越敏捷。图 1-4：Andrew Stellman 在 STRETCH 2013 会议（匈牙利布达佩斯）上演讲的现场图记。这个演讲的内容基础就是本章图记：Kata Mat́hed 和 Maŕti Frigyikhttp://www.remarker.eu  第2章 理解敏捷价值观我们并非因为拥有美德和优点而行事正确，而是行事正确让我们拥有美德和优点。不断实践的行为会决定我们成为什么样的人。优秀不是一种表现，而是一种习惯。——亚里士多德《尼各马可伦理学》

作为一次变革运动，敏捷不同于以往的软件开发方法，它从思想、价值观和原则入手，形成了一种思维方式。拥有这样的思维方式，你会成为更加敏捷的实践者，也会成为更有个人价值的团队成员。

敏捷运动在软件开发的世界中是一次颠覆性的变革。采用了敏捷的团队会发现自己构建优秀软件的能力不断增强，有时候甚至会有巨大的飞跃。成功采用了敏捷方法的团队能构建更优秀、更高质量的软件产品，而且开发速度也比之前要快。

业界正处于迈向敏捷的转折点。敏捷方法不再是一种不入流的方法，而是成为了正规的学派。在敏捷方法出现的头几年，采用了敏捷方法的人费了很大力气才让自己的公司和团队相信它可行且值得实践。现在，没有谁会质疑敏捷方法在软件开发上的高效。事实上， 12008 年，一项重要的调查 表明，超过一半的受访团队正在遵循敏捷方法进行实践，或是遵循了一部分敏捷原则。敏捷正是从那个时候开始流行的。此外，越来越多的敏捷团队已经不满足于通过敏捷解决自己的问题，而是开始考虑怎样在全公司范围内推广敏捷开发。

1Forrester 2008 全球敏捷公司在线调查。

不过敏捷的推广并非一帆风顺。很多公司在运作软件开发项目的时候习惯于采用瀑布式流程（waterfall process）。在瀑布式流程中，团队首先定义好软件的需求，对项目进行完整的规划，然后开始软件设计，接下来再进行代码编写和产品测试。多年来，大量的软件（既包括非常好的软件，也包括垃圾软件）都是通过这种方式构建的。但是几十年来，不同公司的不同团队都遇到了相同的问题。因此有人开始怀疑，项目失败的根源也许就是瀑布式流程本身。

敏捷的故事始于一小群创新者，他们聚在一起试图找到解决这些问题的新方法。他们一开始就对以下这四则价值观达成了一致，认为这些是成功团队和成功项目共有的特质。他们把这四则价值观称为“敏捷软件开发宣言”（Manifesto for Agile Software Development）。个体和互动高于流程和工具可工作的软件高于详尽的文档客户协作高于合同谈判响应变化高于遵循计划在本章中，我们会学习这些价值观，包括其来源、意义以及

如何将它们应用到自己的项目中。我们会对一个厌倦了瀑布式开

发的团队进行追踪，介绍在团队成员还没有真正理解如何应用这

些价值观的时候是怎样初步尝试实现敏捷开发的。当你阅读他们

的故事时，请思考为什么更好地理解这些价值观可以帮助他们避

免问题。故事：有一个开发流式音频点唱机项目的团队Dan——开发主管和架构师Bruce——团队主管Joanna——新招进来的项目经理Tom——产品所有者2.1　团队主管、架构师和项目经理走进了一间酒吧……

Dan 在一家开发投币游戏和信息亭软件的公司担任开发主管和架构师。他参与过很多项目，从制作弹球街机到开发 ATM 机。在过去几年中，他与团队主管 Bruce 合作。他们负责开发公司最大的一款产品：一款名为 Slot-o-matic Weekend Warrior 的 Vegas 老虎机。

Joanna 是几个月前招进来的项目经理，负责领导一款新型流式音频点唱机的软件开发。公司希望在酒吧和餐馆推销这款产品。她在这个项目中非常重要，因为她是公司挖来的，她的老东家开发了一款风靡市场的点唱机。她已经与 Dan 和 Bruce 相处得非常好了，而且十分期待与他们一起开始的新项目。

与 Joanna 相比，Dan 和 Bruce 对这个新项目没有多少精神头。有一天他们一起出去喝酒，Bruce 和 Dan 聊到，团队私底下把老虎机项目叫 Slog-o-matic Weekend Killer，可见新产品并不被团队看好。

在这家公司，项目失败居然是规律而不是意外——发现这一点，Joanna 感到不舒服。公司的经理声称最近的三个项目是成功的，但是这些项目能发布靠的全是 Dan 和 Bruce 疯狂加班。更糟糕的是，他们故意在代码里偷工减料，导致现在的支持工作成为了噩梦。例如，他们为了某个特性而仓促地做了一个原型补丁，然后就推到产品中了。事后证明这里有严重的性能问题，因为有部分代码根本不能向上扩展。

在他们聊天的过程中，Joanna 找出了其中的模式，明白了导致问题的原因：公司采用的是特别低效的瀑布式流程。采用瀑布式流程的团队尝试尽可能早地对要开发的软件写出一份详尽的描述。一旦所有的用户、经理和主管都同意了软件要实现的功能（需求），就会给开发团队递交一份包含这些需求的文档（需求说明书），然后开发团队就动手构建说明书中描述的软件。完成之后，测试团队介入，验证软件与文档是否匹配。很多敏捷实践者把这种方式称为前期的详细需求分析（Big Requirements Up Front，BRUF）。

不过拥有多年项目经验的 Joanna 也知道理论和实践的差距，尽管有一些团队可以实施非常高效的瀑布式流程，但是有很多团队却为这个流程而感到痛苦。她开始感觉她所在的这个团队就是众多感到痛苦的团队之一。图 2-1：瀑布式模型

在他们聊天的过程中，Bruce 和 Dan 又聊到了一些事情，进一步验证了 Joanna 的观点。 Joanna 怀疑公司里有无数说明文档藏在文件夹里蒙尘已久。从某种程度上看，所有人都期望一组用户、经理和主管给出一个完美的需求说明文档。实际上，需求说明书经常变化。到达开发团队手中的那一刻，需求说明书可能已经不准确了。当开发团队完成软件构建的时候，需求说明书可能已经面目全非了。Bruce、Dan 和公司里的很多人都知道完美的需求说明书并不存在，但是他们在运行项目的时候仍然假设需求说明书就是完美的。

时间越来越晚了，Bruce 也越来越放松（还有点小醉意）。他提出了另一个困扰他的问题：在公司里，他工作过的很多团队在构建软件的时候实际上存在很多困难。即使用户十分罕见地提出了准确的需求，即便整个团队破天荒地通过需求说明书完美地理解了这些需求，他们也常常会使用很糟糕的工具，而且在软件设计和架构设计上遇到了很多困难。结果，团队总是开发出有很多 bug 的软件，而且往往混乱而不可维护。

有很多项目的失败都是因为这两个原因，如果把需要长时间工作（每周 90 小时）的项目和充满 bug 的代码称为失败的话，那么以上两个问题就更能解释失败的原因了。Joanna 解释说这些失败的最主要原因就是公司采用的瀑布式流程无法应对变化。在理想情况下，瀑布式流程没有任何问题，因为在项目初期大家就精确地知道项目结束的时候需要造出个什么东西。这样的话，他们可以在一份优雅的需求说明书中把一切写下来，然后交给开发团队。但是项目开发其实从来不会这么美好。

Dan 和 Bruce 现在真的醉了，开始向 Joanna 进行马拉松式抱怨。Dan 说，他工作的项目几乎每一个都遭遇过客户中途反悔，总要开发和最初计划不同的功能。这样，所有人都要回到瀑布模型的最初状态。根据团队采用的严格瀑布流程，他们要从头写一份新的需求说明书，然后进行完全不同的设计，接下来再构建一个全新的计划。实际上没几个人这么做，而且人们极少抛弃已经编写的所有代码，因为时间不允许。相反，他们通常会在现有代码的基础上商定出一个修改方案（hacking）。这样的修改容易产生 bug。在为某一个需求而设计的代码上匆忙修改，使其满足其他需求，这种做法往往会得到混乱交织的代码，如果团队处于压力之下，则更是如此。根据新的需求重写代码会浪费宝贵的项目时间，因此他们最后都会采用糟糕的替代做法（workaround），编写出不可靠的代码。

这一夜结束的时候，Dan、Bruce 和 Joanna 开始意识到导致他们项目存在问题的原因——过分严格的文档、糟糕的沟通以及代码中的 bug。这些导致项目无法跟上正常的变化。

最后，酒吧的服务生帮他们三位叫了出租车。在离开之前，Dan 表示他抒发了胸中淤积已久的怨气。Joanna 很高兴她对于即将加入的项目有了更好的想法，不过并不乐观。她不知道自己是否能够找到方法来解决这些问题。2.2　没有银弹

如今我们都知道软件构建没有最佳方法。现在没多少人会去争论有没有包治百病的灵丹妙药，但是业界在 20 世纪很长一段时间都坚信一劳永逸。很多从业人员认为能找到一种高度规范的方法，解决所有人在所有场景遇到的项目问题。很多人认为开发人员只要遵循一定的步骤就可以开发软件了，就好像看着菜谱做菜，或者在生产线上组装产品一样。（具有讽刺意味的是，软件工程领域被引用最多的论文就是 Fred Brooks 在 1986 年发表的“No Silver Bullet”。在这篇文章中，他对这个不可能的目标下了定论。但是这并没有阻止人们去寻找象征着灵丹妙药的“银弹”！）

有不少人对这些类别的问题提出了银弹解决方案。这些解决方案通常都逃不出两种形式：一类属于方法（methodology），号称可以为团队提供一套防误操作的软件开发方案；另一类属于技术，据说可以让程序员防止或消除 bug。这背后的思想就是：如果一家公司决定采用某种方法或技术，那么所有的团队都要遵循公司的正统规范，这样就能源源不断地开发出优秀的软件了。

Dan 和 Bruce 以亲身经历证实这是不可能的，因为他们多年来在公司的项目管理中提出了很多方法和技术，但是都没有带来真正的长期改进。公司每一次寻找软件开发流程银弹的尝试都让所有人失望。Bruce 和 Dan 尤其感到烦恼，因为他们被要求遵循不断变化的流程，而他们并不希望流程发生变化。

Joanna 在职业生涯中也常常碰到类似情况。在上一份工作中，她总是收到一组组严格规定的需求，而且被要求制订计划，将新的需求体现在软件中。接下来她还把自己的计划转交给开发团队，要求严格执行。像这种“做计划，然后执行计划”的团队常常开发出丧失时效性的软件，即使是在部署当天也可能让用户觉得不实用。

让 Joanna 犹豫的是，她工作过的一些团队确实可以通过严重依赖前期文档的瀑布式流程发布优秀的软件。她在一家开发医疗设备软件的公司中用瀑布式实践管理了她最棒的几个项目。

瀑布式流程确实也有用。事实上，如果你明确知道想要做什么，那么在初期将需求写下来是构建软件非常有效的方式。Joanna 的医疗设备软件项目是少有的需求在一开始就很明确的例子，这种项目在实施期间需要做的改动非常少。

可是稳定的需求并不是瀑布式流程成功的唯一因素，这类项目总会遇到很多问题。可以采用瀑布式流程开发优秀软件的团队通常都有以下特点。沟通顺畅。在要求使用瀑布式开发的公司里，成功的团队都

会在整个项目期间不断地与用户、经理和主管沟通。实践得力。代码审查和自动化测试阶段的工作尤其有效，可

以在流程中尽早发现 bug。人们通常把这个过程称为缺陷预防（defect prevention）。这要求团队主动去思考 bug 最开始是怎样

引入代码的。多数文档很少打开。团队成员都明白，写下计划这件事情本

身（以及在制订计划的过程中提问）比盲目严格执行计划要重要

得多。这里还要说到一点。Dan 的职业生涯是在 20 世纪 90 年代

软件开发工具和技术变革之后开始的，因此，他工作过的团队都

会以面向对象的开发技术设计更好的软件。Dan 在工作中还会使

用版本控制系统、自动化测试工具、包含自动化执行代码重构和

类似设计功能的集成开发环境（Integrated Development

Environment，IDE）以及其他一些革新的工具辅助代码的编写。

Bruce 参与项目的时间比 Dan 要早，他目睹了团队中的开发人员

不断采用新工具自动化一些重复性的日常任务。Bruce 和 Dan 通

过实际项目经验认识到，最成功的项目会充分运用优良实践、工

具和思想，将时间节省下来，与用户和同事沟通。他们应当思考

如何解决问题，而不是花时间去与代码作对。事实证明，在高效运转的瀑布式项目中，团队成员遵循的价

值观、原则和实践往往与敏捷项目异曲同工。那些使用了一些敏

捷技术和方法但是没有真正遵循敏捷价值观和原则的项目，通常

都会遇到困扰瀑布式项目的问题。遗憾的是，Bruce、Dan 和 Joanna 将要通过痛苦的方式意

识到这一点。要点回顾

试读结束[说明：试读内容隐藏了图片]

下载完整电子书