推荐序一
《敏捷开发的艺术》第一版发行于2009年，一经发行便成为了众多软件从业者在工作、生活中随手可及的瑰宝。作为软件从业者的我们，都曾为这本书着迷。当华章的编辑老师推荐我们编译这本书第二版的时候，我们欣然答应。
可以确信的是，《敏捷开发的艺术》第二版依旧精彩，它将现代软件交付浓缩到一本简短、可读并且有趣的书中。对于刚接触迭代交付的人来说，它针对敏捷实践提出了精彩的概述；对于迷失在过度工程化的“大规模敏捷”流程中的团队来说，它提供了逃离此“地狱”的好主意。我们在翻译的过程中也融入了很多我们的见解和实践，我们相信这本书会继续帮助数以百万计的开发者改善软件交付方式。
如何深入思考敏捷思想在现代数字化时代所扮演的角色？
2000年初，敏捷刚进入中国的时候，国内的软件从业者对敏捷还是懵懂的状态。十多年来，大家对敏捷的理解日益加深，都意识到传统开发模式带来的问题，不断剖析着瀑布模型的适应局限以及给业务、IT部门带来的痛点。研发团队越来越重视对业务的响应速度。大多数企业的研发团队已经理解实施敏捷的益处，很自然地接受并开始践行敏捷：
引入敏捷的管理实践，比如需求管理、用户故事、进行迭代管理、制定发布计划
引入敏捷的工程实践，比如结对编程、代码管理、自动化测试、持续集成、持续发布等
引入相应的团队工具，比如看板、线上协作、知识管理与协同、事务跟踪等
然而时至今日，在与很多企业的CIO、CTO、以及IT部门的各级主管交流时，我依然可以看到：大多数企业IT部门的职能还停留在“业务支持”的程度，是为业务部门提供IT系统支持的组织。这也造成了传统企业中IT部门的员工，更多的是承担甲方项目经理的角色。IT部门的员工在业务或专业能力上很难得到持续的积累和沉淀，整个研发团队的生产力和创新氛围也受到影响。与此同时，IT部门面前有成百上千个需要用⾼昂的成本进⾏支持和维护的遗留系统，尽管他们愿意响应快速变化的市场需求，但在项目周期与成本压力面前，却又显得力不从心。
《敏捷开发的艺术》犹如一本圣经，将敏捷软件开发的理论与实践娓娓道来，切实地帮助我们分析并解决上述问题。在今天，敏捷思想在业内广受尊重，客户也常常期望我们助其变得敏捷。 目前的挑战是软件世界被“伪”敏捷所淹没，许多公司认为完成 Scrum/SAFe，数字化工作就结束了。殊不知我们现在所说的敏捷，早已不限于敏捷研发和敏捷项目管理。
事实上，敏捷的概念已经扩散到组织的每个领域，而数字化时代需要的是打造敏捷的组织实践。我们认为，“数字变革”是这一变化的重要推动力。人们意识到软件已经成为商业活动的重要部分，技术再只作为成本削减的工具。更为重要的是，业务与科技之间的整体关系将被重新定向——敏捷思想是业务数字重定向的核心，在数字化转型中起到重要作用。在此基础上，咨询顾问通过建立统一的流程、打造共享的技术平台、建立创新型的组织文化来不断推进业务与IT的深度融合。
数字化转型有一个非常重要的目的，就是让客户和最终的生产者距离更近，提升效率，进而降低客户和企业内部交易成本。转型的关键在于拉通客户端的需求和企业内部生产运营，这就需要企业内部各个部门的快速协作与灵活变通，这些工作是最难的。作为数字化转型顾问和大型研发团队的领导者，我很庆幸看到本书的问世，书中的很多实践、工具、流程以及敏捷开发的艺术正在帮助我们推进数字化转型。
建议大家静下心来，阅读这样一本好书。祝阅读愉快！
万学凡 凯捷中国副总裁，数字化团队负责人
推荐序二
本书书名包含「艺术」一词，但实际上更是一本详尽的手册，它阐述了敏捷研发的各个方面：从文化、管理、团队合作到开发和设计的原则与质量，以及持续集成等内容，全面地讲明了要在敏捷开发中取得成功，我们需要关注的核心问题。
作为知乎的CTO，我一直在追寻卓越的软件开发实践，本书让我看到了知乎实践在书中的映射。它如同一盏明灯，照亮了我们前行的道路，使我们更加坚信自己前进的方向。作者在本书中深入浅出地探讨了敏捷开发的核心理念，强调了文化与价值观的重要性。他们指出，敏捷开发不仅仅是一套流程，更是一种思维方式和团队的共同理念——文化才是真正支撑和推动敏捷开发的根基。在我们的实践中，这种文化变革同样至关重要，只有当每一位团队成员都以相同的敏捷精神对待工作，才能真正发挥敏捷方法的威力。
书中对敏捷团队合作的描述也令我深感共鸣。团队是软件开发的核心，而敏捷团队则更加高效和灵活。作者强调了协作、自组织和跨功能的重要性，这也与我们在知乎的实践紧密贴合。唯有于此，在追求创新和持续发展的过程中，每个团队成员的才华和贡献才能得到最大程度的尊重和发挥。当然，书中所论及的不仅仅是团队合作，作者更是剖析了敏捷开发的各个环节，每个章节都体现了大师们对于软件研发的精湛理解。这些原则和实践对于保障软件的高质量和稳定性至关重要，也正是我们这些软件从业者一直追求的目标。 在本书中，我找到了很多知乎团队所需要的启示和指引，每一页都散发着智慧与洞见，每一章都激励着我们更加努力地追求卓越。这是一本我们值得拥有的书籍，我相信它也将成为将敏捷组织作为前行目标的团队必备指南。
这本书第一版在十多年前就已发行，粉丝众多。很多在那个年代还很超前的理念，在今天已经成为了行业里普遍认同的最佳实践。随着大模型等新兴AI 技术的演变，我们也正在思考如何将先进的技术引入到我们的敏捷实践中，期待看到作者和译者在未来的著作中有更多对于这些方向的实践和思考。让我们一起努力。
知乎CTO兼面壁智能CEO 李大海
推荐序三
开发软件产品是为了解决业务问题，特别是复杂的业务问题。我们为什么需要敏捷？因为世界变化太快，无论是外部的市场环境、消费者习惯、行业竞争，还是企业自己的业务、战略、组织、流程，随时随地都在发生着变化，这就造成了业务问题的不稳定、不确定、复杂和模糊。要解决复杂多变的业务问题，需要基于对业务和用户的深刻洞察，快速测试与验证假设，持续不断地迭代解决方案，这正是敏捷。
企业管理追求确定性，特别是财务相关流程，比如营收预测和预算管理。因此，许多企业管理者习惯于使用瀑布式的项目管理来开发软件产品。这种长期的瀑布式项目管理是基于确定性的，认为业务需求和方案设计在项目计划阶段就可以确认清楚，在项目执行阶段只需要精确管理建设过程，就像盖房子一样，由此就可以保证成功。然而现实情况却并非如此，仅在项目建设阶段，许多业务需求就已经发生了显著变化；项目组则往往会极力去管控这些变更，希望按照原定计划上线。在经历了千辛万苦后，项目终于成功上线了，然而仍然无法解决原本希望解决的业务问题——没有能够创造业务价值，项目实际上是失败的。
企业要想从传统的管理模式转变为敏捷，需要一场变革，涉及到组织、流程、人员和工具等方方面面，充满了各种挑战。本书为我们提供了全面的帮助——这本敏捷工具书面向的读者包括企业管理者、敏捷团队成员以及所有与敏捷团队合作的同仁。作为企业管理者，可以了解敏捷理念和运作方式，以及如何引入敏捷或者改善公司现有的敏捷实践；作为敏捷团队成员，可以学习如何持续改善团队合作、流程和工程实践，持续提升交付质量与创造价值。因为本书涵盖的话题十分广泛，作者无法尽述所有方面，读者可以关注书中的延伸阅读，对感兴趣的主题进一步学习；与此同时，译者在每一章节都加入了导读，其中的专业见解和洞察也让本书更具价值。
认知升级，知行合一需要持续地学习和新鲜思想的输入。感谢这样一本好书，祝所有思考者与践行者好运。
王泳帅 宝洁大中华区信息技术部CTO
推荐序四
今天的软件行业和十多年前相比发生了天翻地覆的变化，敏捷开发已是软件领域中的主流，俨然成为现代系统开发和数字化转型的核心。软件行业的创新也从未停止，ChatGPT不仅替代人工用于软件测试，提供运维支持，甚至还能直接编写代码。象牙塔里追求优雅代码的软件工程师不断思考着如何为项目和组织带来更高的透明度，追求更合理的迭代过程和更快的反馈。
在我所处的团队中，我们正在不断学习和实践敏捷开发的方法和工具。同时，我们意识到团队需要将敏捷开发的理念和文化贯穿到整个组织中，这是一个知易行难的过程。我们重视团队建设和人才培养，致力于建设高效协作的团队文化。此外，我们建立了敏捷的组织架构和流程，通过技术打破传统的职能壁垒，以实现团队的快速响应。这需要我们具备持续学习和实践的能力，不断提高自身的敏捷性，积极探索和应用新技术，不断创新、优化业务流程和产品服务以提升用户满意度。这是本书为我带来的最大启示。
浅白中见深刻，不显山露水却又笔墨横姿，这是本书的风格。要掌握敏捷，意味着超越我们所列出的实践方法。敏捷开发与具体环境的关系十分紧密，不可能有一种方法完全适合所有的情况。敏捷开发也十分精妙，任何一本书都不可能教会你怎样精通它，精通来自经验，也来自于对一种选择所能引发的后果有直觉的理解。
本书在讲述敏捷原理和实践同时，提供了许多实际案例，帮助读者理解如何在实际项目中应用敏捷方法。没有任何过程是完美的。每一种方法都有一些潜在的需要改进的地方。我们的目标是消除位于团队和项目成功之间的每一道障碍，并且当条件改变时随时调整我们的方法以适应新的情况。这就是敏捷。
感谢译者，为我们带来了一本经典好书。要掌握敏捷开发的艺术，我们需要经验和感悟。经验能使我们看到敏捷方法如何起作用。感悟则能帮我们理解经验。经验和感悟，永无止境地连接在一起，这是通向精通之路。与各位共勉。
吉利汽车数字化中心CTO 郑金伟
推荐语
软件工程是一门在危机中诞生的学科。每一个软件从业者，从程序员到架构师，从运维人员到企业高管，都有着被各种deadline和bug所支配的焦虑经历。作为一种价值观和开发者文化，敏捷以独特的形式为软件从业者开启了一条在效率和质量间取得平衡的途径。与初版相比，本书第二版内容上更加充实，不仅体现了近年来敏捷实践的最新进展，而且其编排体例和行文风格也能帮助读者快速定位自己感兴趣的观点和内容。无论你希望掌握敏捷的艺术，还是想成为一名熟悉敏捷工具的实用主义者，这本书都能让你开卷有益。
华中科技大学软件学院教授 沈刚
敏捷开发诞生三十年以来，为什么变得越来越重要？因为无论是企业外部市场环境、行业竞争，还是内部的战略、组织，都充满了越来越多的易变性、不确定性、复杂性和模糊性。需要以人为核心、迭代式、增量式的软件开发方法，强调团队的合作、沟通和技术能力，快速响应变化和需求，这是敏捷开发的本质。
本书详细介绍了敏捷方法的各个环节，包括需求分析、计划制定、开发流程、测试和部署等，让读者全面了解敏捷方法的理念、流程、工具和技术；提供了许多实用工具和技巧，帮助读者在实际项目中更好地应用敏捷方法，提高软件开发的效率和质量。此外，作者还深入探讨了敏捷方法的哲学和思考方式，让读者更好地理解敏捷开发的本质和核心理念。
本书不仅适合开发人员和项目经理，也适合想要了解敏捷开发的企业领导和业务人员。通过阅读本书，读者可以更好地了解敏捷开发的理念和实践，为企业的数字化转型提供有力的支持。
小鱼易连CEO、清华大学EMBA 王飞
在敏捷宣言诞生的二十年内，对于敏捷的愿景和方法，已经有很多出版物作出了诠释和解读。但知易行难， 在我们的工程团队与客户转型敏捷项目交付的过程中，对敏捷的理解和实践总有不同的认识与交付结果。是流于形式的工具和流程，还是忠实敏捷的精神，回归初心，重新关注宣言中的左项价值？项目实践中，这些冲突会一直在技术理念与商业利益的博弈中反复拉锯。
本书再版正是在这些冲突和流于形式的敏捷误区的基础之上，作者针对第一版落地方法的实践几乎都进行了重写。认真、客观地对敏捷在商业世界运行的多年经验进行了剖析和解读，专注于价值本身。同时分析了规模化敏捷失败的可能原因，以及与DevOps的结合应用，对敏捷方法在团队中的运用做出了详尽指导。作为团队管理者，毋庸置疑，本书为我们提供了一本最佳指南。
凯捷咨询云与人力资本管理服务线总经理 徐飞
君子不器，敏捷同样如此。从敏捷宣言发布以来的20多年时间，逐渐发展出来了很多流派、方法、实践，敏捷不应该像一个器具那样，只具有一种功能或只限于某种特定场景。在本书中，我们看到了敏捷本身与时俱进的变化，在演变的过程中不断完成自我迭代，更加具有实操性、更加关注业务价值，所以也越来越多地应用于不同领域、不同行业并取得成功。本书完全可以作为一位软件从业人员的案边书籍，当我们在研发过程中自认为对很多方法融会贯通的时候，建议再翻看本书，一招一式拆解一遍。不忘初心，我们都会有新的思考和成长。
OPPO软件IT部部长 裴哲
敏捷开发的艺术，书如其名。无论是敏捷团队的成员，还是工作在一线的管理者；无论是初识敏捷的新生，还是运用自如的老手，都值得一读。敏捷的本质是以客户价值为核心，不断拥抱变化以快速响应客户需求。如何界定价值，应该拥抱什么频率的变化， 以什么样的速度响应客户需求, 快速交付与质量保证如何平衡? 践行敏捷的我们或多或少会有类似的疑问。本书提供了丰富的最佳实践指南, 定能为我们答疑解惑。祝开卷有益。
宝洁信息技术研发总监 童熙
谈起敏捷开发，一百人眼中可能有一百种不尽相同的理解。做产研的同学如果说自己团队的交付不是敏捷的，感觉会被当成不入流的异类，但真正投身敏捷的诸位所经历的变革过程和酸甜苦辣唯有自己知晓。正如本书十五年后再版，回归初心，重申敏捷宣言和要解决的核心问题，提纲挈领的强调敏捷是一种投资以及敏捷本质上带来了组织价值交付方式的变革。
本书系统化地从团队合作基础开始，将我们都很“熟悉”的敏捷要素一一解读，融入15年间无数团队实践敏捷的得失体验。结构化的叙述，掷地有声的分享，让我们受益匪浅。其中的规模化敏捷，团队建设等章节更是让我感同身受。本书会给大家一个停下脚步，重新审视前行方向的契机。推荐阅读，与各位共勉。
阿迪达斯中国数字化中心高级总监 王博
距离本书第一版已超过十五年，对众多敏捷开发的从业者而言，它都是不可不读的经典。本次再版，既是在前作经典之上的延续，也是通过全面重写将这十几年来软件研发的发展历程娓娓道来。我强烈推荐这本敏捷开发的经典之作，建议我们都能沉下心来仔细研读，从中找到自己心中一直不断追寻的答案。
华为云应用平台部首席解决方案架构师 姚冬
本书的主要作者James Shore是敏捷开发早期的先驱者，开创了极限编程的先河；James与本书合作者之一的Diana Larsen共同创建了“敏捷流畅度模型”（Agile Fluency Model）。当我们翻开本书，受益于大师们镌写的经典，在字里行间中我们能够更深刻地理解敏捷实践，感受在践行企业敏捷转型过程中的包容与思辨。感谢这样一本好书，中国的敏捷实践者，加油！
荣庆物流信息技术部总监 刘永生
在软件开发的世界里敏捷早已不是一个新鲜词，但能够将敏捷做好的组织却并不多。本书从敏捷的起源、理论入手、再结合实践，深入浅出地探讨了如何践行敏捷，最大化组织与个人价值，从而推动整个企业的敏捷转型。对于软件从业者，本书亦是一本非常好工具手册，我们可以像查阅字典一样进行针对性地阅读，为我们答疑解惑。
默沙东中国IT产品总监 黄飞铭
数字化浪潮的推动下，所有企业都将从信息化进入到数字化，这必然导致软件开发的规模和复杂度继续提升，软件研发面临着“技术”以外的挑战将会成倍增加。在疫情后每一个技术管理者都在寻找如何降本增效，保持团队创新活力和效能的方案。我一直认为，敏捷软件研发为众多IT工作者提供了一种解决问题的优雅之道，本书中作者和译者深入浅出地解释了敏捷的原理、实践与案例，帮助读者理解在实际项目中应用敏捷的思想与方法，帮助技术管理者在数字化转型的今天推动整个企业的敏捷转型。见贤思齐，我会向TGO鲲鹏学社的小伙伴们推荐本书，让我们一起成长。
TGO北京董事会董事、清华大学EMBA 王磊
当我们正苦恼着该如何拥抱敏捷，并期待藉由敏捷之道来推动数字化转型的时候，本书已将其宝贵的经验与扎实的工具组合集结成册，从基础入门到案例拆解、从思维启蒙到追求卓越，以高效、深刻的方式引导着在VUCA时代生存的每一个团队与企业。感谢译者为我们带来这样一本实用又精彩的好书，也非常庆幸在追求敏捷的道路上有这样一本好书相伴。打开它，让我们一起敏捷吧！
金融业首席信息官 冯胜雄
我非常高兴看到《敏捷开发的艺术》第二版的翻译出版。相比第一版，过去的十多年里，敏捷开发在软件领域得到了更多实践，并取得了更大的发展。它不仅仅是一本关于敏捷开发的操作指南，更是一本带领读者探索软件开发艺术的良师益友。
无论你是软件开发新手还是资深从业者，这本书都将为你和你的团队提供宝贵的知识和实践经验。在此感谢译者团队，你们长期工作在中国敏捷开发实践的第一线。正是这些常年实践的积累，使你们能够深刻理解敏捷开发的真谛，并用最好的方式将其呈现给广大读者，使这本书成为一本既实用又易读的精美之作。
愿更多的读者通过这本书学习到敏捷开发的方法，领略敏捷开发的艺术，并在探寻敏捷之道的过程中有所收获。
极客邦科技副总裁 & TGO鲲鹏会总经理 杨攀
译者序
关于本书
本书第一版在2008年出版，当时敏捷的思想才刚刚开始在软件开发领域萌芽，许多人对敏捷的理解还停留在表面层次。如今，经过十多年的发展，敏捷已经成为了软件行业的主流方法。然而，敏捷的实践和理念仍在不断演变，和众多软件从业者一样，我们发现才刚刚开启敏捷开发这扇大门，走进这座艺术的殿堂。我们想，这正是这本著作再版的原因。
第二版中，作者詹姆斯·肖尔（James Shore）充分运用过去十余年的新工具、技术和经验教训，对第一版进行全面更新和升级。整合极限编程、Scrum、精益、DevOps等领域的最新理念，并结合其二十多年的敏捷实战经验，为敏捷的采用、计划、交付和管理提供有效建议。本次再版中，作者融入了大量精彩案例，并通过讲述各种故事，为读者提供全面、深入的敏捷实践视角。这与我们所在团队倡导的敏捷理念一致：敏捷不仅是一种开发方法，更是一种思维方式和价值观。
本书共分为四个部分，旨在帮助读者深入理解敏捷实践，提升敏捷项目的价值和成功率。第一部分讲述敏捷的本质和追求真正的敏捷实践，通过敏捷力的选择、投资和扩展，引导组织实现敏捷转型；第二部分关注价值导向的敏捷项目，围绕团队合作与持续改善，确保项目始终关注价值创造；第三部分详述敏捷实践中协同合作、开发、设计、DevOps和质量的重要性，旨在提高软件交付的可靠性和客户满意度；第四部分探讨敏捷实践在自主性、探索和展望未来方面的优化，指导团队更好地把握产品规划、预算和实验，以设计市场领先的软件产品。
关于翻译
作为凯捷数字化团队的成员，我们非常荣幸翻译并与您分享本书。与本书的原作者James Shore一样，我们不仅是软件开发者、敏捷教练，也积极参与社区的建设和推广。我们在团队中承担不同的职责；我们一起探讨软件开发的各个方面，包括敏捷开发、测试驱动开发、重构和持续集成等；我们坚信敏捷开发是一门艺术，它正推动着整个行业的发展。
凯捷中国数字化团队在端到端的产品与项目交付方面具有丰富实战经验，我们与作者一样都致力于敏捷实践，在翻译的过程中对于作者的观点和提供的故事，我们感同身受。然而，在翻译过程中我们也面临挑战和困难。首先，敏捷开发领域广泛且复杂，涵盖众多知识和实践。因此，我们在翻译过程中需仔细研究和理解每个概念及实践，并反思在团队敏捷实战中的应用，确保准确地翻译成中文。其次，我们在翻译过程中遇到了术语和概念的翻译问题，需要深入研究和讨论，以确保翻译的准确性和一致性。尽管过程中遇到困难，但我们始终保持高度热情和专注。
我们在每个章节的开始都加入了“译者导读”，这也是我们在阅读本书时的总结和归纳。我们希望读者在轻松的阅读中，能和我们一样从中悟出一些哲理。我们希望通过努力让更多的读者学习并分享书中的内容，以帮助更多数字化从业者从中受益，这是我们不变的初心。
感谢
感谢所有参与本书审校的人员，他们是田楮梦、王艳春、吕征达、孙笑怡、朱伟章、陈蕾、杜佳宇、肖博懿、张立、张明鑫。肖博懿负责了“译者导读”部分的整体设计，她的专业领读为本书带来了更多价值。感谢所有人的辛勤工作与无私付出。敏捷开发的一个重要特点是强调团队合作和持续交互。本书的翻译也是遵循了这样的合作模式，我们在一起紧密合作，不断获取反馈，并对译文作出调整。这种持续的交互和反馈机制，帮助我们顺利完成本书的翻译。
敏捷开发是一种高效、灵活和可持续的软件开发方法，它已经成为了当今软件开发中不可或缺的一部分；敏捷开发更是一门艺术，为推动软件开发行业的进步和发展做出了重要贡献。希望各位喜欢我们为大家精心准备的好书。祝开卷有益。
凯捷中国数字化团队 吴衍刚、宋俊毅，梁凌锐、姚文杰
译者导读
第一章 什么是敏捷
敏捷思想起源于20世纪90年代“软件危机”时期。当时，一些轻量级的软件开发方法引起了广泛关注。然而，《敏捷宣言》的诞生改变了这一局面，它定义了敏捷的三个要素：名称、价值和原则。
“敏捷开发方法是适应性的，而非预测性的；是面向人的，而非面向过程的。”这段话是对敏捷软件开发本质最好的解释之一。
敏捷之所以成功，是因为其关注点在于确保进展清晰可见，同时允许利益相关者在开发过程中进行纠正。敏捷之所以如此有效，是因为其包含并遵循其五个核心概念：以人为本、交付价值、消除浪费、追求技术卓越、改进流程。且人们在采纳敏捷理念的同时，能够根据自身情况进行调整和持续改进。
然而，很多个人和组织会陷入对于敏捷的“货物崇拜”陷阱之中，而这也可能导致敏捷的失败。尽管人们渴望敏捷所带来的好处，却往往缺乏对其背后的理念的深刻理解。即便理解了，他们也可能不愿意投入。
第二章 如何做到敏捷
要将敏捷思想转化成实际有效的敏捷团队，关键在于大量的实践。
通过大量的实践，团队可以将敏捷从理念的集合转化为切实可行的工作方式，融入到团队的日常实际操作中。在使用引入敏捷的过程中，掌握敏捷需要采用一系列特定的方法，而真正精通敏捷则需要经历这样一种演进过程：遵循规则，打破规则，抛弃规则，最终能够灵活地运用敏捷。
引入敏捷的首要步骤是选择一个或多个团队，确保敏捷方法适合这些团队，在引入敏捷前的准备阶段，需要做好准备工作，如选择合适的敏捷教练、为团队提供必要的资源，例如会议室，并协助团队成员规划好好第一周的工作。然后，逐步引入敏捷方法，对现有团队运作方式进行改进。
在引入敏捷实践时，如果无法一开始就全面实施敏捷，可以逐步将部分敏捷实践融入现有流程中。一些成功的敏捷实践包括每日计划、迭代开发、回顾会议、快速反馈、持续集成、测试驱动开发等。
第三章 选择适合你的敏捷
敏捷是否能帮助我们取得成功？如何实现成功？只有能回答这些问题，才能判断敏捷是否适合团队。此外，敏捷对不同团队，甚至是同一公司内的不同团队，效果可能也会截然不同。这些差异来源于团队所处的“区域”不同，导致流畅度不同。
敏捷流畅度模型将这一“区域”划分为四个部分：
专注区：关注与商业成果。跨职能成员共同合作，致力于发布最有价值的功能。
交付区：专注于流畅交付，通过优秀技术减少频繁变更对代码质量的影响，减少变更中的浪费。
优化区：专注于业务探索和市场价值开发，引入业务经验丰富的专家不断优化产品计划，取得竞争优势。
加强区：通过增强团队洞察力，推动从单团队敏捷向更大规模的组织敏捷的转变。
有意识地进行选择性的敏捷投资时，需要仔细权衡每个区域。每个区域都有成本与收益，但无论选择哪个，都需全面学习其实践，以确保后续区域的发展与实践更为顺利和有效。
第四章 投资于敏捷
对敏捷进行投资非常重要。有效地引入敏捷需要对团队过往的限制进行改变，在组织结构、系统和行为方面做出有意义的真正变革。这些投资领域广泛，包括获得发起人与利益相关者的认同、建立跨职能的全功能团队、为团队引入敏捷教练、接受可能在1-4个月内出现业绩下降、将权利下放至团队层面、转变项目治理方式等。
变革通常伴随着破坏，新模式需要时间来学习，所以刚开始引入敏捷时团队可能会放缓。根据经验，一开始的业绩可能会下滑10%-20%。然而，一但团队熟练掌握了敏捷技能，表现通常会超越以往。这一过程可能会引发团队的挫败感，成员们感到沮丧。此时，最有效的方法是聘请专业的敏捷教练来指导每个团队，通过金钱换取时间，虽然不能完全避免产能下滑，但时间会减少，程度也不会太严重。
在此过程中，团队需要从组织中获得以下重要投资：
建立跨职能的全功能团队
为团队配备敏捷教练
分配工作给团队而非个人
创建适合团队的“团队空间”
以有价值、非紧急且有学习机会的任务作为第一个目标
确保团队控制开发、构建、测试和发布过程
让团队对预算、计划和结果负责
采用敏捷管理模式取代部分管理模式
消除阻碍敏捷的人力资源政策
第五章 投资于变化
敏捷方法将帮助你的团队获取更大的成功。你已经知道哪些区域有最好的成本效益的权衡，并且已经确定了公司需要进行投资。那么，下面的三个步骤将帮助你实现目标。
首先，需要认识到变革是具有破坏性的，引入敏捷也不例外。变革的破坏性程度取决于有受影响的团队数量，以及对变革的管理程度。萨蒂尔变革模型可以有效的帮助你管理变革，它将变革分为了五个阶段：旧的现状、阻力、混乱、集成、新的现状。这个模型同样适用于引入敏捷方法的情况。
其次，对于大规模的变革，适当的变革管理尽管无法完全消除干扰，但可以在一定程度上减少干扰。同时，需要区分持续改进和变革性变化，以根据不同的流畅度区域采取不同方法。
最后，敏捷需要得到利益相关者的支持。如果缺乏管理层的支持，团队的敏捷实践和组织的非敏捷文化之间的不匹配将导致持续的摩擦。敏捷以人为本，因此进行敏捷尝试需要获得团队的认可。同时，将利益相关者视为可信赖的合作伙伴，让他们知道你期望他们能够成功。
第六章 规模化敏捷
在现实的工作中，组织通常都是大规模的，人数少则三五十人，多则数千人。这些成员分布在不同的产品中心，为共同的企业业务目标而做出贡献。在规模化的过程中，敏捷就变得尤为关键，体现在敏捷流畅度与产品协作两个方面：
敏捷流畅度是规模化敏捷的基础。许多组织试图扩大敏捷规模，却未具备实现敏捷的能力。他们在规模化方面投入了大量时间和资源，但忽视了团队流畅度和组织能力的投资。这样的方法往往无法取得成功。为了实现组织的大规模敏捷，需要提升以下三方的能力：
建立支持敏捷团队提升流畅度的组织能力；
提供解决规模化敏捷问题的教练能力；
实现安全稳定的团队扩展能力。
规模化产品协作。在规模化组织中，各团队并非完全独立工作，因此需要一种协调团队工作的方法。这需要明确团队之间的相互依赖关系，并解决可能存在的问题。通常有两种基本策略：
纵向扩展，旨在增加能够在没有瓶颈情况下协同工作的团队数量；
横向扩展，通过隔离团队的责任来消除瓶颈。
第七章 团队合作
最优秀的架构、需求和设计来自于自组织团队。跨职能、自组织团队是敏捷组织的基础 资源，也是敏捷的核心思想之一。
全功能、自组织团队是敏捷的精髓。团队中成员具备各种技能和角色，能够共同协作完成任务。全功能团队不仅包括编程技能，还涵盖人际关系、艺术、技术等多方面的技能。团队成员的多样技能能够持续提升团队的工作效率。
敏捷团队借助团队空间进行直接沟通和写作。团队在团队空间中紧密合作，包括领域专家和现场客户。程序员可以与现场客户交流，以确保理解任务要求。
构建心理安全的团队有助于提高整体效能。心理安全并不排出冲突，相反。它允许每个团队成员自由表达自己的观点，而不用担心受到打击和批评。
团队是相互依赖的成员组成，他们合作实现共同目标。这种相互依赖性是团队的特表，也是团队成功的关键，区分优秀团队与糟糕团队的重要指标。
保持充满活力是最佳、最高效工作的关键。虽然专业人士在困难的环境中也能表现出色，但在精力充沛、积极主动的情况下，他们会将工作做得更好，更富有成效。
第八章 计划
敏捷是适应性的，而非预测性的。敏捷与其他管理模式最显著的区别之一便是其计划方式。
敏捷计划是一个博弈过程，尽管博弈听起来有点像娱乐项目，但并非如此。计划与博弈有助于制定最优计划，并提供大量信息。计划与博弈的目标是将团队集中在能提供最佳投资回报的工作上。
用户故事是以客户为中心的小颗粒度价值单元，是计划与博弈活动中的关键要素。故事是一个提醒，提醒我们关注团队需要完成的任务。在实际实践中，故事可能写在索引卡片上或是虚拟系统的卡片上，团队成员可以拿起它们、移动它们，并探讨如何把它们安排进计划中。
计划的目的是为了获取成功。敏捷计划基于价值增量，将工作切片成适当大小并分批发布。通过 尽早发布、持续发布等原则，交付速度大幅提升，实现高效增加价值。与其固定地“做这个，然后做那个”，不如制定可视化计划，在行动中不断调整。可视化计划对此有所帮助，是团队实现目标的关键。
在团队工作的同时，通过并行和增量式方法处理客户需求，避免设定一个固定的需求收集阶段。这有助于化简工作流程，确保团队成员无需等待需求分析完成后才开始工作。同时，敏捷团队中代表客户、用户和商业利益的成员负责选择故事、设定优先级，他们对掌控团队工作价值承担着重要责任。
第九章 所有权
敏捷团队拥有自主权，他们自行决定何事需要完成、如何分解，以及由团队中的谁来承担工作。这是基于敏捷的一个基本原则：最了解工作需求的人最有资格决定细节，所有权不仅仅是控制权，还包括责任。当团队拥有工作的所有权时，他们也承担完成工作的责任。以下是掌握工作并完成工作的一些实践方法：
通过任务规划，团队将故事分解为任务并确定如何完成。
预测产能，以便在下一次迭代中决定可以完成的内容。未完成计划时，产能就会下降；有充裕的时间进行交付和优化时，产能会增加。
采用柔性方法，提升能力，使团队能够做出可靠的短期承诺。
通过站会协助团队成员协调工作，每日在固定的时间进行5-10分钟的简短会议，以实现团队成员的同步。。
利用团队的工作空间，类似于飞行员座舱，提供所需的信息来指导工作。
使用演示模型用于交流，目的是在任务计划期间检查故事，确定是否存在开发人员可能误解的细节。
完整的故事不是一堆未经整合和未经测试的代码，而是准备好且可以发布的状态。
第十章 职责
在敏捷团队自我管理工作和计划的情况下，组织仍然需要确保团队在正确的方向上进行工作。尽管敏捷团队拥有资源、信息和人员，但他们需要向组织证明他们在适当的领域投入了时间和金钱，以及对组织成果负责。
尽管敏捷方法可能在软件交付方面非常有效，但如果没有获得利益相关者和赞助者的支持，仍可能会遇到问题。利益相关者需要了解项目所需时间，规划预算并与第三方协调。敏捷团队需要预测何时发布，以建立信任和责任感。这种预测过程被称为估算。
持续获取反馈是敏捷团队做好工作的关键。团队通过演示展示团队最近完成的工作，让利益相关者自己尝试使用软件并提供反馈，这是一种获取反馈的有效途径。
敏捷的路线图涵盖了团队共享进度和计划信息的多种方式，具体取决于组织的治理方法。敏捷团队的管理者不管理个人的工作，而是管理整个工作系统。他们为团队的成功做好准备，引导建立高效的团队环境，使每个成员能够在没有明确管理层干预的情况下做出正确的选择。
第十一章 改进
反馈和适应是敏捷的核心，这句话同样适用于团队的敏捷方法本身。虽然你可能从现成的敏捷方法入手，但每个团队都应制定符合自身情况的方法。就像在敏捷中的其他方面一样，这种定制是通过迭代、反思和反馈来实现的，强化有效的方面，优化无效的方面。其中，回顾、激发团队动力以及消除障碍是三个有效的实践。
回顾：团队的回顾活动有多种类型，其中迭代回顾是最常见的一种。这实际上是一个非常简单、有趣的团队协作工作坊[。通过一些巧妙的设计，团队成员都愿意分享他们过去这段时间收获的经验和看法，坦诚地讨论团队存在的具体问题并给出建议，帮助团队持续改进。
团队动力：团队不仅仅是一群人的集合。建立一个团队通常需要树立共同的目标愿景、一致的价值观，以及规范一同工作方式的方法。这是一个专业且循序渐进的过程。我们在团队中建立“共享领导力”并识别可能会对团队健康产生深远影响的“有害行为”。
消除障碍：“无常”是生活的常态，每个人时刻都会遇到各式各样、或大或小的障碍，对团队而言更是如此。对这些障碍的“识别”“区分”“定义”是妥善应对的关键。“圆圈和汤”这一形象有趣的思维方法可以帮助我们快速识别哪些障碍是团队可以控制的，哪些是可以影响的，哪些是既不能控制也无法影响的，进而快速采取合适的应对策略。
第十二章 协作
敏捷团队不仅要求团队合作，交付团队对于技术卓越和团队协作也有着很高的标准。他们致力于共同工作，以保持高质量的内部产出，并交付优先级最高的业务价值。以下这些实践将有助于团队进行协作。
代码集体所有权：读过《凤凰项目》的朋友都知道团队的明星员工劳伦特实际上是团队的瓶颈。“以团队的代码为荣”或者“对团队的代码负责”会给团队省去很多不必要的摩擦。更重要的是，当你意识到你面对的困难自己难以应对时，请放心“下坠”，你的团队会“接住你”。
结对编程：结对编程来自《极限编程》，是实现代码集体所有权的实践之一，编程是知识性工作，思考的时间远多于敲键盘的时间，特别是有了人工智能的加持之后，这两个活动的比值甚至会无穷大。
集体编程：和结对编程类似，只不过这种实践更彻底一些。虽然不是所有的场景都适合，但就我们的实践来看，在建立团队标准和编码共识的时候它是非常有效的。
统一语言：最初了解到“统一语言”的概念是在《领域驱动设计》。语言是人类最伟大的发明，作为一种粘合剂将不同背景、不同能力甚至不同文化的人粘合到一起。“统一语言”拥有类似的能力，软件开发是一种多领域知识碰撞的创造过程，统一语言让这些不同的知识载体可以实现良好协作。
第十三章 开发
软件开发过程中，很少谈及开发的具体细节。然而，团队的开发方式决定了绝大部分时间投入的地方。以下这些实践可以在提升开发速度的同时提高发质量：
自动化的程度往往决定了团队和个人的工作效率。通过场景画方式，“零摩擦”向我们展示了自动化如何显著提升了软件研发准备阶段带来效率。而“持续集成”以自动化为基础，在团队中建立起与之协作和工程实践，有助于消除开发过程中由人为因素引起的信息混乱。
“测试驱动开发”对程序员而言是“稳稳的幸福”，我们听过对测试驱动开发最恰当的解读是“从一个成功”到“另一个成功”。
质量与软件交付和团队中的每个人息息相关，“快速、可靠测试”是质量保证的基础，强调了需要工程师关注的测试策略与工具。
重构是一项广为人知的体系化的优化代码的实践：“在不改变代码外在行为的基础上，对软件内部结构进行调整，提高其可理解性，降低其修改成本。”
实验方案，也称为Spike，在工作场景中不需要翻译，因为这个词本身就是一个隐喻。它传达了一些需要的精神和含义：原意是攀岩运动中在墙壁上钉钉子的活动，在敏捷实践中指代小范围的探索性实验。
第十四章 设计
在软件开发过程中，增量式设计、简单设计和反思性设计是非常重要的设计方法。它们可以帮助开发人员创建高质量、可维护、易于扩展和可靠的软件。这些设计方法在软件开发过程中具有非常重要的作用，可以帮助开发人员创建优秀的软件。
增量式设计是一种通过一系列小的改变，而不是一次性重构整个代码库的方法。这种方法可以减少重构所需的时间和风险，同时保持代码库的稳定性和可维护性。通过增量式重构，每个改变都可测试且不会破坏代码库的其他部分，从而确保代码的稳定性和可维护性。
简单设计原则是一种非常重要的设计方法。它强调保持代码的简洁性，避免过度设计和复杂性，同时确保代码的可扩展性和可维护性。这种设计方法可以帮助开发人员创建简单、可靠和易于维护的软件。
反思性设计强调在设计过程中不断地反思和改进。它包括识别代码中的问题和缺陷，然后通过重构来改进代码。反思性设计的目标是通过不断地反思和改进代码设计来提高代码质量，同时提高开发效率和代码可维护性。
第十五章 DevOps
DevOps通过打破开发、运维和安全之间的壁垒，使团队能够创建更安全、更可靠、更易于在生产环境中管理的软件。以下是一些关键实践：
面向运维构建的目标是使应用程序更易于部署和维护。构建过程应该创建一个可以在任何环境中运行的二进制文件，这个文件应该是独立的、不依赖于任何特定的环境变量或配置。在构建过程中应该使用安全的编译器和库，以防止代码注入攻击。使用容器化技术部署可以使应用程序更易于部署和管理。
特征标志是一种管理应用程序特性的方法，在需要添加或删除功能时，只需要在代码中添加或删除一个特征标志。特征标志应该像代码一样受到版本控制的管理，同时应该使用配置管理工具来管理特征标志的状态。
构建和测试应该自动化，以减少人为错误；使用持续集成来确保代码的一致性和可靠性；使用持续交付来确保应用程序的部署和维护。
第十六章 质量
敏捷团队对待质量的视角不同，其视角下质量不是测试出来的，它是建立出来的。这不仅包括代码，还涵盖了整个开发体系：团队对待工作的态度，人们对错误的思考方式，甚至组织与团队互动的方式。
为了进一步推进流畅交付，团队需要进行敏捷实验和分析。团队采用构建-度量-学习-实践的方法，并探索如何建立自主团队、学习新的方法和工具，以实现更高效的生产力。实现流畅交付对于提高生产力和减少缺陷至关重要，这是团队追求的目标之一。
团队需要与内部和外部利益相关者合作，共同实现业务目标。团队还需探讨如何为客户和市场创造新的商业机会。敏捷实验和事件分析是团队不断推进流畅交付的关键。
通过事故分析，团队能够确定导致问题的根本原因并制定相应的解决方案。事故分析的步骤包括收集数据和证据、确定问题、找出根本原因、制定解决方案以及实施解决方案。在此过程中，团队需要保持开放的心态，尽可能多地收集信息和证据，并积极探索根本原因及解决方案。
第十七章 自主性
敏捷团队应该拥有自主性，自主性不仅仅意味着使团队能够独立工作，还代表着团队在财务和产品计划方面拥有完全的决策权。
敏捷团队通过发挥自主性来增强交付的流畅性。通过打通组织的上下游， 获得了对限制条件的决策权和自主权，从而实现更加顺畅地交付。
敏捷团队需要具备做出明智决策的能力，关注商业结果和价值，致力于为组织带来有意义的变革，他们得到组织的信任，因此高层管理人员和经理们能够将资金和任务交给团队，然后退居幕后。这样，团队就可以自行解决如何实现任务的问题。
敏捷织团队并不是没有监督，但这并不代表着他们可以为所欲为。他们仍然要展示他们的工作，并证明他们的宏观决定是明智的。组织在团队周围设置了指导轨道，以确保团队朝着正确的方向前进。团队的目标设定了大致方向，而近期目标和成功的衡量指标，则由团队与管理层和其他利益相关者合作制定。
对于敏捷团队而言，资金成为了组织层级的另一个监督机制。通常情况下，团队在持续的”日常业务 ”中运作，组织根据它对团队的期望结果来分配资金。此外，团队还可以通过向管理层解释原因来获得一次性的资金和资源。随着团队工作的进展，组织的预期价值是否得以验证，这为调整团队的目标提供了机会。如果团队创造了超出预期的价值，可以增加资金，这将鼓励团队更加努力取得成功。而创造的价值低于预期，资金可以减少，或者团队可以转向一个更有价值的目标。
第十八章 探索
优化团队致力于自主地做出产品决定。在决定建立何种产品方面，任务是明确的：学习并发现客户面临的问题和痛点，以及产品概念是否解决这些的问题。
验证性学习在发现客户需求和市场机方面具有重要性，为了适应不断变化的市场需求，灵活的计划和增量至关重要。例如，验证性学习必须基于真实客户和成本数据；学习和选择是优化团队的重要价值，特别是在产品创新的早期阶段；而选项思维和建立“安全”增量则是有效管理风险的手段。
保持适应性至关重要。通过 ”创造-度量-学习”的循环，团队会不断累积新的知识。为了利用这些到的知识，团队将调整计划。因此，优化团队更倾向于将计划范围设定的较短，以便适应变化。他们将有价值的增量保持的很小，从而可以灵活调整反向而不浪费资源。
优化团队需要以客户为中心，始终关注客户需求和市场机会，通过验证性学习及灵活的计划和增量来实现产品创新和开发。这需要团队成员持有开放的心态，愿意不断学习和适应市场需求的变化；同时，还需要建立有效的沟通机制，与客户和利益相关者保持紧密联系，不断收集反馈和建议，并及时调整计划和策略。只有这样，优化团队才能在竞争激烈的市场中脱颖而出，创造有价值的产品，并取得商业成功。
第十九章 走向未来
敏捷开发是一个不断学习、实验和改进的过程，从“尝试敏捷”到“投资敏捷”到“推广敏捷”再到“实践敏捷”。本书带着大家一起经历了这次敏捷之旅，然后实践只是一个起点。
一旦理解敏捷，就把它变成自己的实践：尽情试验替代方案，寻找新的想法。随着这些实践越来越得心应手，尝试打破规则，看看会发生什么。你将会更加深入地理解这些规则存在的原因，以及它们的限制和边界。
随着时间的推移，流程和经验将不断积累，惯例和原则将变得不再那么重要。当做正确的事情变成一种本能和直觉的习惯时，就是时候把规则和原则抛在脑后了。怎么称呼它并不重要，当直觉带来了伟大的软件，为有价值的目标服务，智慧激励着新生代团队，那是你已经掌握了敏捷开发的艺术。
