前言

在客户眼中，信息技术（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）和精益方法（如看板）是在教他们如何跑。

目录