书名：敏捷测试：以持续测试促进持续交付
ISBN：978-7-115-56098-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 朱少民 李 洁
责任编辑 郭 媛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
互联网产品的快速迭代，让敏捷开发在各个领域都得到了广泛应用。同时，也加快了敏捷测试在各家企业落地生根的进程。
本书由测试领域老兵联合10余位测试专家对敏捷测试的实践经验汇总、整理而成。本书分为10章和4个附录，从敏捷开发和敏捷测试基础、人的因素、敏捷测试基础设施、分析与计划、设计与执行、测试右移、收尾与改进、展望等角度入手，几乎涵盖实现高效敏捷测试所需的各个方面的知识，详细介绍测试思维、测试流程、测试基础设施和一系列的优秀实践，对提高测试效率进而提升产品交付质量具有重大的指导意义。
本书理论知识与实践操作深度结合，辅以思维导图、延伸阅读等模块，深入浅出，尤其适合有一定测试实践经验的软件质量保障和测试人员，以及想要较为深入了解敏捷测试的专业人士阅读参考。
朱少民老师是国内测试领域的先行者，是敏捷测试的研究者和探索者，更是敏捷测试的实践者和推广者。这本书基于深入的研究与思考给出了敏捷测试的详细定义，认为持续测试是敏捷测试的实质，也是敏捷开发中真正需要的测试，并强调了思维模式转变在有效敏捷测试中的重要作用。这本书从人员/组织与技术基础设施两个方面建立了成功敏捷测试的基本保障，进而以测试左移与敏捷测试天然一致性、测试的分析与计划、测试的设计与执行，以及从敏捷到DevOps的测试右移等若干主题为主线，给出了敏捷测试落地实施的一套完整的实践方法。这本书既能从概念和思维模式上给予指导，又提供了系统的方法论和完整的实践支持，相信能给大家带来帮助。此外，阅读这本书，也解决了我多年纠结的一个问题——既不能单纯“形而上”，又要避免陷于“术”。道、法、术、器兼备融合，才能真正做好一项开拓性的工作 。
——陈晟，软通动力信息技术（集团）股份有限公司副总裁
目前全社会都在加速数字化转型，任何数字化产品都要求生产速度快而且质量高，数字化产品质量的把控已经不是测试团队单纯根据传统测试方法能够完成的。对于如何应对数字化转型过程中软件测试的挑战，敏捷测试是一个很好的解决方案。这本书将教给你几乎所有需要了解的关于敏捷测试的知识。最让我深有感触的是，它强调了“敏捷不只是方法，还是人和组织文化”。
——付可，Poly博诣全球研发副总裁
这本书从敏捷测试的定义入手，从人员及组织文化、思维方式、工作流程、基础设施、人员职责与培养等多角度阐述了敏捷测试如何落地，为传统测试向敏捷测试的转型指明了方向。鉴于作者的研究背景，这本书语言更为严谨，逻辑清晰，论证严密，既有深入思考，又有可以用来实践的具体建议，是一本非常好的敏捷测试实践指导手册。无论你是软件测试的管理者，还是初入行业的新人，这本书都值得细细品读。
——李怀根，广发银行研发中心总经理
不同于传统的测试相关的图书，这本书从测试人员的角度阐述了如何在实际场景中落地“敏捷测试”，并提出一整套解决方案来保障产品质量与工程效能，有助于读者进行学习和应用。
——邓月堂，腾讯微信测试中心总监
DevOps的精髓在于“持续”。相比持续集成、持续部署等已广泛落地的技术，持续测试在国内才刚刚兴起。这本新书的出版正当其时，它不仅阐明敏捷测试之“道”，也能在“术”的层面指导软件测试从业人员落地测试左移和测试右移，是一本不可多得的好书。
——阮志敏，飞致云创始人兼CEO
任何时候我们开始讨论测试，总会有各种分歧和争论，与之相伴的是整个行业的困惑。测试的行为和角色在快速变化和模糊不确定的时代中演变。
测试是一种活动，而不是一个阶段；测试是覆盖全生命周期的，既要左移，又要右移；质量是内建的，而不是通过检查获得的；测试是属于团队的，而不是一种个人行为。
是否称之为敏捷并不重要，这一切都只是在回归软件开发的本源，回归测试这一活动的初心，回归测试本该有的样子。
朱少民老师在业界耕耘多年，有资深的行业背景、严谨的学术态度，勤于思考和写作，乐于学习与分享，是我极为佩服与敬重的一位师长。这本书体现了他对测试这一领域的专注和热情。希望广大读者可以享受测试，享受它给你带来的启发和乐趣。
——姚冬，华为云应用平台部首席技术布道师
中国DevOps社区核心组织者
IDCF社区联合发起人
2020年注定是不平凡的一年，也许会成为新一轮数字化转型浪潮的起点。在《敏捷宣言》诞生近20年、DevOps运动风靡全球10多年之后的今天，如何在保证质量的前提下快速交付有效的产品价值依然是摆在很多企业面前的难题。交付速度可以是变量，追求越来越快，而交付质量和安全性是必须力保的常量，测试已经成为很多企业敏捷交付过程中最大的瓶颈。这本书有别于市场上其他讨论测试实践的书，它在数字化时代的大背景下从敏捷的视角来谈测试，系统地阐述了敏捷测试的理念、原则、方法、实践和工具如何落地，既有整体方法框架，又有大量落地实践和从真实案例总结出来的经验。更难能可贵的是，作者希望能“授之以渔”，即让读者不仅能学习如何做敏捷测试，还能体会如何在敏捷测试中，培养出敏捷测试的思维，打开更广阔的专业视野。这本书的编排非常用心，每章开头通过思维导图进行引导，每章结尾有延伸阅读，非常有指导性和实践价值。我将本书推荐给测试领域和对测试感兴趣的朋友。
——张乐，京东DevOps与研发效能技术总监、首席架构师
我是从互联网企业成长起来的测试人。传统软件以年为单位制定、迭代规划，而互联网时代，期待更快速、更灵活的模式。大量研发组织正在或即将从传统转型至敏捷，在理念、方法、技术和团队等方面都面临着迭代升级。这本书作者从事和观察这个领域多年，具备丰富的理论与实操经验，他的新书能提供有价值的参考，值得一读。
——钱承君，哔哩哔哩测试中心负责人
“这是一个最好的时代，这是一个最坏的时代。”这是写于158年前的经典名句，放在今天来看，依旧不过时。软件测试的理念在敏捷开发模式的冲击下正发生着天翻地覆的底层逻辑变化，如果不能系统地掌握高效敏捷测试的理论体系与方法，就很难在瞬息万变的VUCA时代立足，而这本书可以带你进入敏捷测试殿堂，非常值得你仔细阅读。
——茹炳晟，腾讯技术工程事业群基础架构部T4级专家
腾讯研究院特约研究员
畅销书《测试工程师全栈技术进阶与实践》作者
敏捷测试是DevOps时代最佳质量工程解决方案，已经“火”了许多年，但目前为止仍有不少同行对它处于不甚了解的状态。
这本书作者学识渊博，尤其是对敏捷测试这一新领域钻研多年，这本书是他的厚积薄发之作。这本书讲透了敏捷测试的道、法、术、器，是业内先验者凝练的经验总结，相信读者看完后一定能够刷新认知、升级技能，并且受用终身。
——殷柱伟，腾讯WeTest产品总监
随着移动化、云化和智能化技术的飞速发展，敏捷测试也面临着新的挑战。如何升级你的敏捷测试解决方案？敏捷测试中引入了哪些新的方法、技术和工具？如何做到持续测试来支撑持续交付？相信读者可以从这本书中逐一找到想要的答案。这本书既有关于敏捷测试体系化的道、法、术、器的阐述，又有丰富的业界优秀实践案例。
——金晖（定源），阿里巴巴淘系技术部高级测试开发专家
能够快速适应市场需求的变化，根据需求调整开发的内容和进度是每一个互联网公司努力追求的目标。在这种情况下，敏捷开发模式以高速迭代、频繁交付、灵活适应需求变化等特点，在各个工程领域得到了广泛应用。随着敏捷开发的发展，软件测试工程师也面临着更多的挑战。
这本书针对“敏捷”娓娓道来：开篇回顾了敏捷开发的原则、方法及其框架技术；接下来对敏捷测试涉及的测试方法、测试流程、测试技术、测试工具和最佳实践等进行了深入且细致的阐述；最后，把敏捷测试这一实践性很强的技术提到一个新的高度，对提高测试效率进而提升产品交付质量具有重大的指导意义。
——陈洋，小米IoT开发者平台测试中心总监
当“黑天鹅”事件越来越多地发生在我们的身边时，如何适应变化，并且在快速变化中持续交付高质量产品，成为当下研发团队的核心目标。而在高频的持续交付下如何保证产品的高质量，如何让测试团队从瀑布模式转化为与团队共担的敏捷模式，形成质量内建，这本书从敏捷发展历史到理念，再到工具，给出了全局性指导，是落地敏捷测试的一本佳作。
——云层，TestOps测试运维开拓者，《敏捷测试实战指南》作者
随着敏捷开发的广泛应用，敏捷测试也逐渐受到广泛关注，并引得“百家争鸣”。这本书是作者多年的经验总结，从敏捷测试的理论基础到实践操作，系统地介绍了敏捷测试的各个方面，是一本很好的学习敏捷测试的参考书。
——刘冉，ThoughtWorks首席测试与质量咨询师
当前国内敏捷领域测试相关的著作非常少，这本书作为补充，系统地介绍了敏捷测试的体系，不仅有完善的理论，还包括了丰富的实践和案例，非常值得读者仔细阅读。
——陈晓鹏，德勤管理咨询（上海）有限公司系统集成业务线测试负责人
敏捷测试并不是一个新概念。我拜读这本新书，至今意犹未尽。这本书实际上是一本介绍在当今开发高速迭代的情况下软件测试策略的书。这本书融会了敏捷的方方面面，并基于实际问题提出了具体建议，恰如其分地融合了新的观点与技术，对软件团队及管理者关于软件质量构建具有重要的指导意义。
——耿晓倩，Splunk公司总部测试开发总监
这是一本将近年来领域内最新的理论与实践相结合的不可多得的好书！随着敏捷和DevOps的兴起，软件测试的方法、工具和从业人员都面临着巨大的挑战。一方面，这本书更加体系化地梳理并构建了敏捷测试的理论基础；另一方面，这本书以深入浅出的方式介绍了在实际工程中如何应用理论与工具落地敏捷测试，给软件测试工程师和管理者提供了敏捷环境下具体可行的指导办法。它将带您开启敏捷测试的探索之旅！
——陈飞，独立敏捷教练、质量教练
作为最早在国内推进敏捷测试的践行者之一，作者将自己多年关于敏捷测试的心得体会汇聚于此。这本书循序渐进地为读者厘清一整条敏捷测试脉络，同时将业界公司实际使用的工具、框架、方案完整地以图文、代码的方式呈现，实操性极强。对于想要了解敏捷测试，并希望从中获益的个人或正从传统模式转型敏捷模式的团队，这本书十分值得认真阅读。读者可以跟随全书的主脉络及每章结尾处的延伸阅读构建出适用于自身和团队的敏捷测试图谱。
——张宏博，字节跳动资深测试开发工程师
数字化浪潮正一浪高过一浪地袭来，处于核心的软件开发持续高速演进，让我们这些从业者倍感焦虑。对软件开发行业的领导者来说，至关重要的一点是在高速发展的过程中逐步深化认知，提炼出变化中不变的东西，既帮助当下的从业者拨开迷雾，又能够让后继者少走弯路。对比很多领域，软件行业实则很缺乏这样的积淀，也缺乏类似这本书从专业视角所做的系统性总结。
对于软件测试工作一直存在着两个极端：一个极端源自于硬件生产迁移过来的专人专用，测试就是测试人员的责任的做法；另一个极端是软件开发不需要测试，开发人员必须是“多面手”的不切实际的想法。产生这些误解的背后原因，正是这本书作者希望通过“敏捷测试”去澄清的。
在帮助组织推行敏捷开发的十多年时间里，测试一直是个“老大难”领域，《敏捷宣言》的倡议在测试领域是典型的知易行难，大家都知道沟通和协作的重要性，但一谈到最后的问题责任认定，每个角色都希望把测试的烦恼留给别人。于是经常出现开发人员抱怨测试人员不给力，测试人员抱怨开发人员不按时完成的情况。而这些问题往往被宏观的理念所忽视，从持续集成到DevOps，测试方面的敏捷可能仅仅是一笔带过，“质量内建，人人测试”好似面向对象编程一样，已经是普适性能力。当然，事实并非如此，这本书的目录就可以帮助大家体会到这样一个系统性工程的复杂性。
这本书作者对于“高效敏捷测试”的总结实际上是对于一个组织软件研发质量保障体系的剖析。面对云和智能技术的普及，很多敏捷测试理念的落地必然会有更多的选项，实施的门槛也会逐步降低。现在我们面临的最大的挑战仍然是思想观念的转变，这也是我钦佩这本书作者之一朱少民老师之处。朱少民老师能够通过自己在敏捷测试领域的专业能力和热诚，影响一个又一个的组织和企业，让正确的敏捷测试思想为更多的团队所接受，与此同时，他还在不断地关注和吸纳更多的前沿技术。
最后，我相信这本书的出版仅仅是我们讨论敏捷测试如何更加高效地在组织落地的开始，也会推动这个领域的持续碰撞和总结。随着数字化的深入，敏捷测试会成为很多数字化业务的关注重点。让我们一起踏上这本书提倡的敏捷测试之旅吧！
肖然
ThoughtWorks创新总监
中国敏捷教练企业联盟秘书长
2020年12月
我认识朱少民老师是在2019年召开的一个关于DevOps的交流大会上。当时，他做了一场题为“业务驱动的DevOps智能闭环”的演讲，这个题目对于我这个还在IT企业内部大规模推进DevOps的人来说，还是有点超前的。在那次大会期间，朱少民老师现场签售《全程软件测试（第3版）》这本书，我毫不犹豫地买了下来。虽然我当时在测试领域涉足不深，但同样对他渊博的知识产生敬佩之情。后来，我与朱少民老师在复旦大学彭鑫老师牵头主办的“智能化软件开发沙龙”的访谈中有过多次交流。2020年，我受朱少民老师邀请，担任QECon大会DevOps分会场的出品人。
朱少民老师的这本新书旨在实现软件持续交付，并且更有效地推进DevOps的实施。乔梁老师有句名言：流程和工具持续优化所能达到的最高境界就是让开发者成为瓶颈。而要达到这个“终极目标”，以及学会如何解决“测试瓶颈”的问题，读者也许可以从这本书中找到一些思路。这本书在每章开始用思维导图的方式概述本章内容，每章的结尾处有小结和延伸阅读，帮助读者思考。这本书一开始从测试四象限入手，总结了当前流行的分层测试框架，并结合最新的思维方式和流程，提出新的敏捷测试四象限；接着，就是解决人的“思想”问题，只有了解影响变革的本质——人的思想问题，才能更好地使用后续章节所提到的工具和基础设施。
我们在刚进行敏捷试点的时候，吕毅老师给我们进行Scrum培训，其中给我留下深刻印象的是“候鸟迁徙”的例子：它们持续在做“适应和调整”。在VUCA时代，如何更好地适应变化，是企业实现数字化转型的重要能力。虽然这是一本关于测试的书，但是其实它是从测试如何更好地适应新的端到端研发流程的角度进行阐述的。为了更好地进行敏捷测试，不但要对业界当前流行的基础设施技术、容器技术、微服务架构、各类DevOps实践和工具进行了解，而且要进一步左移，了解产品需求分析和价值分析的工具，了解TDD（测试驱动开发），领域驱动开发和设计，以及实例化需求等实践和方法。另外，为了应对微服务架构给测试带来的挑战，实现低风险的部署，支持持续的灰度发布，敏捷测试也要右移，通过在线的方式进行高效的验证测试。如果你关注过Gartner的报告，一定听说过技术成熟度曲线（或者称为“炒作”曲线），在2020年发布的Agile和DevOps技术成熟度曲线中，测试自治（autonomous testing）、持续质量（continuous quality）、混沌工程（chaos engineering）和性能工程（performance engineering）都出现在技术成熟度曲线的“创新触发区”。如果你正在寻找关于这些实践的落地方法，可以参考朱少民老师写的这本书。
“想，都是问题；做，才有答案”，这是招商银行田惠宇行长在我行进行Fintech战略转型时所说的一句话。其实，在实现高效的敏捷测试时，也是一样：在推行DevOps和持续交付的过程中，J形曲线（“烟斗”曲线）——迎来小波峰后就会因为测试的原因掉入大波谷——是绕不过的“坎”。最后，希望这本书能为读者找到行动的方向和带来指引。
陈展文
招商银行总行信息技术部DevOps推广负责人、资深专家
2020年12月
20年前，《敏捷宣言》发布，正式宣告敏捷开发模式诞生，但敏捷开发模式在国内被采纳的时间相对比较迟。2006年6月，首届“敏捷中国”开发者大会在北京召开。腾讯、华为等一些头部企业，从2007年开始敏捷试点。而“敏捷测试”的提出和应用则更晚一些，2009年，国外出版了第一本关于敏捷测试的书，然而敏捷测试的正式定义直到2017年才给出（根据国际敏捷联盟官方网站的记录）。
2010年，笔者在《程序员》杂志上发表过一篇文章《敏捷测试的方法和实践》。2011年，笔者又在这本杂志上发表了文章《敏捷测试的思考和新发展》，谈到“在BDD（行为驱动开发）、ATDD（验收测试驱动开发）和TDD（测试驱动开发）最根本的、共同的思想基础上，构成一个全新的、更完善的敏捷测试框架”。此后，笔者陆续写了不少文章，如《究竟什么是敏捷测试》 《如何不让测试成为敏捷的绊脚石》等。至于敏捷测试相关话题的文章就更多了，涉及自动化测试、探索式测试和DevOps等。如果读者有兴趣，那么可以去笔者的公众号“软件质量报道”里阅读。
笔者是国内最早开始思考软件测试如何适应开发敏捷化并且一直坚持下来的那批人之一，也正是基于坚持，在不平凡的2020年，逆行而上，在拉勾教育开设了“高效敏捷测试”专栏，经过4个多月的努力，圆满实现阶段性目标。在此专栏的基础上，笔者又重新整理，丰富内容，形成本书。
这些年，敏捷开发在国内已经流行起来，敏捷测试也有了较大进步，加上DevOps（development和operation的组合词，是一组过程、方法与系统的统称）的兴起，进一步推动了测试左移（测试前移）和测试右移（在线测试）的发展。例如，大家开始重视软件的持续构建（continuous build，CB）和测试自动化，大量使用体现敏捷测试思想的开源工具，开始探索通过软件测试平台提供各种测试服务。
有些公司开始在流程上明确要求在设计、编程前要明确用户故事（user story，US）的验收标准，即开始推行ATDD；有些大型金融机构开始推行BDD，开始使用自带BDD的自动化测试框架；有些团队更加关注探索式测试；在有些团队中，测试人员和开发人员更加融合，在一个看板上一起讨论测试任务。
这些均说明敏捷测试的思想和方法是经得起时间考验的，也说明测试同行在探索和推广敏捷测试方面确实取得了一定的成效。
但有很多人对于敏捷测试的理解依然不够准确。2013年，笔者在InfoQ（极客邦科技旗下的全球社区网站）上发表了《究竟什么是敏捷测试》这篇文章，认真探讨了敏捷测试的内涵。如今8年过去了，这种情况依然没有明显改善，这导致基于敏捷的测试实践往往形似而神不似，更糟糕的是，根据2019年的相关调查数据显示，软件测试已经成为敏捷交付的最大瓶颈。导致这样的局面的主要问题有：
看到这些问题，以及敏捷中的测试处在比较糟糕的境地，笔者心里非常着急。这是笔者开设专栏、写书的一个重要原因。
如果敏捷团队成为自组织的特性团队，团队对质量测试负责，开发人员也热衷于测试工作，或者说，测试是每个研发人员的日常工作中的一部分，就没有独立的测试，开发和测试彻底融合，敏捷测试就是一个伪命题。
但是现实不是这样的，即使今天又前进了一步，从敏捷走向DevOps，许多开发人员依旧缺乏质量意识，不能构建高质量的设计和代码，也不能很好地完成单元测试、集成测试等工作，甚至单元测试相较十几年前没有什么改善，他们更不乐意去做系统测试、业务验收测试，测试还是由一些专门的测试人员来做。在这种环境下，敏捷测试就不是一个伪命题。
正如前面所说，软件测试已经成为敏捷交付过程中的最大瓶颈。如果不打破这个瓶颈，就不可能实现敏捷、DevOps最主要的目标——持续交付。笔者写这本书，就是为了帮助读者所在的团队实现这一目标。要实现这一目标，就是要做到持续测试。于是笔者最近一段时间一直强调“敏捷测试就等于持续测试”。如果做不到持续测试，就做不到持续交付，也就做不到敏捷和DevOps；如果做到了持续测试，那么任何时候都可以启动测试，任何时候都可以完成必要的测试，比如两周是一个迭代周期，那两周也能完成所有必要的测试。只有做到持续测试，才能支撑持续交付，才能跟上不断出现的市场变化的速度，才能满足这样的市场环境中的用户。
敏捷测试不但是持续测试，拥有《敏捷宣言》所倡导的价值观，遵守敏捷开发的原则，而且也包括一套软件测试的解决方案，包括测试思维、测试流程、测试基础设施和一系列的优秀实践等，最大限度地实现高效测试，持续改进。
敏捷测试发展到今天，有很多成功的经验，也有一些失败的教训。现在是一个信息爆炸的时代，网络上关于敏捷测试的信息很多，各种观点都有：有的缺乏系统透彻的阐述；有的“鱼目混珠”；有的甚至觉得敏捷测试是个筐，什么好东西都想往里装。因此想分辨什么是真正有效的敏捷测试就变得更加困难。
关于敏捷测试，市面上已有两本书《敏捷软件测试：测试人员与敏捷团队的实践指南》《深入敏捷测试：整个敏捷团队的学习之旅》（Lisa Crispin和Janet Gregory合著），但是看过这两本书的一些读者反映，在对内容的理解上还是比较模糊，难以获得真正可以落地实施的敏捷测试解决方案。本书可以帮助读者重新认知敏捷测试，帮助读者显著提升个人的测试能力，力求将敏捷测试真正落地实践，助持续交付一臂之力，扫除其前进路上的障碍。
敏捷测试涉及很多内容，它是一套适合或顺应敏捷开发的解决方案，包含测试思维、测试人员/组织、测试技术、测试方法、测试流程和工具等方面。本书会系统地阐述这些内容，以业界优秀实践为基础，将真实案例贯穿全书，做到理论和实践相结合。本书也力求以直观、简洁的方式呈现敏捷测试的具体操作流程，尽可能引入有效的测试新方法、新技术和新工具，包括智能的测试技术、基于容器的测试环境部署等。本书不但给读者讲解敏捷测试如何做，而且还讲解为什么这样做，帮助读者拓展测试视野，进一步练好测试的基本功，重构测试技能，构建良好的敏捷思维，使读者终身受用。
本书共10章，第1章内容作为铺垫，重温敏捷的价值观和开发原则，了解不同而具体的敏捷开发框架。如果读者已熟练掌握敏捷开发方法，那么可以跳过这一章，直接从第2章开始阅读。建议读者认真阅读和仔细体会第2章的内容，因为这一章是基础，在“道、法、术、器”中，“道”排在最前面，比原则、方法、技术和工具都重要。
接下来的第3章和第4章也是为后续学习打基础。因为人的因素以及组织文化的构建对于敏捷测试的成功起到决定作用，很多表面上看起来是技术层面的问题，其实本质上是人的问题。因此，在进入敏捷测试的具体操作的讲解之前，我们必须先谈谈人员和组织文化。第3章主要讨论敏捷开发中测试的职责由谁承担、如何承担，以及是否要设置专职的测试人员。如果设置专职的测试人员，那么该如何操作；如果没有设置，那么又该如何操作。第3章还讨论了团队如何转型、学习型团队如何构建，以及不同角色之间如何协作，即使读者不从事敏捷测试，这些内容也是非常有价值的，只是在敏捷测试中其更具有价值，因为敏捷更强调学习、协作和成长等。第4章讨论了敏捷测试的基础设施，包括如何应用虚拟机技术、容器技术等搭建测试环境，这一切就是为了更好地支持自动化测试、自动部署，以及与持续集成/持续交付（CI/CD）的集成等，这些是技术基础。读者会看到敏捷测试在持续集成、持续交付，以及DevOps的实施过程中无处不在。
接下来，本书用5章的篇幅（第5章～第9章）详细介绍如何落地高效敏捷测试，从测试左移（包括需求评审、设计评审和彻底的测试左移ATDD等）、测试计划、测试分析与设计、测试执行到收尾的完整过程。这个过程的前提就是敏捷开发模式，需求是采用用户故事来描述而且变更相对频繁，迭代也是很快的，测试很有挑战性，因此这部分内容侧重于介绍如何应对这些挑战。
通过这部分内容，读者会了解很多优秀的敏捷测试策略、方法和技术实践等。
本书的最后一章是对敏捷测试未来的展望，通过介绍人工智能及大数据测试方法、敏捷测试工具的未来发展趋势，让大家了解敏捷测试的未来。实现彻底的持续测试是敏捷测试的终极目标，这一章介绍了实现持续测试的思路和框架。
每章开头均有思维导图来引导读者学习，每章结尾均有延伸阅读，可以触发读者新的思考，以扩展本书内容，打破本书的局限性，让读者收获更多。
如今，成为一个敏捷测试工程师是大势所趋，更是优秀职场人的自我驱动。通过本书的阅读，读者会有如下收获：
如果读者是研发部门经理或项目经理，那么将获得更多的收益，包括提升对敏捷测试全局的理解，清楚下面的操作和管理：
希望读者能够喜欢本书。让我们一起开启这段敏捷测试之旅，开创辉煌的未来！
首先感谢拉勾教育提供良好的合作机会，让“高效敏捷测试”专栏如期推出，之后成了本书内容的坚实基础；感谢异步社区对本书出版的重视，以及提供的资源支持，更要感谢人民邮电出版社信息技术分社社长陈冀康和本书编辑郭媛的辛勤付出。
感谢家人和朋友的支持，感谢相关测试专家提供的一些素材和案例，这其中就有Poly博诣公司的王海强帮忙完成了本书附录A的内容。
特别感谢ThoughtWorks创新总监、中国敏捷教练企业联盟秘书长肖然和招商银行总行信息技术部DevOps推广负责人、资深专家陈展文两位老师从百忙之中抽出宝贵时间为本书写序。感谢各位IT同人为本书写推荐词，他们是：
陈晟，软通动力信息技术(集团)股份有限公司副总裁；
付可，Poly博诣全球研发副总裁；
李怀根，广发银行研发中心总经理；
邓月堂，腾讯微信测试中心总监；
阮志敏，飞致云创始人兼CEO；
姚冬，华为云应用平台部首席技术布道师；
张乐，京东DevOps与研发效能技术总监、首席架构师；
钱承君，哔哩哔哩测试中心负责人；
茹炳晟，腾讯技术工程事业群基础架构部T4级专家、腾讯研究院特约研究员；
殷柱伟，腾讯WeTest产品总监；
金晖(定源)，阿里巴巴淘系技术部高级测试开发专家；
陈洋，小米IoT开发者平台测试中心总监；
云层，TestOps测试运维开拓者；
刘冉，ThoughtWorks首席测试与质量咨询师；
陈晓鹏，德勤管理咨询(上海)有限公司系统集成业务线测试负责人；
耿晓倩，Splunk公司总部测试开发总监；
陈飞，独立敏捷教练、质量教练；
张宏博，字节跳动资深测试开发工程师。
本书由异步社区出品，社区（https://www.epubit.com/）为读者提供相关资源和后续服务。
本书提供彩图文件，如要获得此配套资源，请在异步社区本书页面中点击
，跳转到下载界面，按提示进行操作即可。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎读者将发现的问题反馈给我们，帮助我们提升图书的质量。
当读者发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入错误信息，单击“提交”按钮即可（见下图）。本书的作者和编辑会对读者提交的错误信息进行审核，确认并接受后，读者将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果读者对本书有任何疑问或建议，请读者发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果读者有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果读者所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果读者在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请读者将怀疑有侵权行为的链接发邮件给我们。读者的这一举动是对作者权益的保护，也是我们持续为读者提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近40年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
有什么开发，就有什么测试，传统开发之下就是传统测试，敏捷开发之下就应该推行敏捷测试。在讨论敏捷测试之前，必须先了解敏捷开发模式，否则理解敏捷测试会很困难，因此有必要用一章的篇幅来进行铺垫。虽然用一章的篇幅不能详细介绍敏捷开发模式的具体操作、实践和工具等，但还是能讲清楚敏捷开发模式的由来、敏捷价值观、开发原则、开发框架，以及敏捷看板、精益和DevOps的关系等内容。
随着开源运动（open source community，OSC）、互联网、软件即服务（software as a service，SaaS）等不断发展，其对软件工程、软件研发模式的演变产生越来越深刻的影响，从而促进软件工程不断创新、变革和发展，以适应新形势下的软件的开发、运行和维护的需求。敏捷开发模式、DevOps应运而生，并逐渐流行起来，并与云计算平台、容器技术等融合，构成了今天的软件开发环境。
敏捷开发是一种思想或方法论，就是通过不断迭代开发和增量发布，最终交付符合用户价值的产品。如何用敏捷的思想来指导软件开发？现在有很多具体的敏捷开发框架、流程或模式，如Scrum、极限编程、行为驱动开发、功能驱动开发和精益软件开发（lean software development）等。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。但无论采用哪种具体的敏捷开发模式，都应该符合《敏捷宣言》的思想，遵守敏捷开发的原则。我们需要按照《敏捷宣言》和敏捷开发原则来判断某种开发活动和实践是否是敏捷开发。
敏捷开发模式可以追溯到1620年，英国哲学家弗朗西斯·培根发表了他的代表作之一——《新工具》，如图1-1所示。《新工具》是对亚里士多德《工具论》的批判继承，全书分为两卷，第一卷着重批判经院哲学的观点，主张人应该是自然的解释者，只有认识并发现了自然的规律，才能征服自然；第二卷论述了归纳方法，为归纳逻辑奠定了基础。培根认为单纯的感觉甚至某些实验所能告诉人们的信息中有太多偶然性的因素，而且之前形式逻辑中的枚举归纳依赖于对已知事例的一一列举，其结论建立在已知的少数事例上，因此他在《新工具》中主张合理的归纳应该以大量的事实为基础，而且是一种循序渐进的研究过程。这样的科学方法可以写成“假设—实验—评估”或理解为“计划—做—检查”（plan-do-check）。直到300多年后，即1939年，贝尔实验室的统计学家沃特·休哈特依据这样的科学方法，将“统计控制”下的生产描述为“规范—生产—检验”（specification-production-inspection）这样的3步过程，借助统计分析的帮助，不断对产品和过程进行改善。之后，休哈特的学生、现代质量控制之父威廉·爱德华兹·戴明将这个过程修改为著名的戴明环，即PDSA（plan-do-study-act，计划—做—学习—处理）环。根据戴明的说法，日本参与者在20世纪50年代又进一步将PDSA改为今天大家熟悉的PDCA（plan-do-check-act，计划—做—检查—处理），用于质量管理、业务流程等持续改进，并得到广泛应用。因此，敏捷方式更合理的追溯时间是20世纪20～50年代，看作PDCA思想的延伸，将PDCA用于软件开发过程中，如图1-2所示。
图1-1 弗朗西斯·培根的《新工具》
其间，丰田公司聘请戴明培训公司中数百名经理，并在他的经验之上创立了著名的丰田生产体系——精益生产，按订单生产，减少库存，尽力避免各种生产环节产生的浪费，并持续改进产品质量。精益思想，包括其实践+看板，对敏捷开发又产生了较大影响，或者说，精益思想已逐渐融入敏捷并发之中。
图1-2 PDCA循环（来自维基百科）
在敏捷开发中，目前比较流行的是Scrum开发模式，而Scrum可以追溯到1986年。在那一年，日本一桥大学教授、享有世界“知识运动之父”美誉的竹内弘高、野中郁次郎在1986年1月出版的《哈佛商业评论》发表了一篇文章《一种崭新的新产品开发游戏》（“The New New Product Development Game”），首次提到新产品开发应该是“橄榄球”（即Scrum开发模式），团队试图作为一个整体完成所有任务，将球传来传去，而不应该是传统的“接力赛”方式—序列式的开发（即“瀑布模型”开发模式）。他们是在通过研究那些比竞争者更快发布新产品的公司（如富士施乐的复印机、本田的摩托车引擎、佳能的照相机等）后而提出这种Scrum开发模式。这种整体方法有6个特点：内建不稳定、自组织团队、重叠开发阶段、多样化学习、微妙的控制和学习的组织内转移。
1）内建不稳定。高层管理者往往只是指明战略方向，制定极具挑战性的目标，这种挑战性目标会传递压力给团队，而高层管理人员给予项目团队极大的自由（新产品概念、具体工作计划等则由项目团队自行决定、完成），团队反而能体会到这种不稳定性，更能激发团队的斗志。
2）自组织团队。像一家初创公司一样运营，具有三大特征：自治、自我超越和交流成长，能够自行运作，承担主动性和风险，自己制定计划和进度表，突破原来的惯性思维，每天都在渐进地改进、完善，不断提升。
3）重叠开发阶段。不像传统的序列式开发模式，开发的各阶段重叠，使得团队始终保持信息通道畅通，增强了合作意识，获得了更高的效率和更大的灵活性，更能适应变化，提高了对市场的敏感度。
4）多样化学习。表现在两个方面：跨越多个层次（个人、团体和企业）、多个专业（不同领域）的学习。个人层面的学习有多种方式，例如，将在公司15%的时间用于追求个人的“梦想”，利用同伴的压力来培养个人的学习能力，团队可以开展集体读书打卡活动，等等。多职能的学习，则鼓励员工通过学习积累自己工作领域之外的经验，掌握非本职工作之外的能力。员工通过这些多样化的学习方式来培养主动性和学习能力，并使自己跟上最新的发展。
5）微妙的控制。虽然项目团队大部分是靠自己管理，避免那种严格的控制，但并不是不受控制，而是强调“自我控制”“通过来自同事的压力来控制”和“爱的控制”，如鼓励工程师听取客户和经销商的意见，监测团队动态变化，必要时增加或剔除成员等。
6）学习的组织内转移。定期开展将学习的知识转移给接下来的新产品开发项目或组织的活动，例如将关键人员分配给随后的项目，通过“渗透”进行知识转移。而且，知识也可通过将项目活动作为标准实践，在组织中传播，甚至将成功的经验制度化。
除自组织团队、多样化学习以外，文章还强调“产品开发过程是在一个精心挑选的多学科团队的持续互动中产生的，团队成员从头到尾都在一起工作”，因此这篇文章经常被认为是Scrum开发框架的灵感来源。
1994年6月，贝尔实验室（Bell Labs）软件产品研发部成员詹姆斯·考帕里安在佛罗里达州奥兰多举行的第5届Borland国际年会上发表了一篇论文《Borland软件工艺：流程、质量和生产力的新视角》（“Borland Software Craftsmanship：A New Look at Process,Quality and Productivity”），这篇文章主张研发团队每天开一个短的会议，这样能显著提高团队效率。杰夫·萨瑟兰从上面两篇文章获得了灵感，创建了一种新的软件开发方法——Scrum。作为Scrum开发方式的实验，完成了Easel公司一项极具挑战性的产品开发任务，而且做到了程序缺陷较之前版本少很多、没有超出预算等。随后，杰夫·萨瑟兰和他的同事肯·施瓦伯对Scrum方法进行了进一步研究，并在奥斯汀举办的ACM OOPSLA（面向对象编程系统、语言以及应用程序）1995年年会上联合发表了一篇论文，正式发布了Scrum开发框架。此后的几年，他们将Scrum的实践经验以及业界的优秀实践进行融合，形成今天业界熟知的Scrum。
在Scrum提出之前，1991年IBM请阿利斯泰尔·科伯恩开发面向对象项目的方法论时，他为此进行广泛的调研，认为不存在一种适合所有开发流程的、规模相同的团队，而是分为不同规模的团队，从而逐步构建起一系列的水晶（crystal）开发模式，包括透明水晶方法论（crystal clear）、黄色水晶方法论（crystal yellow）、橙色水晶方法论（crystal orange），以及红色水晶方法论（crystal red）。水晶开发模式以绩效为先，强调经常交付，流程虽然重要，但是次要的，并聚焦开发人员，沟通与协作（渗选式交流），以及反思改进，提倡与专家用户建立方便的联系，配有自动测试、配置管理和经常集成功能的技术环境。
之后各种轻量级开发方法如雨后春笋般涌现出来，如图1-3所示，却引来它们之间谁对谁错、谁好谁坏的争论，而且争论越来越激烈。
图1-3 轻量级开发模式发展的历史
1992年，威廉·奥普迪克发表了论文《面向对象框架之重构》（“Refactoring Object-Oriented Frameworks”），对“重构”进行了全面的论述。
1994年，珍妮弗·斯特普尔顿提出动态系统开发方法（dynamic systems development method，DSDM），强调发布周期相对固定，功能特性动态调整。
1995年，肯·施瓦伯和杰夫·萨瑟兰在OOPSLA大会上联合发布了Scrum开发框架。
1996年，马丁·福勒、肯特·贝克等人将极限编程（eXtreme Programming，XP）方法第一次引入C3项目。
1998年，关于极限编程的第一篇文章《走向极限编程的克莱斯勒公司》（“Chrysler Goes to ‘Extremes’”）发表，描述了一些极限编程实践。
1998年，杰夫·德·卢卡等人正式提出特性驱动开发（feature-driven development，FDD）方法。
1998年，持续集成（continuous integration）和每日站会（daily standup）被列入极限编程的核心实践中。
1999年，福勒出版了《重构：改善既有代码的设计》。“重构”实践在此之前的几年已经被纳入极限编程，但因这本书才得以推广。
1999年，贝克出版了《解析极限编程：拥抱变化》。
1999年，安德鲁·亨特等出版了《注重实效的程序员》（The Pragmatic Programmer）。
1999年，吉姆·海史密斯提出自适应软件开发（adaptive software development，ASD），着眼于人员协作和团队自我组织，自我思考和学习。
2000年，福勒的文章《持续集成》（“Continuous Integration”）发表。
2000年，ThoughtWorks开源了第一个持续集成工具CruiseControl。
2000年9月，来自芝加哥的鲍勃·马丁发了一封电子邮件，提倡召开一次会议，解决当时争论的关于轻量级开发方法的各种问题。马丁希望2001年1月～2月在芝加哥举行一场小型（两天）会议，目的是让所有轻量级开发方法领导者进入一个“房间”—达成共识。他认为这些人都应该被邀请，并且他也有兴趣知道还应该联系谁。他为此建立了一个维基站点，讨论会议主题和会议地点。有人反对“轻量级”这个词，而反对更激烈的是会议地点芝加哥。
2001年2月11日～13日，17位不同的轻量级开发方法（如Scrum、极限编程、自适应软件开发、特性驱动开发、动态系统开发等）“掌门人”在美国犹他州雪鸟（Snowbird）滑雪胜地聚会，试图找到这些开发方法的共同点，就实质性问题达成共识。虽然与会者不能在具体方法上达成一致，但是他们为共同拥有的方法论取了一个名字：敏捷（“Agile”来源于《敏捷竞争者和虚拟组织：给客户更多的策略》（Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer），并发布了《敏捷宣言》（全称《敏捷软件开发宣言》）。
我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：
1）个体和互动高于流程和工具；
2）工作的软件高于详尽的文档；
3）客户合作高于合同谈判；
4）响应变化高于遵循计划。
也就是说，尽管右项有其价值，我们更重视左项的价值。
在《敏捷宣言》发布后，敏捷思想快速传播，不少公司开始尝试敏捷开发模式。我们可以这样说，所有符合《敏捷宣言》所阐述的价值观及其背后的12项原则的开发框架，都可以认为是敏捷开发模式。
《敏捷宣言》代表了价值观。传统研发模式对人不够信任，强调流程的作用，通过流程来减少，甚至杜绝问题的发生。敏捷开发模式以人为本，认为人是决定的因素，研发人员及其构成的团队更具价值，团队决定了研发的质量和效率，团队对质量负责；并且相信团队，鼓励团队内部成员之间的协作、团队之间的协作，并由团队来确定该做什么、如何去实现，包括任务估算、进度安排。因此，在敏捷开发模式中，每一个研发人员及其协作的价值高于流程和工具的价值。
我们都清楚，软件研发要交付的是开发的产品或服务，而不是软件过程文档。如果过程文档写得很漂亮，但交付的软件漏洞百出，或者用户不能很好地使用软件，就是本末倒置，没有正确认识软件研发的本质。因此，敏捷开发强调我们交付出去的软件的价值胜于文档的价值。
软件产品或服务是为了提供给客户使用或者解决客户的问题，客户清楚这个软件是否能够解决他们的问题或者符合他们的使用习惯。即使我们有良好的用户思维，可以从用户的角度思考问题、设想客户的需求、设计软件、写代码、做测试等，但研发人员终究不能完全代表客户（用户），于是我们要和客户合作，经常和他们交流，听取他们的反馈，这样才能打造出符合他们需求的软件，给客户带来更大的价值，让客户获得更好的体验。因此，我们应该认可客户合作的价值胜于合同谈判的价值。如果客户确实不能和研发人员在一起开发，那么业务人员、产品负责人应该代表客户，与研发人员在一起工作，分析和定义需求，按价值大小决定待开发的功能特性的优先级等。
市场驱动业务，业务驱动研发。当今是一个快节奏的时代，市场瞬息万变，业务需求的变化也很快，那么我们的研发不能拒绝这种变化，拒绝需求变更，而应该拥抱这种快速的需求变化，从架构、代码、流程等各个方面进行变革，从而能够适应市场的挑战，满足用户的需求。这就是敏捷所强调的“响应变化高于遵循计划”。
敏捷还有其他一些价值观，如开放、勇气、尊重、承诺、反馈和简单等。敏捷拥抱变化，这种变化不仅体现在用户需求的变化，还包括技术的变化、工程实践的变化、流程的变化，甚至一切上下文的变化。作为敏捷的践行者，不能墨守成规，也不能拘泥于某一种特定的形式，而是应该拥有开放的精神，敢于尝试新的技术、新的实践，主动求变，也就是需要有勇气去进行新的尝试，不怕犯错，一旦犯错，能认识到错误并通过反思来审视错误，于是勇气还体现在快速迭代、不断反思上。
因为以人为本，所以要信任研发人员，尊重他们的意见和决定，由团队进行估算和制定计划。而之前的传统开发模式，通常是上级制定的、被动安排的，在这种情况下，许多承诺是违心的，承诺缺乏意义。而在敏捷开发模式下，研发人员得到尊重，团队是自我管理的团队，同样得到足够的尊重，承诺是建立在团队自身所做出的估算和计划之上的，自然有决心和能力兑现承诺。
敏捷推崇快速迭代、持续交付，一方面是为了拥抱需求的变化，更好地满足业务或用户的需求，另一方面，也是为了快速得到用户的反馈。如果软件开发方向有偏差，那么及时调整，少走弯路，即使没有偏差，也可以更快地改进产品，提升用户体验，也就是说，持续交付达到持续反馈、持续改进。
简单，有利于快速构建和重构。在敏捷开发中，需求、架构、代码等力求简单，这样可以更好地支持快速迭代、快速交付。
敏捷运动并非反对方法论，事实上，敏捷倡导者倒是希望恢复“方法论”这个词的可信度，恢复平衡，接受建模。敏捷倡导者接受文档，但不是数百页从未维护过且很少使用的大部分文档。敏捷倡导者也会制定计划，但在日新月异的环境中认识到了规划的局限性。
《敏捷宣言》只是呈现了其价值观，但对具体实施缺少实质的指导意义，有些制定《敏捷宣言》的参会人员还开玩笑说：《敏捷宣言》是“糊涂”声明。人们对敏捷方法论的兴趣，有时也伴随着巨大的批评。因此，在《敏捷宣言》发布之后的几个月，参会人员一起努力，制定了《敏捷宣言》背后的12项原则，帮助我们以更灵活的方式思考软件开发方法和组织。
为了更好地体现《敏捷宣言》所阐述的价值观，这里简单介绍《敏捷宣言》背后所蕴含的12条原则。
1）我们最重要的目标是通过持续不断地快速交付有价值的软件使客户满意。
2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6）不论团队内外，传递信息效果最好、效率最高的方式是面对面交谈。
7）可工作的软件是进度的首要度量标准。
8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定、延续。
9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10）以简洁为本，它是极力减少不必要工作量的艺术。
11）最好的架构、需求和设计出自自组织团队。
12）团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷可以看作方法论，更多体现在上面的价值观、开发原则上，而具体落地实施，则需要依赖可操作的、具体的开发模式，即我们熟知的极限编程、行为驱动开发、特性驱动开发和Scrum等。下面分别对它们进行简单介绍。
极限编程（eXtreme Programming，XP）是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一，基本思想是“沟通、简单、反馈、勇气”。如同其他敏捷方法学，极限编程和传统方法学的本质的不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、应该被欣然接受的现象；与传统的在项目初始阶段定义好所有需求再费尽心思地控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实、有效的方法。一般认为极限编程对于少于12人的小团队很有用。然而，极限编程在一些超过100人的开发小组中也获得了成功。这就说明极限编程不是不能够推广到更大的团队，而是很少有更大的团队尝试它。
极限编程项目一开始就是收集用户故事（user story，US），用户故事由用户编写，是一段与技术无关的文本，其目的在于提供一些特殊场景的详细描述，而不是用来估计系统的复杂性。用户故事的所有细节必须在它实现之前得到客户的确认。紧接着就是制定发布计划。发布计划确定在系统的哪个发布版本中有哪些用户故事需要实现。每个发布版本都要经过好几次迭代，每次迭代实现一些用户故事，如图1-4所示。一次迭代包括如下阶段。
1）计划：选择要实现的用户故事及其要明确的细节。
2）编码：实现用户故事。
3）测试：至少每个类都要有相应的单元测试。
4）验收测试：用来验证交付的软件是否满足用户需求。如果测试成功，那么新功能开发完成；如果失败，则进入下一个迭代，直至验收测试通过。
图1-4 极限编程流程示意图
相对于Scrum，极限编程更贴近软件开发，有12项优秀实践，如表1-1所示，其中核心的实践是结对编程、测试驱动开发、代码重构、持续集成、代码规范和代码集体所有等。
表1-1 极限编程推荐的软件研发实践
| 编程实践 | 简单设计、代码规范、测试驱动开发、代码重构、结对编程 |
| 团队实践 | 代码集体所有、持续集成、系统隐喻、可持续的节奏 |
| 过程实践 | 现场客户（用户）、计划博弈、小型发布（快速发布） |
1）简单设计。代码的设计只需要满足当前功能的要求，尽可能简单，不多也不少。传统的软件开发理念强调设计先行，在编程之前构建一个完善的、详细的设计框架，其前提是需求稳定。而极限编程拥抱需求变化，认为需求是会经常变化的，因此设计不能一蹴而就，而是一个持续进行的过程。简单设计应满足以下几个原则。
成功执行所有的测试。
不包含重复的代码。
向所有的开发人员清晰地描述编码及其内在关系。
尽可能包含最少的类与方法。
简单的代码更易于工作，简单设计包括系统架构设计，简单的架构有利于设计的重构。
2）代码规范（code standard）更好地保证代码的可读性，有利于代码的重构和维护，而且通过有效的、一致的代码规范来进行沟通，可以尽可能地减少不必要的文档，因为维护文档和产品的一致性是非常困难的一件事情。这里有双重含义。
通过建立统一的代码规范，加强开发人员之间的沟通，同时为代码走查提供了一定的标准。
减少项目开发过程中的文档，极限编程认为代码是最好的文档。
当然，不可能用代码代替所有的文档，只是尽量消除不必要的文档，因为与规范的文档相比，代码的可读性低。
3）测试驱动开发（test-driven development，TDD）与传统开发（开发在前、测试在后）完全不同，强调测试在前、开发在后，即在写产品代码之前先写测试用例（测试脚本），再运行测试用例通过，最后写产品代码让测试通过。代码只有通过测试的时候才被认为完成了。整个软件系统用一种周期化的、实时的、被预先编好的自动化测试方式来保证代码正常运行，这也是彻底的单元测试。
4）代码重构（code refactoring）是指在不改变系统行为的前提下，重新调整，优化系统的内部结构以减少复杂性，消除冗余，提高系统的灵活性和性能。在极限编程中，强调代码重构的作用，是对“简单设计”的补充，改善既有设计，但不是代替设计。重构也是迭代过程所必需的、经常性的活动，特别是在功能实现前后或各个迭代周期的前后。
5）结对编程（pair programming）是指两个（在技能上相当或接近的）开发人员以交替方式共同完成软件的某个功能或组件的代码，即某程序员在写代码的同时，另一个程序员在旁边观察（代码评审），确保代码的正确性与可读性，并以1～3小时的间隔相互交换工作。结对编程可以看作互为评审（peer review）这种实践的最彻底的体现，更能比较彻底地提高代码质量，效率也有可能得到提升。在具体实施时，一些关键的程序代码可以按结对编程方式进行，而其他大部分代码仍可以按传统方式进行，但可以适当加强代码走查和互为评审的力度，如持续代码评审——团队每天留半小时进行代码评审。
6）持续集成（continuous integration，CI）提倡每日构建一个以上的版本，并通过版本的验证，包括自动构建、自动部署和自动测试。持续集成已成为软件研发中非常普遍的一种优秀实践，能够提高代码重构的成功率和代码的质量（即极大地减少回归缺陷），也可以使团队保持一个较高的开发速度。
7）系统隐喻（system metaphor）。与传统软件工程不同的是，极限编程不需要事先进行详细的设计，而是依据可参照和比较的类和设计模式，通过系统隐喻来描述系统如何运作、以何种方式将新的功能加入系统中，在迭代周期中不断地细化架构。对于大型系统，系统架构设计是至关重要的，前期需要一个准备阶段完成这项工作。
8）可持续的节奏。团队只有持久才有获胜的希望，把项目看作马拉松长跑，而不是全速短跑。极限编程提倡健康工作、快乐工作，如实施每周40小时工作制，反对加班，高效地构建高质量的代码。
9）代码集体所有（collective ownership）。开发团队的每个成员都有更改代码的权利，所有的人对全部代码负责，没有程序员对任何一个特定的模块或技术单独负责。这样，程序员不会被限制在特定的专业领域，整个团队的能力、灵活性和稳定性等都得到增强。有时我们也需要认真考虑代码存取权限（代码知识产权保护）、代码有序管理等问题。
10）现场客户（用户）。从理论上要求在整个软件开发过程中，客户一直和研发团队在一起，参与需求的分析、定义和优先级排序（调整），确定验收标准和产品评审，而且能随时回答团队的问题。团队也可以及时、主动地向客户介绍开发状态、演示（半）产品，及时获取客户的反馈。若实施起来有些困难，那么可以采用有效的远程沟通方式，包括电话会议、远程网络会议等，或者让用户代表——产品经理或业务人员等扮演用户角色。
11）小型发布（快速发布）。快速发布是指每次发布的周期要短（2～3周），每次发布的特性要少，从而容易估计每个迭代周期的进度，便于工作量和风险的控制，及时处理用户的反馈。若要做到快速发布，就需要测试驱动开发、代码重构、持续集成等实践的支撑。
12）计划博弈（planning game）要求结合项目进展和技术情况，确定下一阶段开发与发布的系统范围。但随着项目的进展，计划会进行适当调整，一成不变的计划是不存在的。因此，项目团队需要根据项目实际进展情况、需求变更、风险等及时进行项目评估，再根据资源、进度、质量状态、需求优先级等因素来调整或优化项目计划。还有一些具体做法，如项目团队每天举行简短的例会，反思昨天的工作，了解研发过程中的困难，确定当天的主要任务（每日计划）。
1）快速反馈。当反馈能做到及时、迅速时，将发挥极大的作用。开始接触一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，与客户发生接触是反复出现的。客户能够清楚地洞察开发中系统的状况，能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。
2）假设简单。认为任何问题都可以简单的方式解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。
3）增量变化。极限编程的提倡者总是说：罗马城不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。例如，可能每3个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统更为可控。
4）包容变化。可以肯定的是，不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。例如，在一次阶段性会议中，客户提出了一些看起来戏剧性的需求变更。作为程序员，必须包容这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。
在敏捷开发中，一般推荐以用户故事来描述需求。
As a [角色]（作为一个用户角色）
I want to [功能]（我要做什么事）
So that[利益]（达到什么目的）
例如，下面是用户故事的一个具体例子。
我作为账户持有人
我想从ATM提取现金
这样就可以在银行关门后取到钱
虽然相对特性，用户故事粒度比较细，描述了不同用户角色的不同行为，一个特性包含若干个用户故事，但即使对某个角色的某个特定用户行为，其场景不一样，行为还是有较大差别。例如上面那个用户故事，账户持有人的账户被冻结、账户中金额不足、ATM没有现钞等，其结果不一样。因此，仅仅是靠用户故事的描述，需求缺乏可测试性，最好在开发（设计、编码）前明确每个用户的验收标准，这就引出了“行为驱动开发”。
行为驱动开发（behavior-driven development，BDD）是一种敏捷开发的技术，可以看作验收测试驱动开发（acceptance test-driven development，ATDD）的延伸，在软件设计、编程前用场景来定义用户故事的验收标准，通过场景来澄清需求。ATDD只是强调在开发前要先明确每个用户的验收标准。
BDD的根基是一种 “通用语言”。这种通用语言同时被客户和开发者用来定义系统的行为。由于客户和开发者使用同一种“语言”来描述同一个系统，因此可以最大程度地避免因表达不一致而带来的问题。表达不一致是软件开发中常见的问题，由此造成的结果就是开发人员最终做出来的东西不是客户期望的。使用通用语言，客户和开发者可以一起定义系统的行为，从而做出符合客户需求的设计。但如果仅有设计，而没有验证的手段，就无法检验我们的实现是不是符合设计。因此，BDD还是要和测试结合在一起，用系统行为的定义来验证实现代码。
| 行为书写格式 |
|---|
| 故事标题（描述故事的单行文字） |
| 行为实例 |
| 故事：账户持有人提取现金 |
BDD的实践还包括：
确立不同利益相关者要实现的远景目标；
使用特性注入方法绘制出达到这些目标所需要的特性；
通过由外而内的软件开发方法，把涉及的利益相关者融入实现的过程中；
使用例子来描述应用程序的行为或代码的每个单元；
通过自动运行这些例子，提供快速反馈，进行回归测试；
使用“应当”（should）来描述软件的行为，以帮助阐明代码的职责，以及回答对该软件的功能性的质疑；
使用“确保”（ensure）来描述软件的职责，以把代码本身的效用从其他单元（element）代码带来的边际效用中区分出来；
使用“模拟”（mock）作为还未编写的相关代码模块的“替身”。
特性驱动开发（feature-driven development，FDD）是由彼得·科德、杰夫·德·卢卡、埃里克·勒菲弗共同开发的一套针对中小型软件开发项目的开发模式。
FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。简单地说，FDD是一个以架构（architecture）为中心的，采用短迭代期，特性（feature）驱动的开发过程。它首先对整个项目建立一个全局的模型轮廓，然后通过两周一次的基于特性设计（design by feature）、基于特性构建（build by feature）的迭代完成项目开发。此处的“特性”是指“用户眼中最小的、有用的特性、功能”，它是可理解的、可度量的，并且可以在有限的时间内（两个星期）实现。由于在FDD中采用了短周期迭代的方式，最小化的特性划分法，因此可以对项目的开发进程精确且及时地进行监控。
在FDD中，将开发过程划分为如下4个阶段，如图1-5所示。
（1）开发一个全局的模型
在有经验的组件/对象建模专家（首席架构师）指导下，业务领域需求人员与开发人员一起协调工作，业务领域需求人员提供一个初始的、具有一定高度的、可以覆盖整个系统和业务场景的介绍，业务领域需求人员和开发人员会依此产生初始的模型，然后组成单独小组，进入详细讨论阶段，将模型轮廓描绘出来，最后丰富之前产生的初始模型。
（2）建立特性列表
当初始模型产生以后，就开始构建特性列表（feature list），体现为下面的形式。
<action>the<result><by|for|of|to>a(n)<object>上述的形式就是动作、主体、结果的关系，每个动作行为发生都是围绕一个对象为主体的。建立特性列表就是将这些特性进行分类、合并和整理，如功能需求中有用户注册、用户修改注册资料和用户登录等功能，那么输入特性列表中之后就可能是围绕对象模型用户（user）的新增、修改、删除及查询等功能。
图1-5 FDD开发过程
（3）依据特性制定计划
这步的工作就是将这些特性进行排序和计划，然后分配给相应的程序员组。
（4）依据特性进行设计和构建
程序员组针对自己的特性列表按迭代进行设计和构建。
每次迭代的内容如下。
工作包的启动会议：详细描述被包括的特性。
设计：创建必需的类、方法及相关文档。
设计评审：对提供的设计进行评审，接受或者拒绝。
开发：实现并进行单元测试。
代码评审会：执行代码同级评审。
发布会：将已实现的特性进行集成。
在敏捷开发模型中，现在比较流行的是Scrum。Scrum（源于：英式橄榄球运动）将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权、高度自我管理意识，紧密地进行沟通与合作，以高度弹性的方式面对各种挑战，确保每天、每个阶段都向着目标明确地进行推进。
Scrum开发流程通常以2～4周（或者更短的一段时间）为一个阶段，以客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时按优先级挑选应该完成的部分，开发团队必须尽力在这个阶段交付成果。团队每天用15分钟开会检查每个成员的进度与计划，了解所遇到的困难并设法解决。
Scrum是一种迭代式增量软件开发过程，包括一系列实践和预定义角色的过程骨架。其流程如图1-6所示。
图1-6 Scrum开发流程
1）承诺（commitment）：鼓励承诺，并授予承诺者实现承诺的权力。
2）专注（focus）：集中精力做好工作，关注并完成承诺。
3）公开（openness）：Scrum提倡公开、透明，无论是计划会议、平时工作、每日站会，还是最后的总结反思，都需要大家公开信息，以确保大家及时地了解工作进度，如有问题及时采取行动来解决。
4）尊重（respect）：团队是由不同个体组成的，成员之间相互尊重是很有必要的。
5）勇气（courage）：有勇气对任务进行承诺，采取行动完成任务。
1）产品负责人（product owner）：负责维护产品需求的人，代表利益相关者的利益。
2）Scrum Master：其为Scrum过程负责的人，确保Scrum的正确使用并使得Scrum的收益最大化，负责解决一些阻碍项目进展的问题。
3）开发人员（developer）：Scrum团队中致力于创建每个迭代可用增量的研发人员。
按照对开发过程的参与情况，Scrum还定义了其他一些角色，这些角色被分为两组，即“猪”组和“鸡”组。这个分组的方法来自于一个关于猪和鸡合伙开餐馆的笑话，如图1-7所示。
图1-7 猪和鸡合伙开餐馆的笑话
一天，一头猪和一只鸡在路上散步。鸡对猪说：“我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行”，猪说，“我把自己全搭进去了，而你只是参与而已。”
1）“猪”的角色。猪是在Scrum过程中全心投入项目的各种角色，在项目中承担实际工作，他们有些像这个笑话里的猪。产品负责人、Scrum Master和开发团队都是猪的角色。
2）“鸡”的角色。鸡并不是实际Scrum过程的一部分，是利益相关者，必须考虑他们。敏捷方法的一个重要方面是使得利益相关者参与到过程中的实践，如参与迭代的评审和计划，并提供反馈。用户（客户）、供应商、经理等对项目有影响，但又不实际参与项目的角色都是“鸡”组成员。
1）产品待办事项列表（product backlog）：按照优先级排序的产品待办事项。
2）迭代待办事项列表（sprint backlog）：要在迭代中完成的任务清单。
3）迭代燃尽图（burndown chart）：在迭代长度上显示所有剩余工作时间（逐日递减）的图，因整体上总是递减而得名。新的Scrum指南将迭代定义为“工件”。
1）迭代计划会（sprint planning meeting）：在每个迭代之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
2）每日站会（daily standup）：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
3）评审会（review meeting）：迭代结束前向产品负责人演示并接受评价的会议。
4）反思会（retrospective meeting）：迭代结束后召开的关于自我持续改进的会议。
5）迭代（sprint）：一个时间周期（通常为2周～1个月），开发团队会在此期间完成所承诺的一组需求项的开发。
Scrum模型的一个显著特点就是能够尽快地响应变化。于是，随着软件复杂度的增加，Scrum模型的项目成功的可能性相比传统模型要高一些，如图1-8所示。
图1-8 Scrum模型和传统模型的成功可能性对比
Scrum使我们能在最短时间内关注最高的商业价值。它使我们能够迅速、不断地检验可用软件，以此来确定是立即进行发布还是通过下一个迭代来完善。
与此同时，麻省理工学院（MIT）的詹姆斯·P. 沃麦克等几位教授在研究日本的生产体系（特别是丰田生产体系）之后，提炼、总结了丰田公司的生产方式和多年实践，出版了《改变世界的机器：精益生产之道》，精益生产的概念开始为世人所认知和效仿。这里借用了“精益”来描述改善效率的这套体系，包括消除浪费（muda）、减少波动（mura）和降低负荷（muri）。后来，玛丽·波彭代克和汤姆·波彭代克将传统的精益生产原则应用于软件开发，并在敏捷开发会议上进行了多次演讲，从而让敏捷开发社区逐渐接受了“精益软件开发”这个概念。
知识点：丰田模式
为了帮助读者更好地理解敏捷开发模式，下面介绍丰田模式的关键原则和要素。
丰田模式的关键原则归纳如下。
1）建立看板体系（kanban system），改变传统由前端经营者主导生产数量的方式，重视后端顾客需求，即按“逆向”思维方式去控制生产数量。
2）强调实时存货（just in time），在必要的时候，生产必要的量。
3）标准作业彻底化，对生产每个活动、内容、顺序、时间控制和结果等所有工作细节都制定了严格的规范。
4）排除浪费，即排除生产现场的各种不正常与不必要的工作或动作而造成的时间和人力的浪费。
5）重复问5次为什么，透过现象看本质，以严谨的态度打造完善的生产任务流程。
6）生产平衡化，即“取量均值性”，目的是将需求与供应达成平衡，降低库存与生产浪费。
7）充分运用“活人和活空间”，即鼓励员工都成为“多能工”以创造最高价值。
8）养成自动化习惯，对不符合条件的东西进行自动监视管理，包括对人操作不规范的自动监控。
9）弹性改变生产方式，来解决现场生产问题。
为了实现这些原则，丰田模式需要4个要素（4P）构成完整的丰田体系。
1）长期理念（philosophy）：这就需要建立学习型和高效的组织，绝不松懈地坚持质量，以适应环境的变迁，能够长期为顾客及社会创造与提升价值。
2）正确的流程（process）：流程是以低成本、稳定与高效地达成最佳质量的关键。
3）借助员工与合作伙伴（people and partner）的发展，为组织创造价值。因为人是决定因素，所以要尊重员工的智慧和能力，并不断激励他们，以便他们做得更好。
4）持续解决根本问题（problem）是学习型组织的驱动力：学习型组织强调持续学习，而持续学习的核心在于辨识问题的根源，并预防问题的发生，持续改进。
与精益生产原则的概念相近，精益软件开发可以总结为如下7条原则。
1）尊重一线人员。工作在一线的人最了解实际情况，特别是智力劳动活动，如软件开发人员熟知自己所用的工具、流程和规则，更清楚现状、风险和将要发生什么，能制定更好的应对措施，更有能力提出正确的改进意见。
2）消除浪费。任何不能为客户增加价值的行为即是浪费，如不明确的需求、不必要的功能、被废弃的代码、缺陷、等待处理、低效的内部沟通、某个开发环节的延迟、过度的管理等。为了消除浪费，必须以价值流来识别浪费，并指出浪费的根源并消除它，识别和消除浪费的过程是持续不断的。
3）增强学习。软件开发是持续学习的过程，从而能够面对各种挑战。最佳的改善软件开发环境的做法之一是增强学习，如：
代码完成后马上进行测试可以避免缺陷的累积；
通过给最终客户演示产品快速收集用户的反馈来明确用户的需求；
使用短周期的迭代（含重构和集成测试）可以加速学习过程。
4）尽量延迟决定。直到能够基于事实而非不确定的假定和预测来做出决定，因为软件开发中存在许多不确定性，包括需求、设计和工作量估算等。系统越复杂越能够容纳变化，使我们有空间可以推迟一些关键的决定。
5）构建质量。质量不是检验出来的，而是在整个开发过程中构建出来的（即慢慢形成的）。如果在开发的各个阶段（需求、设计、编程等）都能保证产出物的质量，就能以最低的成本达到产品的质量目标，即最大程度地减少浪费。
6）快速交付。只有将产品交付给用户，才产生价值。交付越快，进入市场越早，客户就能更早地使用产品，使产品尽早产生价值。
7）整体优化。局部的优化若不能带来整体的改善，将是没有价值的。
看板（kanban）源自精益生产，成为精益软件开发的一种实践或工具，正如丰田生产方式之父大野耐一所说：“丰田生产方式的两大支柱是‘准时化’和‘自働化’，看板是运营这一系统的工具。”看板可以看作一种可视化卡片，随时呈现生产工序中组件流动状态，从而改善协作、优化管理，显著提高交付速度，更有效地控制生产过程，减少浪费。
准时化的操作过程如图1-9所示。在需要时，后道工序通过看板向前道工序发出信号——请求一定数量的输入，前道工序只有得到看板发来的请求后，才按需生产，这将带来生产库存［也称为“在制品”（work in progress，WIP）］的降低，甚至实现生产过程零库存，从而达到降低生产成本的目的。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。拉动的源头是最下游的客户价值，也就是客户订单或需求。
图1-9 看板传递信息、拉动价值流的过程
降低库存还能暴露生产系统中的问题。湖水中的岩石是一个经典的隐喻，水位代表库存多少，岩石代表问题。水位高，岩石就会被隐藏，即库存多时，设备故障、质量不达标、停工等待、瓶颈过载等问题都会被掩盖，如图1-10左侧所示。没有了临时库存的缓冲，就会出现“水落石出”的局面——上述问题就会暴露出来。暴露问题是解决问题的先决条件，让问题不断暴露并解决，这样就能持续提升生产率和质量。
图1-10 湖水岩石效应
丰田生产方式的自働化的重点不在于“自动流动”，而在于“自动阻止流动”（auto-no-mation），是指出现问题时（如某个环节有次品），机器能够自动感知异常，并立刻停机。这相当于把人的智慧赋予了机器，因此用“働”而非“动”。传统的自动生产线，不能感知异常状态，继续生产次品，造成较大的浪费。丰田生产方式的自働化把质量内建于每一个生产环节，出现异常时，杜绝继续产出次品，并且不把次品输入下一环节。这是“内建质量”（build in quality），而不是让质量依赖于最后的检测环节。因为立刻停机，所以需要马上解决问题或逼着问题被快速解决，从而形成 “停止并修正”（stop and fix）的企业文化，构建企业持续改进的坚实基础。
精益生产在丰田取得成功，但软件开发和制造业差别很大，例如软件比较抽象、需求具有很大的不确定性、每一个开发的任务都不相同等，因此无法照搬精益生产的实践，我们需要从软件开发自身特点出发，发展一套精益软件开发的实践体系，其中为此做出杰出贡献的有玛丽·波彭代克、唐· G. 赖纳特森和大卫·J. 安德森等人，其中赖纳特森致力于揭示产品开发流的本质，并提出相匹配的原则方法，在其著作《产品开发流程的原理：第二代精益产品开发》（The Principles of Product Development Flow: Second Generation Lean Product Development）中提炼了精益产品开发的175条原则。安德森最早在软件开发中应用看板实践，并不断完善软件开发的看板实践，在其著作《看板方法：科技企业渐进变革成功之道》中详细介绍了看板的价值、原则和5个核心实践。
下面介绍一下这5个核心实践。
软件产品（包括阶段性产品）不是实实在在的物体，而是抽象的信息，为了有利于管理，必须让这些信息可见，即把可视化价值流作为精益软件开发的基础实践，先让价值和价值流具体可见，再进行管理和优化。如图1-11所示是看板开发方法中的一个典型可视化案例，被称为看板墙（kanban wall）。图中的每个卡片代表一个价值项，如功能需求、缺陷、技术概念验证等，它们所在的列表示其所处的阶段。这些价值项，每经过一个阶段（图中的列）都会产生新信息，价值得以增加。例如，需求经过分析阶段，注入了新信息，价值更高。价值流是价值项从左至右的流动过程，是信息产出过程，也是价值增加的过程。
图1-11 可视化价值（工作）流
价值流动可能会被阻碍。例如，编码因对第3方接口错误而无法进展；测试因环境没准备好而停滞。标识阻碍因素并推动其解决，促进价值流动。最终限制整个开发的价值流动的地方就是某些开发环节——瓶颈，于是解决这类瓶颈问题也是改善价值流动的主要任务。发现看板墙上的瓶颈并不困难，找到最长的队列就可以了，如图1-11中的“测试”列。这与我们平常所见到的“道路越拥堵，排队的车就越多”是一样的道理。
显式化流程规则是指明确定义和沟通团队所遵循的流程规则，如团队协作规则、需求评审规则等。价值项的“流转规则”是看板开发方法中典型的流程规则——定义了一个价值项从某个阶段进入下一阶段所必须满足的要求（类似流程中常用的入口/出口准则），如从敏捷需求分析进入实施阶段的流程规则，可能包括：
1）绘制了明确的业务流程图；
2）为每个用户故事定义了验收标准；
3）定义了不同组件之间的接口或数据结构；
4）所有定义的内容通过了评审。
流程规则的显式化让质量内建于各个阶段——这与精益生产中内建质量的思想是一致的，而且可以基于规则进行持续改进。没有显式化的规则作为依据，讨论改进就没有基础，而变得主观和随意。改进的结果通常是进一步完善显式化的规则，正如传统软件开发中，也强调“先定义流程，再持续改进流程”。
限制在制品（WIP）数量是看板开发方法的核心机制。如图1-12所示，各个阶段下的数字标识了该阶段允许的WIP数量上限。在WIP数量小于上限时，才可以从上一环节拉入新的工作，如需求分析与定义、设计阶段WIP数量分别是3、2，小于上限（4），因此可以拉入新的工作。如果WIP数量达到上限，如测试阶段WIP数量是6，达到了上限，就不允许拉入新工作。
限制WIP数量形成一个更有效的拉动机制，减少了价值项在阶段间的排队等待，缩短了软件交付的时间，加速了价值流动。同时，限制WIP数量，让湖水岩石效应产生作用，更快地暴露问题，推进团队解决问题，提升研发效能。
快速、顺畅的价值流动是看板开发方法的目标，以带来稳定和可预测的价值交付能力，以及快速的价值产出和快速反馈，确保具有很强的业务竞争力。度量为改善价值流动和客户反馈提供客观的数据，其中累积流量图是常用的一种度量方法，如图1-13所示，虚线是累积已经开始的价值项（如用户故事）数量，实线是累积完成价值项的数量，实线的斜率反映的是价值交付的速率，即每周可交付的价值项数量。两条曲线的垂直距离表示某个时刻已经开始但未完成的价值项数量，即这个时刻的WIP数量。两条曲线的水平距离表示功能从开始到完成的周期，它是价值流动效率的一个重要衡量。
图1-12 限制在制品（WIP）数量
图1-13 累积流量图
累积流量是一种不错的价值流度量方法，但要看某个时刻（某周）WIP具体数量时，还不够方便，这时也可以WIP数量或系统流量（每周交付价值的数量）的实时曲线、直方图等方式来描述，更能准确地呈现WIP数量或交付周期的变化趋势。
应用可视化、限制WIP数量和价值流度量，能够暴露产品开发中的问题和瓶颈。但发现问题还不够，重要的是如何解决问题。为了更好地解决问题，团队协作是必需的。例如，图1-12展示了测试阶段WIP数量达到上限，不能从上游“实现”拉入更多的工作。这样，实现阶段已完成的工作无法进入下游“测试”环节，实现阶段的WIP数量很快也会达到上限，也无法开展新的工作。要改变这种状态，开发人员就必须关注下游的问题，并做出反应，如提高代码质量或向测试人员提供帮助。开发人员和测试人员的协作使价值流动更加顺畅。通过拉动机制，看板暴露了限制价值流动的瓶颈，并激发团队协作，改善价值流动，最终提升端到端的价值流转，实现产品开发的目标。
很多时候解决瓶颈问题的方案在别处，例如上面所讨论的，解决测试的瓶颈最有效的办法之一是提高上游的代码质量，即瓶颈之前环节的输出质量，调整职责分配，甚至重新设计价值流。为了彻底解决问题，我们需要系统性地分析问题和解决问题，如采用运筹学、排队理论等科学方法来解决问题。
最后总结一下，看板不是一个开发框架或流程，而是一种引导改革的方法或实践，需要结合企业的实际情况来实施，包括流程的可视化、设定合适的WIP数量上限并辅以度量，通过上述拉动机制来暴露问题，并借助团队协作解决问题，持续改进，不断优化相关的流程、WIP数量上限的值，获得高效、顺畅的产品开发价值流。
DevOps可以看作敏捷的延伸，将敏捷思想延伸到运维，从覆盖软件研发周期延伸到覆盖整个软件生命周期。敏捷侧重消除产品、开发与测试之间的隔阂，让研发人员与测试人员、用户更好地融合与协作，加速持续集成、持续交付的过程。DevOps则推倒整个研发与运维之间的一堵墙，让研发和运维贯通，更彻底地实现可靠的持续交付。
在软件研发项目中，从一开始就考虑软件部署和运维的需求，在系统架构设计阶段将系统运维的需求融入，甚至完成系统部署的逻辑设计和物理设计，并开发运维工具。软件部署之后，研发部门也给予大力支持，而且需要进行部署验证（PQA），以客户需求为中心，运维和研发是贯通的、协作的，没有在两个部门之间形成一座高高的隔离墙，这基本就是DevOps（Development和Operations的组合）。DevOps代表一种文化、运动或实践，旨在促进软件交付和基础设施变更中软件开发人员（Dev）和IT运维技术人员（Ops）之间的合作和沟通，使软件发布更加快捷和可靠，真正做到持续交付、持续运维。
虽然DevOps这个概念现在还没有标准的定义，但我们可以追溯一下其发展过程（2009～2017年），列出几个相对明确又有所不同的定义，从而能够比较全面地了解DevOps的内涵。
2009年：DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保证（quality assurance，QA）部门之间的沟通、协作与整合。
2011年：快速响应业务和客户的需求，通过行为科学改善IT各部门之间的沟通，使软件交付能够适应业务快速变化的需求。
2015年：DevOps强调沟通、协作、集成、自动化和度量，以帮助组织快速开发软件产品，并提高操作性能和质量保证；强调自动化软件交付和基础设施变更的过程，以建立一种文化和环境，通过构建、测试和发布软件等方法，可以快速、频繁、更可靠地发布软件。
2016年：DevOps的目标是建立流水线式的、准时化的业务流程，以获得最大化业务成果，如增加销售量和利润率，提高业务速度，减少运营成本。
2017年：一个软件工程实践，旨在统一软件开发（Dev）和软件操作（Ops），与业务目标紧密结合，在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控。DevOps的目标是缩短开发周期，增加部署频率，更可靠地进行发布。
简单地说，DevOps是敏捷开发的自然延伸，从研发周期向右扩展到部署、运维，由持续构建、持续集成扩展到持续部署、持续运维，真正做到持续交付（continuous delivery，CD）。DevOps不但打通研发的“需求、开发与测试”各个环节，而且打通“研发”与“运维”。DevOps适合“软件即服务”（SaaS）或“平台即服务”（PaaS）这样的应用领域，其显著的特征如下。
1）打通用户、项目管理办公室、需求、设计、开发、测试、运维等各上下游部门或不同角色。
2）打通业务、架构、代码、测试、部署、监控、安全、性能等各领域工具链。
DevOps在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控，形成软件研发完整的生态。这很大程度上依赖于工具，在DevOps上现在已形成完整的工具链。
图1-14相对简单地展示了DevOps工具链，包含了常见的5类工具（构建、测试、工件管理、部署和评估），而相对完整的DevOps工具链，需要覆盖14类工具，按交付过程列出如下。
图1-14 贯穿软件生命周期的DevOps工具链[1]
1）编码/版本控制：维护和控制源代码库中的变更。
2）协作开发：在线评审工具和在线会议平台等。
3）构建：版本控制、代码合并和构建状态。
4）持续集成：完成自动构建、部署和测试等调度。
5）测试：自动化测试开发与执行、生成测试报告等。
6）打包：二进制仓库和Docker镜像仓库。
7）部署：完成在服务器（集群）上自动部署软件包。
8）容器：容器是轻量级的虚拟化组件，它以隔离的方式运行应用负载。它们运行自己的进程、文件系统和网络栈，这些资源都是由运行在硬件上的操作系统所虚拟化出来的。
9）发布：变更管理、发布审核和自动发布。
10）编排：当考虑微服务、面向服务的架构、融合式基础设施、虚拟化和资源准备时，计算系统之间的协作和集成就称为编排。通过利用已定义的自动化价值流，编排保证了业务需求是和团队的基础设施资源相匹配的。
11）配置管理：基础设施配置和管理，维护硬件和软件最新、细节的记录，包括版本、需求、网络地址、设计和运维信息。
12）监视：性能监视和用户行为反馈。
13）警告与分析工具：根据事先设定的“警戒线”发出警告，日志分析、大数据分析等。
14）应用服务器、数据库、云平台等维护工具。
本章是为后续各章的学习而做的铺垫。首先让读者了解敏捷开发模式的由来，从而帮助读者更好地理解敏捷开发的价值观和原则。只记住《敏捷宣言》和12项原则是不够的，要理解其产生背后的真正原因，包括当今软件开发所面临的挑战。市场驱动业务，业务驱动研发。急剧的市场竞争和快速的市场变化都驱动软件研发的变革，以做到持续交付。持续交付是敏捷开发的核心诉求，无论是极限编程、BDD、FDD，还是Scrum，都是为了实现这一诉求，包括采用一些优秀实践，如全功能的特性团队、ATDD、持续集成和DevOps工具链等。
| 基本实践 |
扩展实践 |
|---|---|
关于敏捷的资料和图书有很多，于是我们可以从为什么会产生敏捷这个问题出发来加强学习，如阅读《敏捷整洁之道：回归本源》。
虽然现在流行采用Scrum开发模式，但它缺少软件研发的优秀实践，而极限编程是真正基于软件开发特点而构建的开发模式，更有利于我们理解敏捷开发，因此可以阅读极限编程相关的文章和图书，特别推荐去了解一下马丁·福勒、肯特·贝克等人如何将极限编程方法第一次引入C3项目，相关资料包括贝克编写的《解析极限编程：拥抱变化》《测试驱动开发：实践与模式解析》，以及福勒的个人网站和他编写的《规划极限编程》（Planning Extreme Programming）一书。
只了解敏捷还不够，还需要了解精益软件开发、DevOps。关于精益软件开发，可以阅读《精益开发实战：用看板管理大型项目》或《精益开发与看板方法》。而关于DevOps，可以阅读《凤凰项目：一个IT运维的传奇故事》和《DevOps实践指南》。
最后补充一点关于极限编程实践的内容，贝克在1999年出版了《解析极限编程：拥抱变化》，此书的第2版在2004年出版，在原来的基础上做了一些修改和扩展，并给出13项基本实践和11项扩展实践，如表1-2所示。不过比较而言，最初的12项实践还是更为人们所接受。
表1-2 基本实践与扩展实践
[1] 马致杰的“一站式软件交付：世界五百强企业中的DevOps转型之道”演讲材料。
