《敏捷开发的艺术》第二版序

推荐序一

《敏捷开发的艺术》第一版发行于2009年，一经发行便成为了众多软件从业者在工作、生活中随手可及的瑰宝。作为软件从业者的我们，都曾为这本书着迷。当华章的编辑老师推荐我们编译这本书第二版的时候，我们欣然答应。

可以确信的是，《敏捷开发的艺术》第二版依旧精彩，它将现代软件交付浓缩到一本简短、可读并且有趣的书中。对于刚接触迭代交付的人来说，它针对敏捷实践提出了精彩的概述；对于迷失在过度工程化的“大规模敏捷”流程中的团队来说，它提供了逃离此“地狱”的好主意。我们在翻译的过程中也融入了很多我们的见解和实践，我们相信这本书会继续帮助数以百万计的开发者改善软件交付方式。

如何深入思考敏捷思想在现代数字化时代所扮演的角色？

2000年初，敏捷刚进入中国的时候，国内的软件从业者对敏捷还是懵懂的状态。十多年来，大家对敏捷的理解日益加深，都意识到传统开发模式带来的问题，不断剖析着瀑布模型的适应局限以及给业务、IT部门带来的痛点。研发团队越来越重视对业务的响应速度。大多数企业的研发团队已经理解实施敏捷的益处，很自然地接受并开始践行敏捷：

引入敏捷的管理实践，比如需求管理、用户故事、进行迭代管理、制定发布计划

引入敏捷的工程实践，比如结对编程、代码管理、自动化测试、持续集成、持续发布等

引入相应的团队工具，比如看板、线上协作、知识管理与协同、事务跟踪等

然而时至今日，在与很多企业的CIO、CTO、以及IT部门的各级主管交流时，我依然可以看到：大多数企业IT部门的职能还停留在“业务支持”的程度，是为业务部门提供IT系统支持的组织。这也造成了传统企业中IT部门的员工，更多的是承担甲方项目经理的角色。IT部门的员工在业务或专业能力上很难得到持续的积累和沉淀，整个研发团队的生产力和创新氛围也受到影响。与此同时，IT部门面前有成百上千个需要用⾼昂的成本进⾏支持和维护的遗留系统，尽管他们愿意响应快速变化的市场需求，但在项目周期与成本压力面前，却又显得力不从心。

《敏捷开发的艺术》犹如一本圣经，将敏捷软件开发的理论与实践娓娓道来，切实地帮助我们分析并解决上述问题。在今天，敏捷思想在业内广受尊重，客户也常常期望我们助其变得敏捷。 目前的挑战是软件世界被“伪”敏捷所淹没，许多公司认为完成 Scrum/SAFe，数字化工作就结束了。殊不知我们现在所说的敏捷，早已不限于敏捷研发和敏捷项目管理。

事实上，敏捷的概念已经扩散到组织的每个领域，而数字化时代需要的是打造敏捷的组织实践。我们认为，“数字变革”是这一变化的重要推动力。人们意识到软件已经成为商业活动的重要部分，技术再只作为成本削减的工具。更为重要的是，业务与科技之间的整体关系将被重新定向——敏捷思想是业务数字重定向的核心，在数字化转型中起到重要作用。在此基础上，咨询顾问通过建立统一的流程、打造共享的技术平台、建立创新型的组织文化来不断推进业务与IT的深度融合。

数字化转型有一个非常重要的目的，就是让客户和最终的生产者距离更近，提升效率，进而降低客户和企业内部交易成本。转型的关键在于拉通客户端的需求和企业内部生产运营，这就需要企业内部各个部门的快速协作与灵活变通，这些工作是最难的。作为数字化转型顾问和大型研发团队的领导者，我很庆幸看到本书的问世，书中的很多实践、工具、流程以及敏捷开发的艺术正在帮助我们推进数字化转型。

建议大家静下心来，阅读这样一本好书。祝阅读愉快！

万学凡 凯捷中国副总裁，数字化团队负责人

推荐序二

开发软件产品是为了解决业务问题，特别是复杂的业务问题。我们为什么需要敏捷？因为世界变化太快，无论是外部的市场环境、消费者习惯、行业竞争，还是企业自己的业务、战略、组织、流程，随时随地都在发生着变化，这就造成了业务问题的不稳定、不确定、复杂和模糊。要解决复杂多变的业务问题，需要基于对业务和用户的深刻洞察，快速测试与验证假设，持续不断地迭代解决方案，这正是敏捷。

企业管理追求确定性，特别是财务相关流程，比如营收预测和预算管理。因此，许多企业管理者习惯于使用瀑布式的项目管理来开发软件产品。这种长期的瀑布式项目管理是基于确定性的，认为业务需求和方案设计在项目计划阶段就可以确认清楚，在项目执行阶段只需要精确管理建设过程，就像盖房子一样，由此就可以保证成功。然而现实情况却并非如此，仅在项目建设阶段，许多业务需求就已经发生了显著变化；项目组则往往会极力去管控这些变更，希望按照原定计划上线。在经历了千辛万苦后，项目终于成功上线了，然而仍然无法解决原本希望解决的业务问题——没有能够创造业务价值，项目实际上是失败的。

企业要想从传统的管理模式转变为敏捷，需要一场变革，涉及到组织、流程、人员和工具等方方面面，充满了各种挑战。本书为我们提供了全面的帮助——这本敏捷工具书面向的读者包括企业管理者、敏捷团队成员以及所有与敏捷团队合作的同仁。作为企业管理者，可以了解敏捷理念和运作方式，以及如何引入敏捷或者改善公司现有的敏捷实践；作为敏捷团队成员，可以学习如何持续改善团队合作、流程和工程实践，持续提升交付质量与创造价值。因为本书涵盖的话题十分广泛，作者无法尽述所有方面，读者可以关注书中的延伸阅读，对感兴趣的主题进一步学习；与此同时，译者在每一章节都加入了导读，其中的专业见解和洞察也让本书更具价值。

知行合一，认知升级需要持续地学习和新鲜思想的输入。感谢这样一本好书，祝所有行动者好运。

王泳帅 宝洁大中华区信息技术部CTO

推荐序三

本书书名包含「艺术」一词，但实际上更是一本详尽的手册，它阐述了敏捷研发的各个方面：从文化、管理、团队合作到开发和设计的原则与质量，以及持续集成等内容，全面地讲明了要在敏捷开发中取得成功，我们需要关注的核心问题。 

作为知乎的CTO，我一直在追寻卓越的软件开发实践，本书让我看到了知乎实践在书中的映射。它如同一盏明灯，照亮了我们前行的道路，使我们更加坚信自己前进的方向。作者在本书中深入浅出地探讨了敏捷开发的核心理念，强调了文化与价值观的重要性。他们指出，敏捷开发不仅仅是一套流程，更是一种思维方式和团队的共同理念——文化才是真正支撑和推动敏捷开发的根基。在我们的实践中，这种文化变革同样至关重要，只有当每一位团队成员都以相同的敏捷精神对待工作，才能真正发挥敏捷方法的威力。 

书中对敏捷团队合作的描述也令我深感共鸣。团队是软件开发的核心，而敏捷团队则更加高效和灵活。作者强调了协作、自组织和跨功能的重要性，这也与我们在知乎的实践紧密贴合。唯有于此，在追求创新和持续发展的过程中，每个团队成员的才华和贡献才能得到最大程度的尊重和发挥。当然，书中所论及的不仅仅是团队合作，作者更是剖析了敏捷开发的各个环节，每个章节都体现了大师们对于软件研发的精湛理解。这些原则和实践对于保障软件的高质量和稳定性至关重要，也正是我们这些软件从业者一直追求的目标。 在本书中，我找到了很多知乎团队所需要的启示和指引，每一页都散发着智慧与洞见，每一章都激励着我们更加努力地追求卓越。这是一本我们值得拥有的书籍，我相信它也将成为将敏捷组织作为前行目标的团队必备指南。 

这本书第一版在十多年前就已发行，粉丝众多。很多在那个年代还很超前的理念，在今天已经成为了行业里普遍认同的最佳实践。随着大模型等新兴AI 技术的演变，我们也正在思考如何将先进的技术引入到我们的敏捷实践中，期待看到作者和译者在未来的著作中有更多对于这些方向的实践和思考。让我们一起努力。

知乎CTO兼面壁智能CEO 李大海

推荐序四

今天的软件行业和十多年前相比发生了天翻地覆的变化，敏捷开发已是软件领域中的主流，俨然成为现代系统开发和数字化转型的核心。软件行业的创新也从未停止，ChatGPT不仅替代人工用于软件测试，提供运维支持，甚至还能直接编写代码。象牙塔里追求优雅代码的软件工程师不断思考着如何为项目和组织带来更高的透明度，追求更合理的迭代过程和更快的反馈。

在我所处的团队中，我们正在不断学习和实践敏捷开发的方法和工具。同时，我们意识到团队需要将敏捷开发的理念和文化贯穿到整个组织中，这是一个知易行难的过程。我们重视团队建设和人才培养，致力于建设高效协作的团队文化。此外，我们建立了敏捷的组织架构和流程，通过技术打破传统的职能壁垒，以实现团队的快速响应。这需要我们具备持续学习和实践的能力，不断提高自身的敏捷性，积极探索和应用新技术，不断创新、优化业务流程和产品服务以提升用户满意度。这是本书为我带来的最大启示。

浅白中见深刻，不显山露水却又笔墨横姿，这是本书的风格。要掌握敏捷，意味着超越我们所列出的实践方法。敏捷开发与具体环境的关系十分紧密，不可能有一种方法完全适合所有的情况。敏捷开发也十分精妙，任何一本书都不可能教会你怎样精通它，精通来自经验，也来自于对一种选择所能引发的后果有直觉的理解。

本书在讲述敏捷原理和实践同时，提供了许多实际案例，帮助读者理解如何在实际项目中应用敏捷方法。没有任何过程是完美的。每一种方法都有一些潜在的需要改进的地方。我们的目标是消除位于团队和项目成功之间的每一道障碍，并且当条件改变时随时调整我们的方法以适应新的情况。这就是敏捷。

感谢译者，为我们带来了一本经典好书。要掌握敏捷开发的艺术，我们需要经验和感悟。经验能使我们看到敏捷方法如何起作用。感悟则能帮我们理解经验。经验和感悟，永无止境地连接在一起，这是通向精通之路。与各位共勉。

吉利集团IT中心CTO 郑金伟

推荐语

软件工程是一门在危机中诞生的学科。每一个软件从业者，从程序员到架构师，从运维人员到企业高管，都有着被各种deadline和bug所支配的焦虑经历。作为一种价值观和开发者文化，敏捷以独特的形式为软件从业者开启了一条在效率和质量间取得平衡的途径。与初版相比，本书第二版内容上更加充实，不仅体现了近年来敏捷实践的最新进展，而且其编排体例和行文风格也能帮助读者快速定位自己感兴趣的观点和内容。无论你希望掌握敏捷的艺术，还是想成为一名熟悉敏捷工具的实用主义者，这本书都能让你开卷有益。

华中科技大学软件学院教授 沈刚 

在敏捷宣言诞生的二十年内，对于敏捷的愿景和方法，已经有很多出版物作出了诠释和解读。但知易行难， 在我们的工程团队与客户转型敏捷项目交付的过程中，对敏捷的理解和实践总有不同的认识与交付结果。是流于形式的工具和流程，还是忠实敏捷的精神，回归初心，重新关注宣言中的左项价值？项目实践中，这些冲突会一直在技术理念与商业利益的博弈中反复拉锯。

本书再版正是在这些冲突和流于形式的敏捷误区的基础之上，作者针对第一版落地方法的实践几乎都进行了重写。认真、客观地对敏捷在商业世界运行的多年经验进行了剖析和解读，专注于价值本身。同时分析了规模化敏捷失败的可能原因，以及与DevOps的结合应用，对敏捷方法在团队中的运用做出了详尽指导。作为团队管理者，毋庸置疑，本书为我们提供了一本最佳指南。

凯捷咨询云与人力资本管理服务线总经理 徐飞

君子不器，敏捷同样如此。从敏捷宣言发布以来的20多年时间，逐渐发展出来了很多流派、方法、实践，敏捷不应该像一个器具那样，只具有一种功能或只限于某种特定场景。在本书中，我们看到了敏捷本身与时俱进的变化，在演变的过程中不断完成自我迭代，更加具有实操性、更加关注业务价值，所以也越来越多地应用于不同领域、不同行业并取得成功。本书完全可以作为一位软件从业人员的案边书籍，当我们在研发过程中自认为对很多方法融会贯通的时候，建议再翻看本书，一招一式拆解一遍。不忘初心，我们都会有新的思考和成长。

OPPO软件IT部部长 裴哲

敏捷开发的艺术，书如其名。无论是敏捷团队的成员，还是工作在一线的管理者；无论是初识敏捷的新生，还是运用自如的老手，都值得一读。敏捷的本质是以客户价值为核心，不断拥抱变化以快速响应客户需求。如何界定价值，应该拥抱什么频率的变化， 以什么样的速度响应客户需求, 快速交付与质量保证如何平衡? 践行敏捷的我们或多或少会有类似的疑问。本书提供了丰富的最佳实践指南, 定能为我们答疑解惑。祝开卷有益。

宝洁信息技术研发总监 童熙

谈起敏捷开发，一百人眼中可能有一百种不尽相同的理解。做产研的同学如果说自己团队的交付不是敏捷的，感觉会被当成不入流的异类，但真正投身敏捷的诸位所经历的变革过程和酸甜苦辣唯有自己知晓。正如本书十五年后再版，回归初心，重申敏捷宣言和要解决的核心问题，提纲挈领的强调敏捷是一种投资以及敏捷本质上带来了组织价值交付方式的变革。

本书系统化地从团队合作基础开始，将我们都很“熟悉”的敏捷要素一一解读，融入15年间无数团队实践敏捷的得失体验。结构化的叙述，掷地有声的分享，让我们受益匪浅。其中的规模化敏捷，团队建设等章节更是让我感同身受。本书会给大家一个停下脚步，重新审视前行方向的契机。推荐阅读，与各位共勉。

阿迪达斯中国数字化中心高级总监 王博

距离本书第一版已超过十五年，对众多敏捷开发的从业者而言，它都是不可不读的经典。本次再版，既是在前作经典之上的延续，也是通过全面重写将这十几年来软件研发的发展历程娓娓道来。我强烈推荐这本敏捷开发的经典之作，建议我们都能沉下心来仔细研读，从中找到自己心中一直不断追寻的答案。

华为云应用平台部首席解决方案架构师、中国DevOps社区联合发起人 姚冬

本书的主要作者James Shore是敏捷开发早期的先驱者，开创了极限编程的先河；James与本书合作者之一的Diana Larsen共同创建了“敏捷流畅度模型”（Agile Fluency Model）。当我们翻开本书，受益于大师们镌写的经典，在字里行间中我们能够更深刻地理解敏捷实践，感受在践行企业敏捷转型过程中的包容与思辨。感谢这样一本好书，中国的敏捷实践者，加油！

荣庆物流信息技术部总监 刘永生

在软件开发的世界里敏捷早已不是一个新鲜词，但能够将敏捷做好的组织却并不多。本书从敏捷的起源、理论入手、再结合实践，深入浅出地探讨了如何践行敏捷，最大化组织与个人价值，从而推动整个企业的敏捷转型。对于软件从业者，本书亦是一本非常好工具手册，我们可以像查阅字典一样进行针对性地阅读，为我们答疑解惑。

默沙东中国IT产品总监 黄飞铭

当我们正苦恼着该如何拥抱敏捷，并期待藉由敏捷之道来推动数字化转型的时候，本书已将其宝贵的经验与扎实的工具组合集结成册，从基础入门到案例拆解、从思维启蒙到追求卓越，以高效、深刻的方式引导着在VUCA时代生存的每一个团队与企业。感谢译者为我们带来这样一本实用又精彩的好书，也非常庆幸在追求敏捷的道路上有这样一本好书相伴。打开它，让我们一起敏捷吧！

金融业首席信息官 冯胜雄

我非常高兴看到《敏捷开发的艺术》第二版的翻译出版。相比第一版，过去的十多年里，敏捷开发在软件领域得到了更多实践，并取得了更大的发展。它不仅仅是一本关于敏捷开发的操作指南，更是一本带领读者探索软件开发艺术的良师益友。

无论你是软件开发新手还是资深从业者，这本书都将为你和你的团队提供宝贵的知识和实践经验。在此感谢译者团队，你们长期工作在中国敏捷开发实践的第一线。正是这些常年实践的积累，使你们能够深刻理解敏捷开发的真谛，并用最好的方式将其呈现给广大读者，使这本书成为一本既实用又易读的精美之作。

愿更多的读者通过这本书学习到敏捷开发的方法，领略敏捷开发的艺术，并在探寻敏捷之道的过程中有所收获。

极客邦科技副总裁 & TGO 鲲鹏会总经理 杨攀

译者序

关于本书

本书第一版在2008年出版，当时敏捷的思想才刚刚开始在软件开发领域萌芽，许多人对敏捷的理解还停留在表面层次。如今，经过十多年的发展，敏捷已经成为了软件行业的主流方法。然而，敏捷的实践和理念仍在不断演变，和众多软件从业者一样，我们发现才刚刚开启敏捷开发这扇大门，走进这座艺术的殿堂。我们想，这正是这本著作再版的原因。

第二版中，作者詹姆斯·肖尔（James Shore）充分运用过去十余年的新工具、技术和经验教训，对第一版进行全面更新和升级。整合极限编程、Scrum、精益、DevOps等领域的最新理念，并结合其二十多年的敏捷实战经验，为敏捷的采用、计划、交付和管理提供有效建议。本次再版中，作者融入了大量精彩案例，并通过讲述各种故事，为读者提供全面、深入的敏捷实践视角。这与我们所在团队倡导的敏捷理念一致：敏捷不仅是一种开发方法，更是一种思维方式和价值观。

本书共分为四个部分，旨在帮助读者深入理解敏捷实践，提升敏捷项目的价值和成功率。第一部分讲述敏捷的本质和追求真正的敏捷实践，通过敏捷力的选择、投资和扩展，引导组织实现敏捷转型；第二部分关注价值导向的敏捷项目，围绕团队合作与持续改善，确保项目始终关注价值创造；第三部分详述敏捷实践中协同合作、开发、设计、DevOps和质量的重要性，旨在提高软件交付的可靠性和客户满意度；第四部分探讨敏捷实践在自主性、探索和展望未来方面的优化，指导团队更好地把握产品规划、预算和实验，以设计市场领先的软件产品。

关于翻译

作为凯捷数字化团队的成员，我们非常荣幸翻译并与您分享本书。与本书的原作者James Shore一样，我们不仅是软件开发者、敏捷教练，也积极参与社区的建设和推广。我们在团队中承担不同的职责；我们一起探讨软件开发的各个方面，包括敏捷开发、测试驱动开发、重构和持续集成等；我们坚信敏捷开发是一门艺术，它正推动着整个行业的发展。

凯捷中国数字化团队在端到端的产品与项目交付方面具有丰富实战经验，我们与作者一样都致力于敏捷实践，在翻译的过程中对于作者的观点和提供的故事，我们感同身受。然而，在翻译过程中我们也面临挑战和困难。首先，敏捷开发领域广泛且复杂，涵盖众多知识和实践。因此，我们在翻译过程中需仔细研究和理解每个概念及实践，并反思在团队敏捷实战中的应用，确保准确地翻译成中文。其次，我们在翻译过程中遇到了术语和概念的翻译问题，需要深入研究和讨论，以确保翻译的准确性和一致性。尽管过程中遇到困难，但我们始终保持高度热情和专注。

我们在每个章节的开始都加入了“译者导读”，这也是我们在阅读本书时的总结和归纳。我们希望读者在轻松的阅读中，能和我们一样从中悟出一些哲理。我们希望通过努力让更多的读者学习并分享书中的内容，以帮助更多数字化从业者从中受益，这是我们不变的初心。

感谢

感谢所有参与本书审校的人员，他们是田楮梦、王艳春、吕征达、孙笑怡、朱伟章、陈蕾、杜佳宇、肖博懿、张立、张明鑫。感谢他们的辛勤工作和无私付出。敏捷开发的一个重要特点是强调团队合作和持续交互。本书的翻译也是遵循了这样的合作模式，我们在一起紧密合作，不断获取反馈，并对译文作出调整。这种持续的交互和反馈机制，帮助我们顺利完成本书的翻译。

敏捷开发是一种高效、灵活和可持续的软件开发方法，它已经成为了当今软件开发中不可或缺的一部分；敏捷开发更是一门艺术，为推动软件开发行业的进步和发展做出了重要贡献。希望各位喜欢我们为大家精心准备的好书。祝开卷有益。

凯捷中国数字化团队 吴衍刚、宋俊毅，梁凌锐、姚文杰

译者导读

第一章 什么是敏捷

敏捷起源于20世纪90年代“软件危机”时期。90年代末，一些轻量级的软考开发方法引起了人们大量的关注。而《敏捷宣言》的诞生，改变了世界，它定义了敏捷的三个要素：名称、价值和原则。

“敏捷开发方法是适应性的，而非预测性的；是面向人的，而非面向过程的”，这段话是对敏捷软件开发本质最好的解释之一。

敏捷的成功包含五个核心概念：以人为本、交付价值、消除浪费、追求技术卓越、改进流程。敏捷之所以有效，是因为人们在采纳敏捷理念的同时，也会使其适应自己的情况，并不断改进。

有很多的人和组织会陷入针对敏捷的“货物崇拜”陷阱之中，所以敏捷也会失败。人们想要敏捷的益处，但他们并不了解其背后的理念，而且即使他们了解了，也往往不愿意投入。

第二章 如何做到敏捷

团队可以通过大量的实践，将敏捷从思想的集合变成实际的、可以在团队中发挥作用的一种工作方式。在使用引入敏捷的过程中，掌握敏捷需要使用特定的方法，而精通敏捷需要经历这样一个过程：遵循规则，打破规则，抛弃规则。

引入敏捷的第一步是找到一个或多个团队，首先确保敏捷适合于所选择的团队，并在引入敏捷的几周前做好准备，例如确定敏捷教练、确保团队有一个会议室等，并让团队成员计划好第一周的工作。之后，我们可以引入敏捷，改进现有的团队了。

在引入敏捷实践的时候，如果不能立即做到全面敏捷，那么可以将部分敏捷实践融入到现有的流程中，比如一些优秀的敏捷实践：如每日计划、迭代、回顾会议、快速反馈、持续集成、测试驱动开发等等。

第三章 选择适合你的敏捷

敏捷能否帮助我们取得成功？怎样才能取得成功？只有能回答这个问题的时候，才能知道敏捷是否适合你的团队。同时，敏捷对于不同的团队，即使是同一公司中不同的团队，起到的效果可能也会截然不同。究其原因，是由于团队并不都处在同一“区域”，而导致处于不同“区域”的团队具备不同的流畅度。

敏捷流畅度模型对这个“区域”进行了划分，其共包含四个区域：

专注区，专注于商业结果。不同职能的成员作为一个团队工作，共同承担责任，核心目标是发布最有价值的功能。

交付区，专注于交付流畅度，团队成员通过卓越的技术来降低因频繁变化对代码质量所造成的影响，并减少或消除变化过程中的浪费。

优化区，专注于业务探索和开发新的市场价值，通过引入业务经验丰富的专家来不断优化产品计划，以实现尽可能多的价值，进而在竞争中获取胜利。

加强区，通过提炼团队集体的能力，推动于从单团队的敏捷向更大规模的组织敏捷的改进。

有意识地对敏捷进行选择性投资，需仔细考虑每个区域。每个区域都有其成本与收益，但无论选择哪一个区域，都要同时投资学习它的所有实践，这样后面几个区域的发展与实践才会变得更有顺利、更有效。

第四章 投资于敏捷

对敏捷进行投资非常重要。有效的导入敏捷需要改变团队过往发展中所受到的约束，在组织结构、系统和行为上做出真正的且有意义的改变。这些投资时多方面的，例如，获得发起人与利益相关者的认同，建立跨职能的全功能团队，为团队配备一个教练，接受1-4个月内可能得业绩下滑，将团队的组织权利移交给团队，替换项目治理方式等等。

变化通常都带有破坏性，而新的模式需要时间来学习，这导致了引入敏捷会是团队在一开始慢下来。根据经验一开始会有10%-20%业绩下降，当团队熟练的掌握了敏捷技能后，表现就会变得比之前更好。这个过程中会给团队带来一定程度的挫败感，令团队成员沮丧。此时，最有效的方式是投资团队一个专业的敏捷教练来指导每个团队，通过金钱换取时间，虽然不能完全避免绩效下滑，但这个时间会变得更短，也不会那么严重。

建立跨职能的团队并为团队寻找一个“团队空间”，都是一种有效的投资。可能在导入敏捷的过程中，无法获取全部所提及的投资，此时也可以尝试找一些替代方案，如在组织中选取一个具有敏捷意识和少量敏捷知识的人来承担敏捷教练，但这么做仍会让效果大打折扣。

第五章 投资于变化

变化是具有破坏性的，引入敏捷也不例外。它的破坏性究竟多大，取决于有多少团队受到影响，以及你对变化的管理程度。萨蒂尔变革模型将变化分为了五个阶段：旧的现状、阻力、混乱、融合、新的现状，它们也适用于敏捷的情况。

在大规模的变化中，适当的变革管理不能防止所有的干扰，但可以适当减少干扰。而改变也区分Kaizen（持续改进）和Kaikaku（变革性的变化），它们分别适用于不同的流畅度区域。

敏捷需要管理层的支持，如果没有管理层的支持，团队的敏捷实践和组织的非敏捷文化之间的不匹配将导致持续的摩擦。敏捷以人为本，所以你需要试点团队同意来尝试敏捷。同时，把利益相关者当作可信赖的伙伴，让他们知道你期望他们能够成功。

第六章 规模化敏捷

在现实的工作中，组织通常都是大规模的，少的通常三五十人，多个甚至数千人。这些成员会分布在不同的产品中心里，为一个共同的企业业务目标而贡献力量。在规模化得过程中，敏捷就变得尤为重要。

提升敏捷流畅度。很多时候，组织试图扩大敏捷的规模，而实际上却没有敏捷的能力。他们在规模化敏捷方面投入了大量的时间和金钱，而没有投资于团队的流畅度或组织能力。这种做法永远都不会奏效。此时，需要提升组织能力、教练能力、团队产能，以实现组织大规模敏捷。

规模化产品协作。规模化组织中，每个团队并非是完全独立工作的，所以还需要一种协调团队工作的方法。理清团队之间的相互依赖关系，并弄清楚如何管理这些依赖关系之间存在的问题。此处通常有横向扩展与纵向扩展两种方法。

第七章 团队合作

全功能团队，意味着团队拥有交付所需要的所有角色与技能。不仅仅是编程技能，还有人际关系技能、艺术性技能、技术技能。同时，团队成员随着个人技能的拓宽，在团队中不断做出贡献，提升团队的工作效果。

敏捷团队使用团队空间来直接沟通。在这个团队空间里，团队在一起工作和协作。敏捷团队包括领域专家和团队中的现场客户，当程序员需要了解该怎么做时，他们会直接与现场的客户交谈。

构建心理安全的团队，有助于提升团队的整体效能。安全并不意味着团队没有冲突，它的意思恰恰相反。它意味着团队中的每个人都能够表达自己的观点，而不用担心受到报复或被贬低。

团队是由一群人组成的，他们相互依赖以完成一个共同的目标。这种相互依赖性是团队的标志，是使团队能够成功的原因，也是区分好团队与坏团队的重要指标。

充满活力是保持工作节奏，以最好、最有效的方式工作的秘诀。在工作实践中我们认识到，尽管专业人员在困难的情况下也能做得很好，但他们在精力充沛和有动力的情况下，会将工作做得最好，最富有成效。

第八章 计划

尽管博弈听起来有点像娱乐项目，但并非如此。计划与博弈可以帮助我们制定最优计划且贡献大量信息，计划与博弈的目标是将团队集中在能提供最佳投资回报的工作上。

故事是用来计划的，是计划与博弈活动中的棋子。故事是一个提醒，提醒我们谈论团队需要做的事情。在实践中，故事被写在索引卡片上或是虚拟系统中的卡片上，这样团队成员们可以拿起它们、移动它们、并且谈论如何把它们安排进计划中。

计划是为了成功。敏捷基于价值增量制定计划，通过将增量切片成合适的大小并进行分批发布。 尽早发布、持续发布等原则的运用，大大提高了交付速度，以更加高效地增加价值。与其说“做这个，然后做这个，再而做那个”，不如制定一个可视化计划，并在行动中调整计划。可视化计划就是帮助做这件事情的，它是团队实现目标的关键。

在团队开展工作的同时，通过并行的方式及增量方法处理客户的需求，而不是设定一个固定的需求收集阶段。这将会使工作更容易开展，并确保团队成员不必等到需求都分析完成后再开始工作。同时，在敏捷团队中代表客户、用户和商业利益的团队成员，负责选择故事并确定优先级，他们肩负着掌控团队工作价值的重大责任。

第九章 自主权

产能就像“昨天的天气”，用于预测下一次迭代中可以包含的内容。当团队未能完成计划时，其产能值就会下降；当团队有充裕的时间可以边交付、边优化的时候，产能会增加。

站会的目的是协助团队成员协调工作，也是团队成员进行同步的一种方式。每日站会的形式很简单，在每天固定的时间整个团队举行一次5-10分钟的简短会议。团队的工作区就像开发工作的座舱。正如飞行员围绕着自己驾驶飞机所提供需的信息一样，使用信息丰富的工作空间为团队成员提供指导工作所需的信息。

仿真模型是为了交流，而不是为了证明软件工作正常。其目的是在任务计划期间，查看故事并确定是否存在开发人员可能误解的细节。同时，一个完整的故事不是一堆未经整合、未经测试的代码，它应该是已经准备好且可以发布的。

第十章 职责

无论在交付软件方面有多有效，如果没有获取利益相关者和赞助者的善意，都会遇到麻烦。利益相关者需要知道这项工作需要多长时间，他们需要规划预算并与第三方协调。为了建立信任并表现出责任感，敏捷团队需要预测何时发布。通常，作出这些预测通常被称为估算。

敏捷团队做好工作的关键是不断地获取反馈。团队通过演示向关键利益相关者展示团队最近完成的工作，并让利益相关者自己尝试使用软件，这是一种有效的获取反馈的方式。

敏捷的路线地图涵盖了团队共享其进度和计划信息的各种方式。团队提供的路线图类型取决于所在组织的治理方法。敏捷团队的管理者管理的是工作系统，而不是团队中具体某个人的工作。他们为团队的成功做好准备，引导并建立高效的团队环境，使每个成员在没有明确管理层参与的情况下能做出正确选择。

第十一章 改进

回顾：团队的回顾活动有很多种类型，迭代回顾是最常见的一种。它实际上是一种非常简单、有趣的的团队协作工作坊。通过一些非常巧妙的设计使团队每一位成员能够心理安全地分享他们过去这段时间收获的经验和意见，开诚布公地说出团队中存在的具体问题并给出建议，帮助团队持续改进。

团队动力：团队并不只是一群人。一个团队的建立往往需要树立共同的目标愿景、统一的价值观、约束一起做事情的方式方法。这是一个专业且循序渐进的过程。我们在团队中建立“共享领导力”和识别可能会对团队健康产生深远影响的“有害行为”。

消除障碍：“无常”是生活的常态，每个人时刻都会遇到各式各样、或大或小的障碍，对团队而言更是如此。对这些障碍的“识别”、“区分”、“定义”是妥善应对的关键。“圆圈和汤”这一形象有趣的思维方法可以帮助我们快速识别哪些是团队可以控制的障碍，哪些是可以影响的，哪些是既不能控制也无法影响的，进而快速采取合适的应对策略。

第十二章 协作

代码集体所有制：读过《凤凰项目》的朋友都知道团队的明星员工劳伦特实际上是团队的瓶颈。“以团队的代码为荣”或者“对团队的代码负责”会给团队省去很多不必要的摩擦。更为重要的是，当你意识到你面对的困难是自己难以应对时，请放心“下坠”，你的团队会“接住你”。

结对编程：结对编程来自《极限编程》，是实现代码集体所有制的实践之一，编程是知识性工作，思考的时间远大于敲键盘的时间，特别是有了AI的加持之后，这两个活动的比值甚至会到无穷大。

集体编程：和结对编程类似，只不过这种实践更彻底一些。虽然不是所有的场景都适合，但就我们的实践来看，在建立团队标准和编码共识的时候它是非常有效的。

统一语言：最初了解到“统一语言”的概念是在《领域驱动设计》。语言是人类最伟大的发明，作为一种粘合剂将不同背景，不同能力甚至不同文化的人粘合到一起。“统一语言”拥有类似的能力，软件的开发是一种多领域知识碰撞的创造过程，统一语言让这些不同的知识载体可以实现良好协作。

第十三章 开发

自动化的程度往往决定了团队和个人的工作效率，“零摩擦”通过场景化的方式向我们展示了“自动化”给软件研发准备阶段带来的不可思议的效率提升。而“持续集成”以自动化为基础，在团队中建立起与之配套的协作与工程实践，可以消除部分开发过程中由“人的因素”带来的信息混乱。

“测试驱动开发”对程序员而言是“稳稳的幸福”，我们听过对测试驱动开发最恰当的解读是“从一个成功”到“另一个成功”。

质量与软件交付与团队中的每个人息息相关，“快速、可靠测试”是关于质量保证的基础，强调了需要工程师关注的测试策略与工具。

重构是一项广为人知的体系化的优化代码的实践：“在不改变代码外在行为的基础上，对软件内部结构调整，提高其可理解性，降低其修改成本”。

实验方案——Spike，在工作场景中我并不会翻译它，这个词本身是一个隐喻，具备一些需要传递的精神和含义：本意是攀岩活动中在墙壁上钉钉子的活动，敏捷实践中指代进行小范围的探索性实验。

第十四章 设计

在软件开发过程中，渐进式设计、简单设计和反思性设计是非常重要的设计方法。它们可以帮助开发人员创建高质量、可维护、易于扩展和可靠的软件。这些设计方法在软件开发过程中具有非常重要的作用，可以帮助开发人员创建出优秀的软件。

渐进式设计是一种通过一系列小的改变，而不是一次性重构整个代码库的方法来改进代码。这种方法可以减少重构所需的时间和风险，同时保持代码库的稳定性和可维护性。通过渐进式重构，每个改变都可测试且不会破坏代码库的其他部分，从而确保代码的稳定性和可维护性。

简单设计原则是一种非常重要的设计方法。简单设计原则是保持代码的简洁性，避免过度设计和复杂性，同时确保代码的可扩展性和可维护性。这种设计方法可以帮助开发人员创建简单、可靠和易于维护的软件。

反思性设计是一种强调在设计软件时不断地反思和改进设计的方法。反思性设计包括识别代码中的问题和缺陷，然后通过重构来改进代码。反思性设计的目标是通过不断地反思和改进代码设计来提高代码质量，同时提高开发效率和代码可维护性。

第十五章 DevOps

面向运维构建的目标是使应用程序更易于部署和维护。构建应该创建一个可以在任何环境中运行的二进制文件，这个文件应该是独立的、不依赖于任何特定的环境变量或配置。在构建过程中应该使用安全的编译器和库，以防止代码注入攻击。容器化部署可以使应用程序更易于部署和管理。

特征标志是一种管理应用程序特性的方法，在需要添加或删除功能时，只需要在代码中添加或删除一个特征标志。特征标志应该像代码一样受到版本控制的管理，同时应该使用配置管理工具来管理特征标志的状态。

构建和测试应该自动化，以减少人为错误；使用持续集成来确保代码的一致性和可靠性；使用持续交付来确保应用程序的部署和维护。

第十六章 质量

团队要进一步推进流畅性交付，需要进行敏捷实验和分析。团队采用建设-度量-学习-实践的方法，并探索如何建立自主团队、学习新的方法和工具，以实现更高效的生产力。实现流畅交付可以极大地提高生产率和减少缺陷，这是团队追求的目标之一。

团队需要与内部和外部利益相关者合作，共同实现业务目标。团队还需探讨如何为客户和市场创造新的商业机会。敏捷实验和事故分析的重要性，是团队不断推进流畅性的关键。

事故分析可以帮助团队确定导致问题的根本原因，并制定相应的解决方案。事故分析的步骤包括收集数据和证据、确定问题、找出根本原因、制定解决方案、实施解决方案。在事故分析过程中，团队需要保持开放的心态，尽可能多地收集信息和证据，并积极探索根本原因及解决方案。

第十七章 自主性

优化流畅性是指通过打通组织的上下游， 赋予组织对于限制条件的决策权、自主权使团队可以更加流畅的交付。这不是因为它很难，而是因为大多数组织还没有为支持小团队的自主做好准备。

经过优化的团队拥有真正的业务权威和专业知识，并让团队对他们的财务和产品计划全权负责。团队需要有做好决策的能力，有些组织忽略了团队的业务潜能，他们指派了一个产品经理每周只能在项目上跟进几个小时，或者指定一位没有产品决策权的“所有者”。这些组织遭遇了最糟糕的结果：1、产品所有者被分散得太细， 2、没有决策权。

第十八章 探索

通过有效的验证性学习来发现客户需求和市场机会的重要性，以及建立灵活的计划和增量，才可以适应不断变化的市场需求。例如：验证性学习必须基于真实的客户和成本；学习和选择是优化团队的重要价值，特别是在产品创新的早期阶段；而选项思维和建立“安全”增量是管理风险的有效技术。

优化团队需要以客户为中心，始终关注客户需求和市场机会，通过验证性学习和灵活的计划和增量来实现产品创新和开发。这需要团队成员具有开放的心态，愿意不断学习和适应变化的市场需求；同时，需要建立有效的沟通机制，与客户和利益相关者保持紧密联系，不断收集反馈和建议，并及时调整计划和策略。只有这样，优化团队才能在竞争激烈的市场中脱颖而出，创造出有价值的产品，并取得商业成功。

第十九章 走向未来

敏捷开发是一个不断学习、实验和改进的过程，从“尝试敏捷”到“投资敏捷”到“推广敏捷”再到“实践敏捷”。本书带着大家一起走过了这次敏捷之旅，但实践只是一个起点。

一旦理解，就把它变成自己的实践吧：尽情实验替代方案，寻找新的想法。随着这些实践得心应手，尝试打破规则，看看会发生什么。你会更深入地了解到这些规则存在的原因以及它们的限制和边界。

随着时间的推移，流程和经验的不断积累，惯例和原则将变得不再重要。当做正确的事情是一个被本能和直觉驱使的习惯时，就是时候把规则和原则抛在后面了。怎么称呼它并不重要，当直觉带来了伟大的软件，为有价值的目标服务，智慧激励了新生代的团队，你就掌握了敏捷开发的艺术。

敏捷开发已经成为软件开发领域中的主流。它已经成为现代系统开发和数字化转型的核心，为项目和组织带来了更好的透明度、更合理的迭代过程、更快的反馈和更好的变更管理。敏捷开发可以帮助开发人员更好地了解用户需求，并及时响应用户反馈，从而提供更好的交互服务。

在现代软件开发中，敏捷开发已经成为必不可少的技能和工具。越来越多的企业和团队已经意识到敏捷开发在提高效率、降低成本、增强竞争力等方面的重要性。在数字化时代，敏捷开发已经成为企业数字化转型的关键技能之一。

已经有许多敏捷开发的实践帮助团队在效率至上的时代中脱颖而出，赢得了先机。借助敏捷的实践，这些团队的效率得到了质的飞跃，成为了业内的佼佼者。如今，许多企业已经采用敏捷开发方法，提高自身的效率和竞争力。敏捷开发已经成为一个行业标准，不仅仅是软件开发，更是一种文化和思想。

同时，随着数字化时代的到来，企业和团队需要更加敏捷、灵活地应对市场和业务的变化。大规模数字化敏捷转型是一个必然趋势，已经成为企业数字化转型的重要组成部分。

在大规模数字化敏捷转型的浪潮中，企业和团队需要不断学习和实践敏捷开发的方法和工具，包括Scrum、Kanban、XP等。同时，企业和团队需要将敏捷开发的理念和文化贯穿到整个组织中，打造一个敏捷的企业文化和团队氛围。在这个过程中，企业和团队需要重视团队建设和人才培养，吸引和培养具备敏捷思维和实践经验的人才，建立高效协作的团队和文化。此外，企业还需要建立敏捷的组织架构和流程，打破传统的职能壁垒和组织结构，实现团队的快速响应和决策。

这就需要企业和团队具备持续的学习和实践的能力，不断提高自身的敏捷性和适应性。同时，企业和团队需要注重用户需求和体验，积极探索和应用新技术和新模式，不断创新和优化业务流程和产品服务，提升用户满意度和市场竞争力。

《敏捷的艺术》这本书不仅仅是一本敏捷开发的指南，更是一本关于软件开发和项目管理的实用手册。它深入浅出地解释了敏捷的原理和实践，并提供了许多实际案例，帮助读者理解如何在实际项目中应用敏捷方法。通过阅读这本书，读者可以更好地了解敏捷开发的理念、价值以及如何在团队中实践敏捷开发。此外，这本书还提供了许多实用工具和技巧，帮助读者提高团队的效率和协作能力。除此之外，还介绍了如何帮助团队更好地领会用户需求，提高用户满意度。

我相信，更多的人可以通过这本书认识敏捷、践行敏捷、理解敏捷、优化敏捷。敏捷开发已经成为一个不可忽视的技能和思想，企业和团队需要不断地学习和实践，在数字化时代中保持竞争力和创新力。