卓有成效的敏捷

版权信息

书名：卓有成效的敏捷

ISBN：978-7-115-56491-7

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版　　权

著    ［美］史蒂夫·迈克康奈尔（Steve McConnell）

译    任发科 林从羽

审  校 韩 磊 陈连生

责任编辑 郭 媛

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

版权声明

More Effective Agile: A Roadmap for Software Leaders by Steve McConnell,

ISBN-13: 978-1733518215,

Published by arrangement with Steve McConnell.

All rights reserved.

本书中文简体版由作者史蒂夫·迈克康奈尔授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制和传播。

版权所有，侵权必究。

内 容 提 要

“敏捷”一词已成为涵盖各种价值观、原则和实践方法的统称，敏捷实践已成为众多高效能软件组织的制胜之道。然而近年来，新的敏捷实践百花齐放，作为软件开发组织领导者，如何识别有效的敏捷实践方法？如何通过有效的软件开发实现更多的业务功能？本书作者史蒂夫·迈克康奈尔（Steve McConnell）带领Construx软件公司在数百个软件组织实践与总结后，形成卓有成效的现代敏捷实践路线图。

本书从团队、工作、组织3个维度，系统回答了如何选用适合软件组织的敏捷工具，如何创建真正以业务为中心的高效能、自管理团队，如何了解Scrum并诊断团队问题，如何提高sprint环境中的需求一致性，如何高效测试以提高质量等问题，让软件组织领导者能够突破现实世界中的约束条件，高效地领导软件开发组织。

本书提出的敏捷实践方法经历300多位不同层级管理者的实践，并参考10 000多条严格的评审意见进行打磨，几乎涵盖了卓有成效的敏捷的全部实际考虑，具有极强的普遍适用性。无论你是敏捷教练，还是已采用敏捷开发但对结果不满意的企业领导者、有技术背景但没有现代敏捷实践经验的开发人员、没有技术背景但想了解敏捷相关知识的读者，都能从本书中获得关于敏捷实践的宝贵资源。

推荐辞

（按姓氏拼音）

这本书从软件开发的本质切入，围绕价值、团队、个人、度量、领导力等方面，以实际案例和经验总结为主，娓娓道来，带着读者一步一步深入理解敏捷的精髓。

——姜信宝，《Scrum精髓：敏捷转型指南》译者，Scrum联盟认证Scrum培训师（CST）

敏捷如何在组织内推行与落地？每个人都有自己的答案，就像每个人心中都有一个哈姆雷特。正因如此，这本书的难能可贵之处才得以彰显：这本书不但系统介绍敏捷的理论框架，并且根据过去40年最有价值的经验教训，归纳出28个关键原则，为敏捷的推行与落地提供了方向指引。更为难得的是，每个章节基于理论和原则，给出切实可行的“给领导者的行动建议”。

——姜泳涛，泰康保险集团科技中心敏捷教练

拿到这本书的第一感觉：重复敏捷中老生常谈的基本概念。集中精力、仔细阅读后，越读越有共鸣，尤其是很多阻碍敏捷落地的非敏捷内容，比如驱动力、情商、同侪压力、组织生命周期、变革模型等。我强烈建议你将这本书作为了解敏捷的入门书。它就像一张地图，可以清晰地指明方向，并帮助你快速搭建起敏捷的知识体系。

——李小波，华为外部软件教练，绘玩教育（iPlayABC）CTO，软件匠艺（Coding Style）社区发起人

这本书有两个显著的特点。

一是完备。这本书系统地描述敏捷的方方面面：实践来源、应用场景、组织文化、领导力、团队、需求、管理、技术、质量、交付、度量、过程改进、大型项目组合管理以及受监管行业中的敏捷等。

二是务实。作者没有人云亦云，而是有自己的观察与思考。他更加注重敏捷的关键原则与实际应用效果，基于软件组织的真实案例，灵活地看待敏捷实践，很好地平衡敏捷的理想与现实，澄清关于敏捷的很多误解。

——任甲林，麦哲思科技（北京）有限公司总经理，《术以载道：软件过程改进实践指南》《以道御术：CMMI 2.0 实践指南》作者

这本书提到意识自主、能力专精和目标对齐这个铁三角，直击敏捷组织的本质。只有看透这一本质并付诸行动，才能尽早并高质量地产出“可工作的软件”。

——申健，优普丰敏捷咨询全球合伙人，Scrum联盟认证Scrum培训师（CST）&认证Scrum团队教练（CTC）

这本书有效扩展了基础的敏捷框架及实践，形成针对软件研发从个人、团队到组织文化不同层面的工作指引，比较均衡地考虑到敏捷管理和技术实践的组合应用。当前的组织管理者面对数字化转型的压力，急需大规模构建软件研发能力，阅读本书，正当其时。

——肖然，Thoughtworks 创新总监，中国敏捷教练企业联盟秘书长

敏捷不是几句高度抽象、高度泛化的口号，不是外延无限宽广、内涵无限稀薄的“片儿汤话”，而是一系列非常具体的原则和实践。这本书列出的28个具体问题，穷尽了敏捷各个方面需要考虑的要素，让缺斤少两的伪敏捷无所遁形。

——熊节，极限编程合作社发起人

穿过热闹的场面，拨开华丽的辞藻，静下心来思考成功与失败的敏捷之间到底有何区别，到底哪些才是真正有效的敏捷实践，而不是咨询师为了粉饰履历而抹上的浓妆溢彩。史蒂夫在书中为我们娓娓道来。淡淡的味道，浓浓的回甘。许多曾困扰我多年的疑问，都在这本书中找到了答案。希望你也有同样的收获。

——徐毅，中国敏捷教练企业联盟副秘书长，EXIN全球智库（EPG）成员，EXIN敏捷教练评估师

这本书最大的优点就是针对整个敏捷过程进行了清晰的分类及流程的梳理，让你能够从书中轻松找到自己的困惑点，并且获得相应的行动建议。这本书凭借着300多位敏捷实践者提出的1万多条严格评审，让我在阅读中感受到了文笔思路的统一和字字如金的简短有力。如果你正在落地敏捷，那么这本手册应该随时放在身边，在做什么就看什么，预防“踩雷”的同时抓住落地的关键原则，可以少走不少弯路。

——云层，TestOps 测试运维开拓者，《敏捷测试实战指南》作者

市面上已经有很多讲述敏捷方法和实践的书，但这本书依然非常吸引我，主要有两方面原因。

首先是作者写作的出发点，即始终提倡“卓有成效”。敏捷实践本身并不是目的，其所带来的“卓有成效”的业务结果才是最终目的。这本书分享了大量被经验证明卓有成效的敏捷原则和实践，并没有强调某些死板教条的规则或加入言过其实的华丽包装，每章的内容目标都是解决具体问题，非常接地气。

其次是作者强调敏捷是一种依赖于从经验中学习的经验主义方法，虽然通过行业经验有套路可循，但更重要的是在落地和应用的过程中不断进行检视和调整，在组织、团队、个人层面不断改进和优化，最终才能享受到持续精进带来的胜利果实。

读者可以把这本书作为工具书，带着问题阅读和寻找答案，相信会对你深入理解敏捷大有裨益。

——张乐，京东DevOps 与研发效能技术总监、首席架构师

这本书从卓有成效的团队到卓有成效的工作、组织，覆盖了敏捷开发方式下的方方面面。作者针对每个方面整理出提纲挈领的“关键原则”，并且给出行动建议，帮助读者根据自身的应用环境思考敏捷落地的实施方案。除此之外，这本书也强调了敏捷的文化、领导力、项目管理、质量、测试、可预测性等内容，这些往往是国内敏捷开发中容易忽视的要素。总的来说，这是一部有深度、有温度的敏捷力作，它同时彰显了简洁、开放和灵活的写作风格。

——朱少民，同济大学特聘教授，QECon大会发起人

这本书透过形形色色的敏捷或不太敏捷的现象，针对性阐述了作者对软件开发和团队成长的本质的认识。全书通篇都有许多警句和洞见，如敏捷开发的原则就是缩短反馈循环，又如卓有成效的激励机制是自主、专精和目标的达成。

有人会问：如果我们按照这本书的方法培训了员工，但是他们离职了，这不是亏了吗？

那么反问：如果我们不培训员工，而他们一直留在公司，谁亏得更多呢？

这本书值得所有想让员工和公司成长的组织学习！

——邹欣，CSDN副总裁，《构建之法：现代软件工程》作者

对本书的赞誉

无论你是经理还是高管，无论你是刚开始转向敏捷还是期望改进敏捷，在这本书中你都会找到基于深入研究和广泛经验的实用建议。

——Shaheeda Nizar，谷歌工程主管

在提供以业务/价值为中心的观点的同时，这本书让软件组织领导者能够接触和关注敏捷开发的前沿的核心概念。

——John Reynders，Alexion Pharmaceuticals副总裁

这本书明确指出，敏捷是一组实践手段，这组实践手段源自与业务紧密关联的工作成果，而不仅只是一套要执行的仪轨。

——Glenn Goodrich，Skookum副总裁

这本书的28个关键原则总结了过去40年软件产品开发中最有价值的经验教训，是非常宝贵的学习资料。这本书理论和实践相结合，并使用易懂的语言和清晰的图示使这些原则备受关注。

——Xander Botha，Demonware技术总监

这本书明确指出，对于过去认为应该采用顺序生命周期开发方式的项目，例如需要精确预估时限，或者开发过程受到监管，敏捷方法（如果正确使用的话）能够发挥惊人效果。

——Charles Davies，TomTom CTO

这本书对技术型读者和非技术型读者都非常易读，能够使他们对敏捷达成一致的理解。

——Sunil Kripalani，OptumRx首席数字官

即使敏捷专家也可以从这本书中找到重振使用敏捷方法信心的精神食粮。

——Stefan Landvogt，微软首席软件工程师

许多理想化的敏捷方法在面对复杂的现实情况时败下阵来。这本书是穿越敏捷实施迷宫的一盏非凡的指路明灯，它描述了要寻找什么（检视）以及如何应对所发现的情况（调整）。

——Ilhan Dilber，CareFirst质量与测试总监

令人耳目一新的是，这本书避免了敏捷教条，并解释了如何使用那些适合业务需要的敏捷实践。

——Brian Donaldson，Quadrus董事长

人们常常（错误地）认为，采用敏捷就会失去可预测性，而不认为可预测性恰恰是敏捷所能带来的好处。

——Lisa Forsyth，Smashing Ideas高级总监

简洁、实用，内容对得起书名。这本书对那些想让敏捷过程更有效的软件组织领导者特别有价值，对刚刚开始或者正在考虑转向敏捷的领导者来说也非常有用。

——David Wight，Calaveras集团顾问

这本书全面介绍了如何卓有成效地实现敏捷并不断改进，使敏捷不仅仅停留在起步阶段。许多书关注如何开始，但很少有书分享保持继续前行的有用知识和具体工具。

——Eric Upchurch，Synaptech首席软件架构师

这本书总结真实经验，将创建现代软件密集型系统的各个方面——技术、管理、组织、文化和人——汇集成易于理解、连贯、可操作的整体。

——Giovanni Asproni， Zuhlke 工程有限公司首席顾问

要敏捷发挥作用，大组织需要如何去做？这本书对此给出了出色的建议，如敏捷边界、变更管理模型、项目组合管理，以及可预测性与管控之间的平衡。

——Hiranya Samarasekera，Sysco LABS工程副总裁

这本书提供了简洁有力的陈述，为那些以软件为主要工作的个人和公司提供了有价值的东西，并且书中的许多概念基本上适用于任何行业。

——Barbara Talley，Epsilon总监、业务系统分析师

这本书是最佳实践、挑战、行动以及拓展资料的权威来源，这本书也是我和团队的首选学习资料。我有时很难解释敏捷实践以及如何让它们卓有成效，这本书做得非常出色。

——Graham Haythornthwaite，Impero Software技术副总裁

这本书教你如何将敏捷看作一组工具：在环境需要敏捷时有选择性地应用它们，而不是要么不用要么全用。

——Timo Kissel，Circle Media工程高级副总裁

这是一本优秀的书，彻底回答了“为什么使用敏捷？”这个问题。

——Don Shafer，Athens集团首席保险、安全、健康和环境执行官

刚开始使用敏捷的人，可以直接阅读“卓有成效的敏捷实施”这一章（第23章）。我见过太多组织进行“完全敏捷”却没有建立适当的基础来确保其成功。

——Kevin Taylor，亚马逊高级云架构师

这是一本了不起的书，充满了极其有用的信息，即使经验丰富的从业者也能学有所得。这正是目前稀缺的能够务实地应用敏捷实践的手册。

——Manny Gatlin，Bad Rabbit专业服务副总裁

这本书没有夸夸其谈，而是直接告诉我起作用的东西以及其他人发现有用的东西，包括围绕文化、人和团队的软性问题，也包括过程和架构。考虑到这本书的篇幅，其覆盖深度令人惊讶！

——Mike Blackstock，Sense Tecnic Systems CTO

这本书是对敏捷这个20年的方法论的诚实审视，而且这可能是第一本直接针对软件组织领导者并告诉他们如何实施的书。

——Sumant Kumar，SAP工程开发总监

我很欣赏关于在任何环境中都有帮助的、激励个人和团队的领导特质的讨论。我们常常把人为因素视为理所应当而只注重流程性的因素。

——Dennis Rubsam，Seagate高级总监

来自传统项目管理文化的领导者常常难以掌握敏捷概念。这本书对这类领导者颇有启发。

——Paul van Hagen，壳牌全球解决方案国际有限公司
平台架构师和软件卓越经理

这本书不仅提供了如何搭建卓有成效的敏捷团队的关键见解，还提供了组织领导者如何与其开发团队配合，确保项目成功。

——Tom Spitzer，EC Wise工程副总监

这是快速变化的软件世界所急需的资料，目前不同行业越来越迫切地需要交付更多、更快。

——Kenneth Liu，Symantec高级总监

这本书为所有类型的软件开发实践者提供了有价值的独到见解和经验教训——业务负责人、产品负责人、分析师、软件工程师和测试人员。

——Melvin Brandman，Willis Towers Watson首席技术顾问

这本书为想要改进现有敏捷项目的领导者或者正在实施敏捷的领导者，提供了全面的参考，涵盖了敏捷领导力的方方面面。

——Brad Moore，Quartet Health工程副总裁

这本书已被证明是可以提升敏捷团队水平的，是非常有价值的原则摘要。除了信息，还有许多有价值的经验也被收集到这本书中。

——Dewey Hou，TechSmith公司产品开发副总裁

这本书是实施敏捷的一面好镜子——让你的实施过程与其保持一致，就能看到积极和消极的两个方面。

——Matt Schouten，Herzog Technologies产品开发高级总监

5年前我正在公司推行敏捷实施的时候就有这本书该多好啊！它澄清（并言中）了我们遇到的许多问题。

——Mark Apgar，Tsunami Tsolutions产品设计经理

大多数公司可能认为他们拥有“敏捷”开发过程，但他们也许缺少许多可以让其过程变得更好的关键环节。作者从对软件开发的研究和他在Construx 软件公司的个人经验中汲取精华，并将这些知识凝练成一份简明的资料。

——Steve Perrin，Zillow高级开发经理

这本书解决了许多多年来我们一直为之苦苦挣扎的问题。如果在我们开始自己的旅程时就有这本书，对我们应该会非常有帮助。书中的“给领导者的行动建议”棒极了!

——Barry Saylor，Micro Encoder公司副总裁

这本书代表了20年敏捷实施实践经验的巅峰。如同《代码大全》在20世纪90年代成为软件开发人员的权威手册一样，这本书将在接下来10年成为敏捷倡导者的权威手册。

——Tom Kerr，ZOLL Medical嵌入式软件开发经理

致  谢

首先感谢在Construx 软件公司的技术同事。我很幸运能与一群聪明无比、才华横溢且经验丰富的员工一起工作，本书主要是我们集体经验的总结，没有他们的贡献本书将无法付梓。感谢咨询副总裁Jenny Stuart，感谢她在大规模敏捷实施方面的非凡经验和见解。我很欣赏她有关驾驭大型组织的组织问题的见解。感谢首席技术官 Matt Peloquin在软件架构方面的经验——他在领导了超过500次架构评审后已独步天下了，这些经验在敏捷实施上发挥了很大作用。感谢高级研究员、卓越的咨询师和导师Earl Beede，感谢他洞悉展现敏捷概念的最清晰的方式，让团队理解并高效地实施敏捷。感谢高级研究员Melvin PérezCedano将全世界的经验和丰富的书本知识相结合。谢谢Melvin，他是我这个项目的活样本，也是最行之有效实践的关键指南。感谢高级研究员Erik Simmons在不确定性和复杂性研究方面浩瀚无垠的知识以及他在大型传统企业实现敏捷实践方面的专家级的指导。感谢首席咨询师Steve Tockey对传统严谨软件实践以及它们与敏捷如何相互作用的深刻洞察和无与伦比的基础知识。感谢高级研究员Bob Webber对敏捷产品管理的深入理解——他几十年的领导经验帮助本书满足领导者的需要。最后，感谢敏捷实践负责人John Clifford，感谢他鼓励、指导、劝告甚至偶尔强迫组织认识到他们实施敏捷所应该得到的所有价值。多么棒的团队！我如此幸运能与这些人共事。

超过300位软件行业领导者阅读了本书的初稿并提供了评审意见。这本书因他们的无私奉献而更加完美。

特别感谢Chris Alexander，感谢他对OODA的深刻解释并提供出色的示例。特别感谢Bernie Anger，感谢他针对成功的产品负责人角色的广泛评论。特别感谢John Belbute，感谢他对度量和过程改进的深刻意见。特别感谢Bill Curtis和Mike Russell，感谢他们就我对PDCA的一些错误概念提出批评（这些错误概念已不在本书中）。特别感谢Rob Daigneau对架构和CI/CD的评论。特别感谢Brian Donaldson对估算的深入评审。特别感谢Lars Marowsky-Bree和Ed Sullivan，感谢他们对分布式团队成功所需因素的全面评论。特别感谢Marion Miller描述了应急响应团队的组织方式以及其与敏捷组织间的关联和关系。特别感谢Bryan Pflug对航空航天条例下软件开发的广泛评论。

感谢如下审稿人，他们分别审读了书稿的一些部分：Mark Abermoske，Anant Adke，Haytham Alzeini、Prashant Ambe、Vidyha Anand、Royce Ausburn、Joseph Balistrieri、Erika Barber、Ed Bateman、Mark Beardall、Greg Bertoni、Diana Bittle、Margaret Bohn、Terry Bretz、Darwin Castillo、Jason Cole、Jenson Crawford、Bruce Cronquist、Peter Daly、Brian Daugherty、Matt Davey、Paul David、Tim Dawson、Ritesh Desai、Anthony Diaz、Randy Dojutrek、Adam Dray、Eric Evans、Ron Farrington、Claudio Fayad、Geoff Flamank、Lisa Forsyth、Jim Forsythe、Robin Franko、Jane Fraser、Fazeel Gareeboo、Inbar Gazit、David Geving、Paul Gower、Ashish Gupta、Chris Halton、Ram Hariharan、Jason Hills、Gary Hinkle、Mike Hoffmann、Chris Holl、Peter Horadan、Sandra Howlett、Fred Hugand、Scott Jensen、Steve Karmesin、Peter Kretzman、David Leib、Andrew Levine、Andrew Lichey、Eric Lind、Howard Look、Zhi Cong (Chong) Luo、Dale Lutz、Marianne Marck、Keith B. Marcos、David McTavish、J.D. Meier、Suneel Mendiratta、Henry Meuret、Bertrand Meyer、Rob Muir、Chris Murphy、Pete Nathan、Michael Nassirian、Scott Norton、Daniel Rensilot Okine、Ganesh Palave、Peter Paznokas、Jim Pyles、Mark Ronan、Roshanak Roshandel、Hiranya Samarasekera、Nalin Savara、Tom Schaffernoth、Senthi Senthilmurugan、Charles Seybold、Andrew Sinclair、Tom Spitzer、Dave Spokane、Michael Sprick、Tina Strand、Nancy Sutherland、Jason Tanner、Chris Thompson、Bruce Thorne、Leanne Trevorrow、Roger Valade、John Ward、Wendy Wells、Gavian Whishaw和Howard Wu。

感谢如下审稿人，他们对整个书稿给出了评论意见：Edwin Adriaansen、Carlos Amselem、John Anderson、Mehdi Aouadi、Mark Apgar、Brad Appleton、Giovanni Asproni、Joseph Bangs、Alex Barros、Jared Bellows、John M. Bemis、Robert Binder、Mike Blackstock、Dr. Zarik Boghossian、Gabriel Boiciuc、Greg Borchers、Xander Botha、Melvin Brandman、Kevin Brune、Timothy Byrne、Dale Campbell、Mike Cargal、Mark Cassidy、Mike Cheng、George Chow、Ronda Cilsick、Peter Clark、Michelle K. Cole、John Connolly、Sarah Cooper、John Coster、Alan Crouch、James Cusick、David Daly、Trent Davies、Dan DeLapp、Steve Dienstbier、Ilhan Dilber、Nicholas DiLisi、Jason Domask、David Draffin、Dr. Ryan J. Durante、Jim Durrell、Alex Elentukh、Paul Elia、Robert A. Ensink、Earl Everett、Mark Famous、Craig Fisher、Jamie Forgan、Iain Forsyth、John R Fox、Steven D. Fraser、Steve Freeman、Reeve Fritchman、Krisztian Gaspar、Manny Gatlin、Rege George、Glenn Goodrich、Lee Grant、Kirk Gray、Matthew Grulke、Mir Hajmiragha、Matt Hall、Colin Hammond、Jeff Hanson、Paul Harding、Joshua Harmon、Graham Haythornthwaite、Jim Henley、Ned Henson、Neal Herman、Samuel Hon、Dewey Hou、Bill Humphrey、Lise Hvatum、Nathan Itskovitch、Rob Jasper、Kurian John、James Judd、Mark Karen、Tom Kerr、Yogesh Khambia、Timo Kissel、Katie Knobbs、Mark Kochanski、Hannu Kokko、Sunil Kripalani、Mukesh Kumar、Sumant Kumar、Matt Kuznicki、Stefan Landvogt、Michael Lange、Andrew Lavers、Robert Lee、Anthony Letts、Gilbert Lévesque、Ron Lichty、Ken Liu、Jon Loftin、Sergio Lopes、Arnie Lund、Jeff Malek、Koen Mannaerts、Risto Matikainen、Chris Matts、Kevin McEachern、Ernst Menet、Karl Métivier、Scott Miller、Praveen Minumula、Brad Moore、David Moore、Sean Morley、Steven Mullins、Ben Nguyen、Ryan North、Louis Ormond、Patrick O’Rourke、Uma Palepu、Steve Perrin、Daniel Petersen、Brad Porter、Terri Potts、Jon Price、John Purdy、Mladen Radovic、Venkat Ramamurthy、Vinu Ramasamy、Derek Reading、Barbara Robbins、Tim Roden、Neil Roodyn、Dennis Rubsam、John Santamaria、Pablo Santos Luaces、Barry Saylor、Matt Schouten、Dan Schreiber、Jeff Schroeder、John Sellars、Don Shafer、Desh Sharma、David Sholan、Creig R. Smith、Dave B Smith、Howie Smith、Steve Snider、Mitch Sonnen、Erik Sowa、Sebastian Speck、Kurk Spendlove、Tim Stauffer、Chris Sterling、Peter Stevens、Lorraine Steyn、Joakim Sundén、Kevin Taylor、Mark Thristan、Bill Tucker、Scot Tutkovics、Christian P. Valcke、PhD、Paul van Hagen、Mark H. Waldron、Bob Wambach、Evan Wang、Phil White、Tim White、Jon Whitney、Matthew Willis、Bob Wilmes、David Wood、Ronnie Yates、Tom Yosick和Barry Young。

在大量评论中，有一些特别深刻有用。特别感谢这些审稿人：John Aukshunas、Santanu Banerjee、Jim Bird、Alastair Blakey、Michelle Canfield、Ger Cloudt、Terry Coatta、Charles Davies、Rob Dull、Rik Essenius、Ryan E. Fleming、Tom Greene、Owain Griffiths、Chris Haverkate、Dr Arne Hoffmann、Bradey Honsinger、Philippe Kruchten、Steve Lane、Ashlyn Leahy、Kamil Litman、Steve Maraspin、Jason McCartney、Mike Morton、Shaheeda Nizar、Andrew Park、Jammy Pate、John Reynders、André Sintzoff、Pete Stuntz、Barbara Talley、Eric Upchurch、Maxas Volodin、Ryland Wallace、Matt Warner、Wayne Washburn和David Wight。

我还想感谢制作团队的出色工作，包括Rob Nance的绘图、Tonya Rimbey带领的评审工作，以及Joanne Sprott编写的索引。还要感谢Jesse Bronson、Paul Donovan、Jeff Ehlers、Melissa Feroe、Mark Griffin和 Mark Nygren招募审稿人。

最后，特别感谢策划编辑Devon Musgrave。这是我与Devon合作的第三个图书项目。他的编辑判断在诸多方面改善了本书，他对我各类写作项目的浓厚兴趣对完成本书发挥了至关重要的作用。

资源与支持

本书由异步社区出品，社区（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。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。

异步社区

微信服务号

第一部分 卓有成效的敏捷介绍

这一部分介绍敏捷软件开发的基本概念。第二部分至第四部分给出深入的具体建议。

本书其余部分会大量引用第一部分介绍的概念，因此，如果你直接跳到第二部分至第四部分阅读，请牢记那些基于第一部分的理念。

如果读者喜欢从整体概览开始，可以直接跳到第五部分，阅读“享受劳动果实”和“关键原则汇总”。

第1章 概 述

21世纪初期，软件行业领导者就敏捷开发提出了许多重要问题。这些领导者担心敏捷对质量、可预测性、大型项目、可度量改进的支持能力，以及受监管行业工作的支持能力。当时，他们的担心是合理的：敏捷最初的承诺言过其实了，多数敏捷实施令人失望，而且获得结果所花费的时间常常超出预期。

软件行业需要时间和经验来区分早期敏捷的无效失误与真正进步。最近几年，软件行业已经改进了一些敏捷的早期实践，增加了新实践，并且学会避免一些行为。今天，使用现代敏捷开发为同时提高质量、可预测性、生产力和产量提供了机会。

20多年来，我的公司Construx Software（以下称Construx 软件公司）一直与开发各种软件系统的组织合作——范围从移动游戏到医疗设备。我们已经帮助数以百计的组织在顺序生命周期开发（后简称顺序开发）上获得成功，而在过去15年里，我们帮助客户使用敏捷开发，并获得了越来越好的结果。我们看到，许多机构通过采用敏捷实践显著地缩短了周期时间，提高了生产力，改进了质量，提高了客户响应速度及透明度。

大多数敏捷文献都专注于那些新兴市场中雄心勃勃、发展迅速的公司，如奈飞、亚马逊、Etsy、Spotify和其他类似的公司。但是，如果公司制造的软件没那么前沿该怎么办？如果公司是给科学设备、办公设备、医疗器械、电子消费品、重型机械或过程控制设备编写软件，该怎么办？我们发现，当聚焦于对特定业务有好处的方法时，现代敏捷实践也为这类软件带来了好处。

1.1　有效的敏捷为何重要

公司由于自身利益希望更高效的软件开发。它们也因为软件能支持许多其他业务功能而想要更高效的软件开发。《DevOps现状报告》发现：拥有高效IT组织的公司超标实现公司在盈利、市场份额及生产效率等方面目标的可能性是其同行的两倍（Puppet Labs，2014）。对于公司在客户满意度、工作质量、工作量及运营效率等方面所设定的目标高效的公司能满足甚至超越该目标的可能性是其同行的两倍。

有选择地、合理地使用现代敏捷实践为高效软件开发以及随之而来的所有好处提供了一条行之有效的途径。

遗憾的是，大多数公司没有认识到敏捷实践的潜力，因为大多数敏捷实践的实施方式都不够高效。例如，Scrum是最常见的敏捷实践，用好了无比强大，然而大多数时候我们看到的Scrum实施方式并不能真正地实现它的价值。图1-1对比了我们公司所了解的一般的Scrum团队和健康的Scrum团队。

图1-1 一个根据关键Scrum成功因素来展示Scrum团队表现的诊断工具

我们通常只看到一个Scrum关键要素被有效地采用（每日Scrum/站会），但每日Scrum /站会本身也远未普及。Scrum的其他元素被零星地采用或者完全没有被采用（第4章详细描述了这个图使用的评分方式。）

把潜在的好实践用烂并非敏捷失败的唯一原因。敏捷这个词已经成为一个涵盖无数实践、原则和理论的总称。我们看到许多组织由于无法在敏捷的含义上达成一致而导致了敏捷实施的失败。

在敏捷中，有些实践比其他实践表现得更好，我们看到一些组织由于选择了无效实践而失败。

组织可以获得更为卓越的效能，本书描述了做到这一点的方法。

1.2　本书的目标读者

本书的读者是想要确保实施高效敏捷的组织和软件团队的执行官级别高管、副总裁（VP）、总监、经理和其他领导者。如果你拥有技术背景但缺乏现代敏捷实践的丰富经验，本书就是为你准备的；如果你没有技术背景，只是想了解敏捷实践的实用知识，你也是本书的目标读者（跳过技术部分没什么问题）；如果你在10到15年前了解过许多敏捷实践，但此后一直没有更新过现代敏捷知识，这本书也适合你。

最重要的是，如果你的组织已经实施敏捷开发而你对结果并不满意，这本书正适合你。

1.3　本书与其他敏捷图书有何不同

这不是一本关于如何正确实践敏捷的书，它要讲的是那些对公司的业务真正有益的敏捷实践，以及如何从这些实践中获得最大的价值。

本书讨论了公司关心而敏捷纯粹主义者常常忽略的主题：敏捷实施的常见挑战，如何只在组织的一部分中实施敏捷，敏捷对可预测性的支持，在成员位置分散的团队中使用敏捷的方式，还有如何在受监管行业中使用敏捷。

关于敏捷开发的大多数图书都是由布道师编写的。他们要么倡导特定的敏捷实践，要么全面推广敏捷。我不是敏捷布道师，我提倡采用有效的手段，反对无凭无据、信口承诺。这本书并未将敏捷当作一场要求更高意识状态的运动，而是当作一组特定的管理和技术实践，其效用和相互作用能从业务和技术方面进行理解。

我没有办法在21世纪早期编写这本书，因为那时软件世界尚未累积足够的敏捷开发经验，无法确切知晓哪些实践有用而哪些没用。今天，我们已经了解到，一些最广为人知的实践其实没有多大效果，而其他不太为人所知的实践却涌现出来成为现代高效敏捷实施的可靠主力。本书会对此进行整理区分。

敏捷热衷者也许会批评这本书没有呈现最前沿的敏捷开发，这确实说到点子上了——本书关注的是已经被证明有效的实践。敏捷开发的历史充斥着一两个热衷者在少数组织中成功运用但最终发现不具有普遍适用性的想法。本书不会详细讨论这些作用有限的实践。

本书提供了高效的现代敏捷实践的路线图，还有一些注意事项告诉读者要避免的敏捷实践和思想。本书不是敏捷教程，而是帮助软件领导区分有效敏捷与无效敏捷的指南。

1.4　本书如何组织

本书从介绍敏捷的背景开始，接下来介绍个体和团队，然后介绍个体和团队使用的工作实践，再然后介绍使用这些工作实践的团队所在的组织，最后是总结和展望。

本书每部分的开头提供指导，帮助读者决定是否阅读每一部分以及以何种顺序阅读。

1.5　让我知道你的想法

如果没有广泛的同行评审，本书的内容不会这么充实。我的Construx 软件公司同事对最初的手稿进行了详细评审。我请外部志愿者评审了后续的稿子， 300多名软件行业领导者贡献了超过10 000条评审意见。他们无私的帮助使这本书臻于完善。

你对本书的感觉如何？它与你的经验相符吗？它对你面对的问题有任何帮助吗？你可以通过异步社区反馈想法，我希望从出版社知道中国读者的想法。

华盛顿州贝尔维尤市

2019年7月4日

第2章 敏捷到底有何不同

大多数写到“敏捷到底有何不同”的图书开篇都会大幅介绍2001年《敏捷宣言》诞生的历史，还有与其同龄的《敏捷原则》。

这些文件在20年前发挥了重要的作用，但敏捷实践从那时起就不断成熟，这些历史文献根本无法准确描述现代敏捷最有价值的方面。

因此，今天的敏捷有何不同？敏捷运动在历史上将自己与瀑布开发进行了对比。当时的说法是瀑布开发尝试一开始就做100%的规划，需求工作也是100%预先完成，100%预先设计，以此类推。这是对瀑布开发的字面意义的准确描述，但它描述的是一个从未真正广泛使用的开发方式。各种分阶段的开发方式才是普遍做法。

真正的瀑布开发主要存在于美国国防部的早期项目中，而在撰写《敏捷宣言》时，那种早期粗犷式的实施方式早已被更精细复杂的生命周期所取代。^[1]

[1]　美国国防部项目的瀑布软件开发标准（MIL-STD-2167A）在1994年年底被非瀑布标准（MIL-STD-498）取代。

现今，顺序开发是与敏捷开发最有意义的对标物。撇开错误描述不谈，表2-1展示了它们之间的详细对比。

（1）短发布周期与长发布周期对比。采用敏捷实践的团队以按天或周的周期开发可工作的软件。采用顺序实践的团队按月或季度度量其开发周期。

（2）进行从需求到实现的开发工作时，小批量方式与大批量方式对比。敏捷开发强调小批量完整的开发，包含详细的需求、设计、编码、测试和文档工作，意味着一次只实现少量特性或需求。顺序开发强调以大批量的方式将整个项目的工作按需求、设计、编码及测试等阶段一次性地从一个阶段移动到下一个阶段。

（3）即时规划与预先规划对比。敏捷开发通常只做一点点预先规划并将大部分详细规划留到之后即时完成。出色的顺序开发也会做很多即时规划，但像挣值管理这样的顺序实践则非常强调更为详细的预先规划。

表2-1 顺序开发和敏捷开发之间不同的侧重点

（4）即时需求与预先需求对比。敏捷开发强调前期尽可能少地进行需求相关工作（强调广度而不是细节）；它将大量详细需求相关工作推迟到项目开始之后、真正需要详细需求的时候再进行。顺序开发预先定义了大多数需求细节。

需求是现代敏捷实践超越21世纪早期敏捷理念的领域。我将在第13章和第14章中探讨这些变化。

（5）涌现式设计与预先设计对比。与规划和需求一样，敏捷将详细设计的细化工作推迟到需要详细设计的时候，并最小限度地强调预先设计和架构。顺序开发注重更细粒度的预先设计。

认识到预先设计和架构工作的价值是现代敏捷超越21世纪早期敏捷理念的另一个领域。

（6）开发阶段的持续自动化测试与最后单独测试对比。敏捷开发强调测试应该是与编码同步进行的工作，有时要先于编码。测试由包含了测试专家的开发团队完成。顺序开发将测试当作独立于开发来执行的活动并且通常在开发之后。敏捷开发强调自动化测试以便测试能够由更多人、更频繁地运行。

（7）频繁的结构化协作与不频繁的结构化协作对比。敏捷开发强调频繁的结构化协作。这些协作常常很短（如15分钟的每日站会），但被组织成日复一日、周复一周的敏捷工作节奏。顺序开发当然不阻碍协作，但也没有特别鼓励。

（8）经验性的、快速响应、面向改进与理想化的、预先安排、面向控制对比。敏捷团队强调经验方法。他们注重于从真实经验中学习。顺序团队也尝试从经验中学习，但他们更注重制订规划以及在现实中建立秩序，而不是观察现实并持续调整。

比较敏捷开发与顺序开发时，人们倾向于将一方好的方面与另一方坏的方面进行比较。这既不公平也没意义。运行良好的项目注重良好的管理、高水平的客户协作，以及高质量的需求、设计、编码和测试——无论项目使用敏捷还是顺序的开发方法。

顺序开发在理想的情况下也能运转良好。然而，如果研究了如表2-1所示的差异并对自己的项目进行了反思，你会发现一些端倪，表明敏捷开发为什么在许多情况下比顺序开发效果更好。

2.1　敏捷的好处从何而来

敏捷开发的好处可不是由于用了敏捷这个词。它们源于如表2-1所示的那些敏捷要点的直观效果。

（1）短发布周期能帮助你更及时且以更低的成本修复缺陷、浪费更少的时间在无效需求或设计上、更及时地获得用户反馈、更快地修正方向，以及更快地实现收入增长和运营成本的降低。

（2）以小批量方式开展从需求到实现的开发工作也提供了类似的好处——更紧密的反馈周期、更快且成本更低的错误检测和修复。

（3）即时规划的结果是不会花费太多时间去准备那些之后会被忽略或抛弃的详细规划。

（4）即时需求的结果是在那些需求变更时会被废弃的预先需求上投入的工作更少。

（5）涌现式设计的结果是不会给后期会改变的需求预先设计解决方案，更不用说去做那些没有按规划给出细节的设计。预先设计可能非常强大，但为不确定的需求进行预先设计既容易出错也浪费时间。

（6）开发阶段的持续自动化测试增强了引入缺陷和缺陷检测之间的反馈循环，有助于低成本的缺陷纠正，并着重于初始代码质量。

（7）频繁的结构化协作减少了沟通上的错误。过多的沟通上的错误会显著增加需求、设计及其他活动中的缺陷。

（8）经验性的、快速响应、面向改进的模型有助于团队更快地从经验中学习并随时间逐步改善。

不同组织会关注不同的敏捷要点。如果要开发的软件的安全性至关重要，组织通常不会采用涌现式设计。涌现式设计也许能够省钱，但安全方面的考量更为重要。

相似地，每次发布软件都产生很高成本的组织——可能是由于要将软件嵌入难于访问的设备中或者由于监管方面的支出——就不会选择频繁发布。从频繁发布获得的反馈也许能够为一些组织省钱，但也许会让其他组织的成本远远超过其节省的钱。

一旦不再认为敏捷是不可分割的概念——要么全盘接受，要么就毫无用处，就可以自由地单独实施敏捷实践。你开始意识到一些敏捷实践比其他实践更有效——而有些则对你的特定情况更有效。如果组织需要支持业务敏捷性，现代敏捷软件实践自然是合适的；如果组织需要支持质量、可预测性、生产力或其他不明显的敏捷属性，现代敏捷软件实践也非常有价值。

2.2　敏捷边界

大多数组织无法实现从需求到实现的敏捷性。组织可能无法从敏捷HR（人力资源经理）或敏捷采购上看到任何好处。 即使你致力于整个组织的敏捷，但也许会发现客户或供应商没有你敏捷。

理解组织的敏捷部分和非敏捷部分之间的边界是很有用的——既包含当前的边界也包含期望的边界。

如果你是CXO级别的高管，敏捷边界内可能包括整个组织；如果你是组织的高层技术负责人，敏捷边界内可能包括整个技术组织；如果你是较低级别的负责人，敏捷边界内可能只包含你的团队。看一下图2-1中的示例。

图2-1 敏捷边界的示例。这个例子中，敏捷实践仅限于技术组织

错误界定敏捷边界可能造成期望偏差和其他问题。考虑这些场景：

● 敏捷的软件开发和非敏捷的规章制度；

● 敏捷的销售和非敏捷的软件开发；

● 敏捷的软件开发和非敏捷的企业客户。

任何组织都有边界。你打算在组织内将敏捷实施到哪种程度？什么对业务最有利？

给领导者的行动建议

检视

● 反思之前认为敏捷是“要么全盘接受，要么就毫无用处”的程度。这在多大程度上影响你改进管理和技术实践的方法？

● 与组织中至少三位技术领导者交谈。询问他们所说的“敏捷”意味着什么。询问他们指的是什么具体实践。你的技术领导者就“敏捷意味着什么”能够达成多大的认同？他们是否能在“什么不是敏捷”上达成一致？

● 与非技术领导者讨论敏捷对他们意味着什么。他们如何感知其工作和你的软件团队之间的边界或接口？

● 依据表2-1所描述的要点来评审项目组合。就每个因素给项目打分，1是完全顺序，5是完全敏捷。

调整

● 写下在组织中划分敏捷边界的初步方法。

● 编写一个随着阅读本书的剩余部分要回答的问题列表。

拓展资源

● Stellman, Andrew and Jennifer Green. 2013. Learning Agile: Understanding Scrum, XP, Lean, and Kanban. O'Reilly Media.

这本书从支持敏捷的角度很好地介绍了敏捷概念。

● Meyer, Bertrand. 2014. Agile! The Good, They Hype and the Ugly. Springer.

这本书一开始对敏捷运动过度兴盛提出了有趣的评论，并列明了与敏捷开发相关的最有用的原则和实践。