规范敏捷交付

前言

前言在客户眼中，信息技术（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是在教敏捷专家如何走，而大规模敏捷和精益方法（如看板）是在教他们如何跑。本书能提供什么帮助我们相信，通过阅读本书，读者会在许多方面受益。它描述了一个端到端的敏捷交付周期框架。它描述了常见的敏捷实践，以及这些实践如何融入生命周期，它们之间如何协同工作。它介绍了敏捷团队如何在整个组织范围内以“企业意识”（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章。我们建议组织采纳敏捷方法所推行的、领先的核心敏捷实践，但同时也建议组织有必要选择和补充一些规范的策略和工具，以适应组织和项目的现实需求。顺便说一句，本书的一部分销售额将捐给囊性纤维化基金会和多伦多儿童医院，谢谢你对这些善举的支持。规范敏捷交付网站作为一个社区网站，囊括了有关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 信息及相关技术控制目标TechnologyDAD Disciplined Agile Delivery 规范敏捷交付DDJ Dr. Dobb’ s Journal 《Dr. Dobb’ s Journal》杂志DevOps Development operations DevOpsDI 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 ComposerRSA Rational Software Architect Rational Software ArchitectRTC Rational Team Concert？ Rational Team ConcertRUP 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首席技术官《SDLC3．0：Beyond a Tacit Understanding of Agile》的作者“我注意到，‘认证式敏捷’在组织中已经泛滥有加，它所带来的严重问题，甚至超过已解决的问题。终于，我们看到这个让人眼前一亮的方法，它告诉我们如何通过规范地使用敏捷方法来缔造成功。谢谢Scott和Mark。”——Carson Holmes，第四媒体咨询公司服务交付执行副总裁

内容概要

斯科特·安布勒（Scott W. Ambler）

IBMRational首席敏捷软件开发专家和精益软件开发专家，规范敏捷交付（DAD）概念的提出者和相应过程框架的开发领导者，敏捷建模、敏捷数据、敏捷统一过程和企业统一过程等方法的创始人，敏捷伸缩模型的创建者。著作等身，与他人合著图书20余本，包括《RefactoringDatabases》、《Agile Modeling》、《Agile Database Techniques》、《The ObjectPrimer, 3rd Edition》，以及《The Enterprise UnifiedProcess》等经典著作。此外，他还是《Dr. Dobb’s Journal》杂志的特约资深编辑。他的个人网站是www.ambysoft.com。

马克·莱恩斯（Mark Lines）

资深敏捷软件开发专家，规范敏捷方法教练，善于为软件开发组织提供全方位的指导。他在利用敏捷和精益生产技术加速开发进程和提高产品质量方面拥有丰富的实践经验。出版了多本著作，并经常作为演讲人出现在各种业界会议上。他还是IBMRational和UPMentors（2007年与他人合伙创立）的课程讲师。他的个人网站是www.UPMentors.com，联系方式为：Mark@UPMentors.com。

译者简介

阎小兵（Kevin Yan）

IBM中国开发中心资深开发经理，IBM全球质量软件工程专员。关注和推动企业软件产品开发转型、敏捷开发方法与实践、质量管理与度量，并在相关领域拥有丰富的实践经验。

书籍目录

本书赞誉

中文版序

序

前言

第一部分　DAD概述

第1章　DAD

1.1　背景——敏捷伸缩模型

1.2　DAD过程框架

1.3　以人为核心

1.4　注重学习

1.5　敏捷方法

1.6　混合型过程框架

1.7　是IT解决方案，而不只是软件

1.8　目标驱动的交付生命周期

1.9　企业意识

1.10　风险与价值驱动

1.11　可扩展

1.12　观点总结

1.13　延伸阅读

第2章　敏捷与精益开发简介

2.1　向规范《敏捷宣言》进发

2.2　规范敏捷思想的核心价值观

2.3　规范敏捷开发原则

2.4　精益开发原则

2.5　事实重于巧辩

2.6　观点总结

2.7　延伸阅读

第3章　DAD的根基

3.1　专业术语库

3.2　Scrum

3.3　极限编程

3.4　敏捷建模

3.5　敏捷数据

3.6　精益软件开发

3.7　IBM实践

3.8　开放统一过程

3.9　其他

3.10　谁忽视敏捷实践，谁就会置业务于风险境地

3.11　观点总结

3.12　延伸阅读

第二部分　以人为核心

第4章　角色、权利和责任

4.1　每个人拥有的权利

4.2　每个人承担的责任

4.3　DAD角色

4.4　观点总结

4.5　延伸阅读

第5章　组建DAD团队

5.1　组建高效团队的策略

5.2　完整团队

5.3　团队组织策略

5.4　建立自己的团队

5.5　与其他团队互动

5.6　观点总结

5.7　延伸阅读

第三部分　启动DAD项目

第6章　先启阶段

6.1　先启阶段如何运行

6.2　与企业其他部门的合作

6.3　落实资金

6.4　先启阶段中的其他活动

6.5　在什么情况下需要先启阶段

6.6　先启阶段的模式

6.7　先启阶段的反模式

6.8　观点总结

6.9　延伸阅读

第7章　确定项目愿景

7.1　什么是愿景

7.2　如何创立愿景

7.3　捕捉项目愿景

7.4　让利益相关者同意愿景

7.5　观点总结

7.6　延伸阅读

第8章　确定范围

8.1　选择恰当的需求细化度

8.2　选择正确的模型类型

8.3　选择建模策略

8.4　选择管理工作项的策略

8.5　选择捕获非功能性需求的策略

8.6　观点总结

8.7　延伸阅读

第9章　确定技术策略

9.1　选择架构规格的详细程度

9.2　选择正确的架构模型类型

9.3　选择架构建模策略

9.4　贯穿于生命周期的架构演进

9.5　观点总结

9.6　延伸阅读

第10章　制定发布计划

10.1　谁来制定计划

10.2　选择计划级别

10.3　选择计划策略

10.4　选择节奏

10.5　制定项目进度表

10.6　估算成本和价值

10.7　识别风险

10.8　观点总结

10.9　延伸阅读

第11章　建立工作环境

11.1　组建团队

11.2　选择工具集

11.3　建立实体工作环境

11.4　建立虚拟工作环境

11.5　可视化管理

11.6　使用开发指南

11.7　观点总结

11.8　延伸阅读

第12章　案例研究：先启阶段

12.1　AgileGrocers POS案例简介

12.2　开发共享愿景

12.3　需求预想

12.4　创建用户故事，排序工作项

12.5　架构预想

12.6　发布计划

12.7　先启阶段中的其他活动

12.8　运行先启阶段的其他方法

12.9　结束先启阶段

12.10　观点总结

第四部分　增量式构造可利用的解决方案

第13章　构造阶段

13.1　构造阶段如何运行

13.2　构造迭代的典型节奏

13.3　风险—价值生命周期

13.4　何时可以部署

13.5　构造阶段的模式

13.6　构造阶段的反模式

13.7　观点总结

第14章　启动构造迭代

14.1　敏捷计划的特点

14.2　迭代计划

14.3　计划的可视化

14.4　前瞻性计划和建模

14.5　观点总结

14.6　延伸阅读

第15章　构造阶段中典型的一天

15.1　规划团队一天的工作

15.2　协作构建可利用的解决方案

15.3　全天活动

15.4　深入了解关键敏捷实践

15.5　稳定当日工作

15.6　观点总结

15.7　延伸阅读

第16章　结束构造迭代

16.1　向关键利益相关者演示解决方案

16.2　从自己的经历中获得经验

16.3　评估进展和调整发布计划

16.4　评估余留风险

16.5　部署当前构建

16.6　决定前进策略

16.7　观点总结

16.8　延伸阅读

第17章　案例研究：构造阶段

17.1　继续AgileGrocers POS案例

17.2　规划迭代中的工作

17.3　后续的构造迭代

17.4　构造阶段中的其他活动

17.5　结束构造阶段的迭代

17.6　观点总结

第五部分　发布解决方案

第18章　移交阶段

18.1　移交阶段如何运行

18.2　规划移交阶段

18.3　确保生产环境就绪

18.4　让利益相关者为发布做好准备

18.5　部署解决方案

18.6　利益相关者会欣然接受吗

18.7　移交阶段的模式

18.8　移交阶段的反模式

18.9　观点总结

18.10　延伸阅读

第19章　案例研究：移交阶段

19.1　制定计划

19.2　协作部署解决方案

19.3　AgileGrocers公司欣然接受

19.4　观点总结

第六部分　企业环境中的DAD

第20章　治理DAD团队

20.1　治理要解决什么问题

20.2　为什么说治理很重要

20.3　为什么传统的治理策略行不通

20.4　敏捷治理

20.5　支持治理的敏捷实践

20.6　配合IT组织中的其他部门

20.7　度量敏捷团队

20.8　风险缓解

20.9　观点总结

20.10　延伸阅读

第21章　纪律

21.1　采用敏捷开发实践需要纪律

21.2　减少反馈周期需要纪律

21.3　持续学习需要纪律

21.4　增量式交付解决方案需要纪律

21.5　采用目标驱动的方法需要纪律

21.6　企业意识需要纪律

21.7　采用完整生命周期方法需要纪律

21.8　简化启动阶段需要纪律

21.9　简化移交阶段需要纪律

21.10　应用敏捷治理策略需要纪律

21.11　向精益转型需要纪律

21.12　观点总结

21.13　延伸阅读

编辑推荐

《规范敏捷交付:企业级敏捷软件交付的方法与实践》编辑推荐：IBM首席敏捷方法专家、世界级敏捷软件开发大师系统深入地讲解规范敏捷交付过程框架的概念、原理和使用方法，为交付大型的企业级软件提供了行之有效的方法与最佳实践。

作者简介

本书是敏捷软件开发领域的经典著作，由IBM首席敏捷方法专家、世界级敏捷软件开发大师撰写，系统深入地讲解了规范敏捷交付（DAD）的概念和原理，以及规范敏捷交付过程框架的使用方法和技巧，为交付大型的企业级敏捷软件提供了行之有效的方法与最佳实践。

本书共21章，分为六部分：第一部分（第1～3章）介绍了DAD的概念、原理和根基，以及敏捷与精益开发方法的核心价值与原则；第二部分（第4～5章）讲解了DAD方法中的角色、权利和责任，以及如何组建DAD团队；第三部分（第6～12章）讲解了启动DAD项目的步骤和方法；第四部分（第13～17章）讲解了以增量的方式构造可利用的解决方案的步骤和方法；第五部分（第18～19章）讲述了如何发布解决方案，第六部分（第20～21章）介绍了企业环境中的DAD，讨论了如何治理DAD团队，以及敏捷开发实践中需要遵守的纪律。

---

 规范敏捷交付下载

---