越来越多的人认识到，在构建软件解决方案时，敏捷方法比传统方法要有竞争力得多。在本书中，敏捷大师Scott W. Ambler和Mark Lines介绍了IBM公司颇有突破性的规范敏捷交付（DAD）流程框架。
掌握IBM突破性的DAD过程框架，决胜敏捷开发于大型、复杂且关键的IT项目
软件解决方案的构建正在从传统方法走向敏捷世界，作为企业竞争优势的关键来源，这一点已毋庸置疑。主流敏捷方法确实适用于小型项目，但这些方法若要为复杂而大型的企业项目所用，则还需要历经重大调整。本书介绍了IBM突破性的规范敏捷交付（DAD）过程框架，描述了应该如何进行这样的调整。DAD把更严格和更规范的方法引入了敏捷开发过程之中，它承认企业中各种规程、各种计划相互依赖的现实和企业环境的复杂性，并致力于解决其中纷杂而棘手的各种问题。
本书展示了如何通过敏捷思想和精益策略来补充和扩展Scrum方法，包括敏捷建模（AM）、极限编程（XP）、看板（Kanban）和统一过程（UP），以及其他行之有效的方法，并最终提出了一套适合组织独特需求的混合型方法。其中描述了哪些实践效果最好，为什么有效，需要做哪些权衡，什么时候选择替代策略，而所有这些探索都没有脱离企业的生态环境。
规范敏捷交付方法致力于横跨项目整个生命周期的敏捷实践：从用户需求、系统架构和开发过程一直到产品交付与企业治理。作者揭示了在这样一个从项目启动到产品交付的端到端的过程中，上述敏捷实践如何默契配合，最终促成大型复杂系统的成功交付。
本书主要内容：
对敏捷方法进行扩展，使其适应企业关键型任务的开发
避免错误，防止敏捷项目从运维不善发展为混乱不堪
高效地启动敏捷项目
个人在敏捷思维和工作方式上的转变
以增量方式构建可利用的解决方案
向复杂的生产环境部署解决方案
充分利用DevOps方法、企业架构和其他企业规程
调整企业治理策略，使它服务于敏捷开发项目
本书以事实、研究和广泛的经验为依据，为企业的每个软件思想领袖和实践者提供了不可或缺的资源，帮助他们优化自己现有的敏捷实践和Scrum流程，提高迭代过程的敏捷水平。
作者简介
斯科特·安布勒（Scott W. Ambler）
IBM Rational首席敏捷软件开发专家和精益软件开发专家，规范敏捷交付（DAD）概念的提出者和相应过程框架的开发领导者，敏捷建模、敏捷数据、敏捷统一过程和企业统一过程等方法的创始人，敏捷伸缩模型的创建者。著作等身，与他人合著图书20余本，包括《Refactoring Databases》、《Agile Modeling》、《Agile Database Techniques》、《The Object Primer, 3rd Edition》，以及《The Enterprise Unified Process》等经典著作。此外，他还是《Dr. Dobb’s Journal》杂志的特约资深编辑。
他的个人网站是www.ambysoft.com。
马克·莱恩斯（Mark Lines）
资深敏捷软件开发专家，规范敏捷方法教练，善于为软件开发组织提供全方位的指导。他在利用敏捷和精益生产技术加速开发进程和提高产品质量方面拥有丰富的实践经验。出版了多本著作，并经常作为演讲人出现在各种业界会议上。他还是IBM Rational和UPMentors（2007年与他人合伙创立）的课程讲师。
他的个人网站是www.UPMentors.com，联系方式为：Mark@UPMentors.com。
译者简介
阎小兵（Kevin Yan）
IBM中国开发中心资深开发经理，IBM全球质量软件工程专员。关注和推动企业软件产品开发转型、敏捷开发方法与实践、质量管理与度量，并在相关领域拥有丰富的实践经验。
在客户眼中，信息技术（IT）行业的声誉着实令人尴尬。几十年来，我们浪费了太多稀缺的预算和资源，违背了自己的承诺，而交付的产品功能却并不是客户的真正之需。旁观者对我们的职业一定困惑不已。我们有那么多过程框架和各种各样的知识体系，以至于连我们自己都很难理解那些层出不穷的、只有首字母缩写的词语，更不用说隐含在其后的丰富的知识和资源。看一下：PMBOK、SWEBOK、BABOK、ITIL 、COBIT、RUP、CMMI、TOGAF、DODAF、EUP、UML和BPMN等。即使范围缩小到敏捷这样的社区，也还有Scrum、XP、CI、CD、FDD、AMDD、TDD、BDD等许多缩写语。在这些策略之间存在着相当多的重叠，同时也不乏巨大的差异。我们真的需要一起采取行动做些什么了。
为什么要敏捷
在传统/经典项目中，甚至很悲哀，在采用“厚RUP方法”的项目中，为了各种标准机构的各种标准，基本的业务需求和系统需求的探索经常会以各种时尚的文档作为收尾。尽管在一些监管较严格的环境中，这些做法被证明是良好的实践，但在许多情况下，它更被证明是对时间和精力的巨大浪费，而且它经常极少能为组织带来组织所追求的终极价值，所以组织不得不对过程和方法进行定制，从而满足自身的业务需求。
幸运的是，过去十年间，在软件开发领域涌现出了各种敏捷方法，让我们有机会把自己从上述愚蠢的方式中拯救出来。敏捷开发方法的美妙之处在于，它们关注的是如何为我们的客户交付具有高商业价值的可工作软件，而且这种关注在项目的开发过程中会来得更早、更频繁。我们可以随着客户业务需求的变化，随时调整项目的目标，并在总体上，鼓励最大限度地减少编制文档的工作量，最大限度地减少甚至消灭官僚机制。谁不喜欢呢？
更重要的是，敏捷策略在实践中似乎很奏效。在过去几年里，斯科特在IT行业内做过多次调查，并不断地发现，敏捷和迭代软件开发策略的表现一直优于传统和一些临时的开发策略。尽管敏捷方法仍有改进余地，而且本书会为此提出多条改进建议，但很显然，敏捷这一步是在正确方向上迈出的一步。例如，2011年的IT项目成功率调查（IT Project Success Survey）显示，受调查者认为，67%的敏捷项目是成功的（因为满足所有的成功标准），27%的敏捷项目是不太成功的（交付了，但没有满足所有的成功标准），只有6%的敏捷项目是失败的。同一调查显示，50%的传统项目是成功的，36%的传统项目是不太成功的，14%的传统项目是失败的。2008年的IT项目成功率调查发现，敏捷项目团队更善于交付高质量的、具有良好投资回报率（ROI）的、满足利益相关者期望的解决方案，而且比传统团队更快交付。但是，这些只是平均值，敏捷成功率可能因具体项目不同而不同，不过总的来说，这些结果仍足以引人注目。我们现在与大家分享这些数据，旨在激励大家认真对待敏捷，但更重要的是，这是为了说明贯穿于全书的一个主题：我们将尽力回避在许多软件过程书籍中过于热情的“宗教”式讨论，相反，我们的讨论面向事实，基于实验和研究证据。因为研究还在进行中，所以仍有一些证据会有漏洞，但尽管如此，我们仍然会远离那些在其他地方还在进行的争论，诸如“我的过程胜过你的过程”之类。
阿利斯泰尔·科伯恩，《敏捷宣言》起草人之一，认为敏捷方法有三个主要的方面：
自律。极限编程（XP）中的典型方法
自组织。Scrum中的典型方法
自我意识。Crystal（水晶）思想中的典型方法
在本书中，规范敏捷交付（Disciplined Agile Delivery，DAD）将会探讨科伯恩所提出的这三个方面。
为什么需要规范敏捷交付
虽然敏捷策略似乎优于传统策略，但它已清楚地向我们表明，钟摆又摆到了另一个极端，即我们从过于形式主义和以文档为中心的这一端，摆到了几乎只关注代码的另一端。公平地讲，敏捷团队确实在规划方面投入了不少的精力，虽然不可能建立详尽的计划；他们确实在建模方面投入了不少的精力，虽然不可能建立所有的模型；他们确实编写了产品文档（如操作手册和系统概述文档），虽然不可能创建完善的规格说明。然而，在敏捷团队中，迭代方法所产生的效果几乎并没有太多的改善。2011年的IT项目成功率调查发现，69%的迭代项目是成功的，25%的迭代项目是不太成功的，6%的迭代项目是失败的，统计结果与敏捷项目的实际情况基本一致。同样，2008年的IT项目成功率调查发现，从统计上看，采用敏捷方法的团队和采用迭代方法的团队在交付质量、交付能力与交付及时性方面都相差无几，只是敏捷团队在ROI上略优于迭代团队。在对敏捷策略与迭代策略进行比较时，我们发现，敏捷开发的现实表现，确实没有辜负大家用在它身上的华丽辞藻，而且敏捷有可能做得更好。
我们的经验表明，“核心”敏捷方法，如Scrum，适合于非常小的项目团队，解决相对简单的问题，它几乎不存在失败的风险或后果。然而，这些方法显然没有充分考虑交付大型企业解决方案的相关风险，作为结果，我们看到组织正在投入大量精力去组合各种来源的技术，创建一些混合型方法。本书所描述的规范敏捷交付（DAD）过程框架也正是一种混合型方法，它扩展了Scrum，融合了敏捷建模（Agile Modeling，AM）、极限编程（eXtreme Programming，XP）和统一过程（United Process，UP）中已证明有效的策略以及其他一些方法。Scrum专注于软件的构造，而DAD扩展了Scrum的生命周期，致力于从项目启动到为最终用户交付解决方案这一完整的、端到端的交付生命周期。DAD过程框架包含了Scrum有意避而不谈的技术实践以及在Scrum和XP中业已消失的建模、文档和治理策略。更重要的是，在许多情况下，DAD会提供建议，帮助组织选择切实可行的替代方案和折中方案，使得组织能够对DAD进行有效裁剪，使之适合自己的特定情形。通过描述什么可行，什么不可行，以及原因是什么，DAD可以帮助组织更好地采用行之有效的策略。
事实上，高调项目的失败在不断增多，暴露出的原因大都与敏捷策略有关。对于大规模敏捷项目来说，如果我们不着手用更严格的方法来补充和完善核心敏捷实践，那么就可能失去敏捷先驱们所创建的、来之不易的兴旺之势。
本书并不是试图改写现有的敏捷思想（这些例子可以从参考资料部分找到），相反，本书旨在成为实用的指南，使大家能够从今天起，就开始践行结构化和规范化敏捷方法，开发大规模的、承载企业关键使命的项目，满足企业的商业需求。
DAD的历史
规范敏捷交付（DAD）过程框架的概念是由斯科特在2007年提出的，他时任IBM Rational 首席敏捷和精益方法学家。那时他与世界各地的客户打交道，帮助客户在大规模场景中掌握敏捷技术的应用。在这个过程中，他一次又一次地观察到，组织在采用主流敏捷方法（比如极限编程（XP）和Scrum）时是多么辛苦。与此同时，马克在帮助组织采用和应用敏捷技术实践的过程中，也注意到了同样的问题。在许多情况下，固有的发号施令式文化会阻碍企业采用这些混合技术。此外，尽管许多组织在敏捷试点项目中很成功，但离开这些试点团队，他们则很难较好地应用敏捷策略。其根本原因在于，这些方法普遍没有致力于解决IT部门所面临的范围广泛的问题，更不用说IT部门以外更广泛的组织机构了。所以说，有些地方看起来不太对劲。
于是，我们开始分别着手解决这些问题。横向上，斯科特与更多的组织一起工作，对敏捷团队进行广泛的观察；纵向上，马克深入多个组织，对敏捷团队进行长期指导。2009年斯科特带领IBM Rational团队开发出了DAD过程框架，直到今天，许多相关工作仍在继续，例如，开发DAD课件，编写白皮书，在IBM developerWorks 上发表博客。
精益方法简述
精益策略为什么对DAD至关重要，这里有多种原因。
精益为简化DAD团队的工作方式提出了深刻的见解。
精益为可伸缩的DAD处理复杂情况提供了坚实的基础。这个主题在全书都会有所涉及，而且我们打算在未来要出版的书中再做更详细的讨论。
精益原则解释了为什么敏捷实践有效，这也是贯穿于全书的一个主题。
精益策略中的看板（Kanban）方法为DAD提供了一种先进的应用策略。
那么，为什么我们不取而代之叫规范精益开发（Disciplined Lean Development，DLD）呢？我们有这样的经验，在目前，精益策略的吸引力和效力还很有可能仅体现在一小部分团队中。这个“小”也许是10%～15%——当然是在20%以下——但只有随着时间的推移才会知道具体百分比。我们发现，大多数开发团队更适合于轻量级的、端到端的过程框架，因为这种框架可以全面、明确且综合地建议团队如何完成工作而不拘泥于过程细节。前面已经说过，为实现DAD过程框架目标，我们提出了各种选择，而它们在本质上是非常清晰和简洁的，我们预计，许多团队会不断演进他们的流程，并逐渐从以敏捷为主转变为以精益为主。
DAD是Scrum和RUP这两个极端之间的折中，而且恰到好处，因为Scrum是一个轻量级的过程框架，仅仅关注在交付过程中的一小部分，而RUP是一个涵盖完整交付周期的综合性过程框架。DAD注重敏捷交付的基础，而同时又保持充分的灵活性，企业可以对它进行定制，从而使其适应企业自身的环境。在许多方面，Scrum是在教敏捷专家怎么爬，DAD是在教敏捷专家如何走，而大规模敏捷（agility@scale）和精益方法（如看板）是在教他们如何跑。
本书能提供什么帮助
我们相信，通过阅读本书，读者会在许多方面受益。
它描述了一个端到端的敏捷交付周期框架。
它描述了常见的敏捷实践，以及这些实践如何融入生命周期，它们之间如何协同工作。
它介绍了敏捷团队如何在整个组织范围内以“企业意识”（enterprise aware）的方式有效工作。
它使用了一致且合理的术语，并与其他方法所采用的术语进行了映射对比。
它解释了各种策略的权衡，并在许多情况下，提供了可选的替代策略。
它提供了一个基础，你可以围绕该基础对敏捷策略进行扩展，以满足现实世界中团队所面临的实际情形。
它不是为了哗众取宠，而是用确凿的原因阐述这些技术为何奏效。
它确实回答了这个问题：“所有这些敏捷技术是如何组合在一起工作的？”
我们来自哪里
我们俩都注意到，组织在采用Scrum时，总会对其进行扩展，所利用的正是XP、敏捷建模和其他方法中的实践，这非常类似DAD的做法，或者，组织会对统一过程进行裁剪，使之成为类似于DAD的方法。不论哪种策略，组织都投入了大量的精力，而这些原本可以轻松避免。有了DAD，我们希望能够帮助团队和组织，避免这类冗长而且要进行反复试验的过程，而同时还能让团队对它进行定制，以满足其独特的需求。
在IBM Rational中，斯科特仍在带领DAD方法不断发展和演进，并利用他的经验，帮助组织理解和采用这些敏捷策略。本书也包含了来自IBM软件集团——一个拥有27 000开发人员的全球化组织——内部的经验教训，以及IBM全球服务部专业人员采用的规范式敏捷（Agile with Discipline，AwD）方法。规范式敏捷是一种建立在快速解决方案交付（Accelerated Solution Delivery，ASD）框架之上的方法。在2009年秋天，IBM Rational针对DAD推出了一个为期三天的“规范敏捷交付”研讨会。这个研讨会于2010年第一季度首次推介给IBM业务合作伙伴，包括UPMentors。所以作为非IBM员工，UPMentors的马克便成为首批有资格开展DAD研讨会的讲师之一。从此以后，马克不断为DAD做出重要贡献，他把自己的见解和经验带给了DAD。
如何阅读本书
大多数人会愿意从头到尾一页一页地读。然而，有三个例外。
经验丰富的敏捷从业者可以从第1章开始，了解DAD的概况。接着阅读第4章，理解团队中的角色。然后再读第6章～第19章，其中详细介绍了DAD的工作方式。
资深IT经理可以先读第1章，以便在总体上了解DAD是什么，然后跳到第20章，这一章重点描述了敏捷团队的治理策略。
愿意从DAD实践示例开始的人可以读案例研究章节，它们是：第12章、第17章和第19章。
我们建议组织采纳敏捷方法所推行的、领先的核心敏捷实践，但同时也建议组织有必要选择和补充一些规范的策略和工具，以适应组织和项目的现实需求。
顺便说一句，本书的一部分销售额将捐给囊性纤维化基金会和多伦多儿童医院，谢谢你对这些善举的支持。
规范敏捷交付网站
www.DisciplinedAgileDelivery.com作为一个社区网站，囊括了有关DAD的所有信息。马克和斯科特两人都是版主。在这里还可以下载其他资源，如有关DAD的教育资料、服务供应商清单和支持材料等。我们诚邀任何愿意为DAD做贡献的人来这里写博客。加入我们的讨论吧！
本书中使用的缩略语
AD Agile Data 敏捷数据
AM Agile Modeling 敏捷建模
AMDD Agile Model Driven Development 敏捷模型驱动开发
ASM Agile Scaling Model 敏捷伸缩模型
ATDD Acceptance Test Driven Development 验收测试驱动开发
AUP Agile Unified Process 敏捷统一过程
AwD Agile with Discipline 规范式敏捷
BABOK Business Analysis Book Of Knowledge 业务分析知识指南
BDD Behavior Driven Development 行为驱动开发
BI Business Intelligence 商务智能
BPMN Business Process Modeling Notation 业务流程建模标记法
CASE Computer Aided Software Engineering 计算机辅助软件工程
CD Continuous Deployment 持续部署
CI Continuous Integration 持续集成
CM Configuration Management 配置管理
CMMI Capability Maturity Model Integrated 集成软件能力成熟度模型
COBIT Control Objectives for Information and Related 信息及相关技术控制目标
Technology
DAD Disciplined Agile Delivery 规范敏捷交付
DDJ Dr. Dobb’s Journal 《Dr. Dobb’s Journal》杂志
DevOps Development operations DevOps
DI Development Intelligence 开发智能
DODAF Department Of Defense Architecture Framework 美国国防部体系结构框架
DSDM Dynamic System Development Method 动态系统开发方法
EUP Enterprise Unified Process 企业统一过程
EVM Earned Value Management 挣值管理
FDD Feature Driven Development 特征驱动开发
GQM Goal Question Metric GQM方法（目标问题度量）
HR Human Resources 人力资源
IT Information Technology 信息技术
ITIL Information Technology Infrastructure Library 信息技术基础架构库
JIT Just In Time 即时方式
MDD Model Driven Development 模型驱动开发
MMR Minimally Marketable Release 最简市场发布（版）
NFR Non-Functional Requirement 非功能性需求
NPV Net Present Value 净现值
OSS Open Source Software 开放源代码软件
PMBOK Project Management Book Of Knowledge 项目管理知识体系指南
PMO Project Management Office 项目管理办公室
ROI Return On Investment 投资收益率
RRC Rational Requirements Composer Rational Requirements Composer
RSA Rational Software Architect Rational Software Architect
RTC Rational Team Concert Rational Team Concert
RUP Rational Unified Process Rational统一过程
SCM Software Configuration Management 软件配置管理
SDLC System Development LifeCycle 系统开发生命周期
SLA Service Level Agreement 服务水平协议
SWEBOK SoftWare Engineering Book of Knowledge 软件工程知识指南
TCO Total Cost of Ownership 总体拥有成本
TDD Test-Driven Development 测试驱动开发
TFD Test First Development 测试先行开发
TOGAF The Open Group Architecture Framework 开放小组架构框架
T&M Time and material 计时与计料
TVO Total value of ownership 总体拥有成本价值
UAT User acceptance testing 用户验收测试
UML Unified Modeling Language 统一建模语言
UI User Interface 用户界面
UP Unified Process 统一过程
UX User eXperience 用户体验
WIP Work In Progress 在制品，进行中的工作
XP eXtreme Programming 极限编程
致谢
我们要感谢以下人士，感谢他们为本书提供反馈：Kevin Aguanno、Brad Appleton、Ned Bader、Joshua Barnes、Peter Bauwens、Robert Boyle、Alan L.Brown、David L.Brown、Murray Cantor、Nick Clare、Steven Crago、Diana Dehm、Jim Densmore、Paul Gorans、Leslie R.Gornig、Tony Grout、Carson Holmes、Julian Holmes、Mark Kennaley、Richard Knaster、Per Kroll、Cherifa Liamani、Christophe Lucas、Bruce MacIsaac、Trevor O.McCarthy、M.K.McHugh、Jean-Louise Marechaux、Evangelos Mavrogiannakis、Brian Merzbach、Berne C.Miller、Mike Perrow、Andy Pittaway、Emily J.Ratliff、Oliver Roehrsheim、Walker Royce、Chris Sibbald、Lauren Schaefer、Paul Sims、Paula Stack、Alban Tsui、Karthikeswari Vijayapandian、Lewis J.White、Elizabeth Woodward和Ming Zhi Xie。
我们也要感谢以下人士，感谢他们在网上论坛分享自己的想法，而且这些想法最后都在书中得以采纳：Eric Jan Malotaux、Bob Marshall、Valentin Tudor Mocanu、Allan Shalloway、Steven Shaw、Horia Slusanschi和Marvin Toll。
“这是一本实用且理论结合实际的指南书。它在诠释敏捷价值观和敏捷准则的同时，承认企业业务的现实和未来的愿景。你会发现这里没有纯粹主义者的教条，也没有任何夸张的宣传。Scott和Mark所展示的是，团队如何在纷繁变化的团队环境和企业环境及其诸多限制下，不断前进，最终达到敏捷开发方法的‘甜点’，并收获可持续敏捷实践带来的真正好处。我真希望在10年前就能读到本书！”
——Brad Appleton，大型财富150电信公司敏捷/精益开发的倡导者
“我们发现，我们公司的项目管理办公室（PMO）在定制敏捷项目治理策略时，从规范敏捷交付这一指导方法中获得了极大的帮助。如果团队要使用敏捷交付方法，本书则是必读之书。”
——Larry Shumlich，加拿大太平洋铁路项目经理教练
“本书注定会成为事实上的参考标准，它指导组织如何在复杂的业务环境中使用敏捷方法和Scrum方法。Scott和Mark从成功的敏捷团队中总结出了实用的指导原则和实践经验，告诉企业应该如何实现端到端的敏捷交付生命周期。”
——Elizabeth Woodward，IBM敏捷社区领袖，
《A Practical Guide to Distributed Scrum》一书的合著者
“要获得敏捷性带来的好处，有很多方法，但看到这个务实可行的‘涵盖性’方法，则着实令人鼓舞，它把敏捷实践的大部分好处封装成为一个框架。任何处在不断变化、日益复杂的领域中的人，阅读本书，定能受益。”
——Nick Clare，Ivar Jacobson国际公司敏捷教练及首席顾问
“Scott和Mark完成了一个富有挑战的课题。通过对大量成功实践的深入分析，本书既能帮助锐意进取的敏捷专家加速变革，又能为保守的组织管理者提供可伸缩的方法，并在两者之间找到了一个很好的平衡点。”
——Walker Royce，IBM首席软件经济学家
“规范敏捷交付作为一种基于经验的混合型软件交付方法，反映了实用主义的发展趋势，并远离了困扰软件开发行业40多年的反融合思想。我推崇Scott和Mark所写的这本书，赞赏他们表现出的领导力，是他们让我们的专业能力上升到了一个新的台阶。”
——Mark Kennaley，Software-Development-Experts.com首席技术官，
《SDLC 3.0：Beyond a Tacit Understanding of Agile》的作者
“我注意到，‘认证式敏捷’在组织中已经泛滥有加，它所带来的严重问题，甚至超过已解决的问题。终于，我们看到这个让人眼前一亮的方法，它告诉我们如何通过规范地使用敏捷方法来缔造成功。谢谢Scott和Mark。”
——Carson Holmes，第四媒体咨询公司服务交付执行副总裁
计算机\软件工程
掌握IBM突破性的DAD过程框架，决胜敏捷开发于大型、复杂且关键的IT项目。
软件解决方案的构建正在从传统方法走向敏捷世界，作为企业竞争优势的关键来源这一点已毋庸置疑。主流敏捷方法确实适用于小型项目，但这些方法若要为复杂而大型的企业项目所用，则还需历经重大调整。本书介绍了IBM突破性的规范敏捷交付（DAD）过程框架，描述了应该如何进行这样的剪裁。DAD把更严格和更规范的方法引入了敏捷开发过程之中，它承认企业中各种规程、各种计划相互依赖的现实和企业环境的复杂性，并致力于解决其中纷杂而棘手的各种问题。
本书展示了如何通过敏捷思想和精益策略来补充和扩展Scrum方法，包括敏捷建模（AM）、极限编程（XP）、看板（Kanban）和统一过程（UP），以及其他行之有效的方法，并最终提出了一套适合组织独特需求的混合型方法。其中描述了哪些实践效果最好，为什么有效，需要要做哪些权衡，什么时候选择替代策略，而所有这些探索都没有脱离企业的生态环境。
规范敏捷交付方法致力于横跨整个生命周期的敏捷实践：从用户需求，系统架构和开发过程一直到产品交付和企业治理。作者揭示了在这样一个从项目启动到产品交付的端到端的过程中，上述最佳实践技术如何默契配合，最终促成大型复杂系统的成功交付。
本书主要内容：
• 对敏捷方法进行扩展，使其适应企业关键型任务的开发
• 避免错误，防止敏捷项目从运行不善发展为混乱不堪
• 高效地启动敏捷项目
• 个人在敏捷思维和工作方式上的转变
• 以增量方式构建可消费的解决方案
• 向复杂的生产环境部署解决方案
• 充分利用DevOps方法，企业架构和其他企业规程
• 调整企业治理策略，使之服务于敏捷开发项目
本书以事实、研究和广泛的经验为依据，为企业的每个软件思想领袖和实践者提供了不可或缺的资源，帮助他们优化自己现有的敏捷实践和Scrum流程，提高迭代过程的敏捷水平。
（加）Scott W. Ambler, Mark Lines 著：暂无简介
阎小兵 徐蓓蓓 译：暂无简介
本书赞誉
中文版序
序
前言
第一部分 DAD概述
第1章 DAD / 2
1.1 背景——敏捷伸缩模型 / 4
1.2 DAD过程框架 / 5
1.3 以人为核心 / 5
1.4 注重学习 / 7
1.5 敏捷方法 / 8
1.6 混合型过程框架 / 8
1.7 是IT解决方案，而不只是软件 / 9
1.8 目标驱动的交付生命周期 / 10
1.9 企业意识 / 16
1.10 风险与价值驱动 / 19
1.11 可扩展 / 21
1.12 观点总结 / 22
1.13 延伸阅读 / 22
第2章 敏捷与精益开发简介 / 24
2.1 向规范《敏捷宣言》进发 / 25
2.2 规范敏捷思想的核心价值观 / 26
2.3 规范敏捷开发原则 / 27
2.4 精益开发原则 / 30
2.5 事实重于巧辩 / 33
2.6 观点总结 / 35
2.7 延伸阅读 / 36
第3章 DAD的根基 / 37
3.1 专业术语库 / 38
3.2 Scrum / 39
3.3 极限编程 / 42
3.4 敏捷建模 / 44
3.5 敏捷数据 / 46
3.6 精益软件开发 / 47
3.7 IBM实践 / 47
3.8 开放统一过程 / 49
3.9 其他 / 51
3.10 谁忽视敏捷实践，谁就会置业务于风险境地 / 51
3.11 观点总结 / 51
3.12 延伸阅读 / 52
第二部分 以人为核心
第4章 角色、权利和责任 / 54
4.1 每个人拥有的权利 / 55
4.2 每个人承担的责任 / 56
4.3 DAD角色 / 57
4.4 观点总结 / 71
4.5 延伸阅读 / 71
第5章 组建DAD团队 / 73
5.1 组建高效团队的策略 / 74
5.2 完整团队 / 77
5.3 团队组织策略 / 78
5.4 建立自己的团队 / 89
5.5 与其他团队互动 / 92
5.6 观点总结 / 95
5.7 延伸阅读 / 95
第三部分 启动DAD项目
第6章 先启阶段 / 98
6.1 先启阶段如何运行 / 99
6.2 与企业其他部门的合作 / 104
6.3 落实资金 / 108
6.4 先启阶段中的其他活动 / 110
6.5 在什么情况下需要先启阶段 / 111
6.6 先启阶段的模式 / 111
6.7 先启阶段的反模式 / 112
6.8 观点总结 / 113
6.9 延伸阅读 / 114
第7章 确定项目愿景 / 115
7.1 什么是愿景 / 116
7.2 如何创立愿景 / 116
7.3 捕捉项目愿景 / 117
7.4 让利益相关者同意愿景 / 119
7.5 观点总结 / 121
7.6 延伸阅读 / 122
第8章 确定范围 / 123
8.1 选择恰当的需求细化度 / 124
8.2 选择正确的模型类型 / 127
8.3 选择建模策略 / 133
8.4 选择管理工作项的策略 / 136
8.5 选择捕获非功能性需求的策略 / 139
8.6 观点总结 / 141
8.7 延伸阅读 / 141
第9章 确定技术策略 / 143
9.1 选择架构规格的详细程度 / 145
9.2 选择正确的架构模型类型 / 148
9.3 选择架构建模策略 / 151
9.4 贯穿于生命周期的架构演进 / 152
9.5 观点总结 / 152
9.6 延伸阅读 / 154
第10章 制定发布计划 / 155
10.1 谁来制定计划 / 156
10.2 选择计划级别 / 158
10.3 选择计划策略 / 159
10.4 选择节奏 / 161
10.5 制定项目进度表 / 166
10.6 估算成本和价值 / 174
10.7 识别风险 / 179
10.8 观点总结 / 180
10.9 延伸阅读 / 181
第11章 建立工作环境 / 183
11.1 组建团队 / 183
11.2 选择工具集 / 185
11.3 建立实体工作环境 / 190
11.4 建立虚拟工作环境 / 193
11.5 可视化管理 / 195
11.6 使用开发指南 / 196
11.7 观点总结 / 197
11.8 延伸阅读 / 197
第12章 案例研究：先启阶段 / 198
12.1 AgileGrocers POS案例简介 / 198
12.2 开发共享愿景 / 201
12.3 需求预想 / 207
12.4 创建用户故事，排序工作项 / 209
12.5 架构预想 / 209
12.6 发布计划 / 210
12.7 先启阶段中的其他活动 / 212
12.8 运行先启阶段的其他方法 / 212
12.9 结束先启阶段 / 213
12.10 观点总结 / 215
第四部分 增量式构造可利用的解决方案
第13章 构造阶段 / 218
13.1 构造阶段如何运行 / 219
13.2 构造迭代的典型节奏 / 225
13.3 风险—价值生命周期 / 225
13.4 何时可以部署 / 227
13.5 构造阶段的模式 / 227
13.6 构造阶段的反模式 / 228
13.7 观点总结 / 230
第14章 启动构造迭代 / 231
14.1 敏捷计划的特点 / 232
14.2 迭代计划 / 232
14.3 计划的可视化 / 243
14.4 前瞻性计划和建模 / 245
14.5 观点总结 / 246
14.6 延伸阅读 / 246
第15章 构造阶段中典型的一天 / 248
15.1 规划团队一天的工作 / 250
15.2 协作构建可利用的解决方案 / 256
15.3 全天活动 / 271
15.4 深入了解关键敏捷实践 / 278
15.5 稳定当日工作 / 287
15.6 观点总结 / 287
15.7 延伸阅读 / 288
第16章 结束构造迭代 / 290
16.1 向关键利益相关者演示解决方案 / 291
16.2 从自己的经历中获得经验 / 293
16.3 评估进展和调整发布计划 / 297
16.4 评估余留风险 / 298
16.5 部署当前构建 / 298
16.6 决定前进策略 / 299
16.7 观点总结 / 302
16.8 延伸阅读 / 303
第17章 案例研究：构造阶段 / 304
17.1 继续AgileGrocers POS案例 / 304
17.2 规划迭代中的工作 / 307
17.3 后续的构造迭代 / 325
17.4 构造阶段中的其他活动 / 331
17.5 结束构造阶段的迭代 / 331
17.6 观点总结 / 332
第五部分 发布解决方案
第18章 移交阶段 / 334
18.1 移交阶段如何运行 / 335
18.2 规划移交阶段 / 336
18.3 确保生产环境就绪 / 337
18.4 让利益相关者为发布做好准备 / 339
18.5 部署解决方案 / 340
18.6 利益相关者会欣然接受吗 / 341
18.7 移交阶段的模式 / 342
18.8 移交阶段的反模式 / 344
18.9 观点总结 / 345
18.10 延伸阅读 / 345
第19章 案例研究：移交阶段 / 346
19.1 制定计划 / 347
19.2 协作部署解决方案 / 349
19.3 AgileGrocers公司欣然接受 / 350
19.4 观点总结 / 351
第六部分 企业环境中的DAD
第20章 治理DAD团队 / 354
20.1 治理要解决什么问题 / 355
20.2 为什么说治理很重要 / 358
20.3 为什么传统的治理策略行不通 / 360
20.4 敏捷治理 / 363
20.5 支持治理的敏捷实践 / 365
20.6 配合IT组织中的其他部门 / 370
20.7 度量敏捷团队 / 372
20.8 风险缓解 / 381
20.9 观点总结 / 381
20.10 延伸阅读 / 382
第21章 纪律 / 383
21.1 采用敏捷开发实践需要纪律 / 383
21.2 减少反馈周期需要纪律 / 384
21.3 持续学习需要纪律 / 385
21.4 增量式交付解决方案需要纪律 / 387
21.5 采用目标驱动的方法需要纪律 / 388
21.6 企业意识需要纪律 / 389
21.7 采用完整生命周期方法需要纪律 / 389
21.8 简化启动阶段需要纪律 / 389
21.9 简化移交阶段需要纪律 / 390
21.10 应用敏捷治理策略需要纪律 / 390
21.11 向精益转型需要纪律 / 390
21.12 观点总结 / 391
21.13 延伸阅读 / 392
