《规范敏捷交付：企业级敏捷软件交付的方法与实践》——1.8 目标驱动的交付生命周期...
1.8 目标驱动的交付生命周期
DAD探讨的是从项目启动到产品构造，再到向生产环境中发布版本的完整项目生命周期。我们明确观察到并提出：迭代的地位并不等同。在整个生命周期中，项目不断演进，而工作重点也在不断变化。为了清楚地说明这一点，我们把项目刻划为多个阶段，设定了轻量级的里程碑，以确保我们关注的是在正确的时候做正确的事情。所关注的领域包括愿景确立、架构建模、风险管理和部署规划。这一点与主流敏捷方法不同，主流敏捷方法通常集中在生命周期中的构造阶段。许多细节（例如，如何启动项目）如何执行发布活动，甚至这些活动如何融入到整个生命周期之中，通常都是模糊不清的，不得不留给团队自己来处理。
情况往往是这样，任何参与过Scrum项目的人都会发现，在他们的项目之中Scrum生命周期其实经常会被裁剪，已经变成了类似图1.3中的DAD项目生命周期。该生命周期有以下几个关键特征。
交付生命周期。DAD的生命周期扩展了Scrum的构造周期，明确展示出从项目启动到生产环境（或市场）中发布解决方案的完整交付生命周期。
有明确的阶段。DAD生命周期分为三个不同的阶段，并予以命名，它反映了敏捷的3C节奏：协调—协作—结束（coordinate-collaborate-conclude）。
交付周期融合在整体业务环境之中。DAD的生命周期方法承认，在项目正式启动之前很久，识别和选择项目的活动就已经开始。它也承认，DAD项目团队交付的解决方案一旦进入生产环境（在一些组织中称为业务运维环境），或者，在某些情况下是指商业产品进入市场，就必须进行运维和支持，它还认为重要的反馈来自于那些使用过该方案以前版本的人们。
有明确的里程碑。里程碑是内建于DAD之中的重要的治理策略和风险缓解策略。
图1.3中的生命周期是贯穿于本书的重点，称为DAD的敏捷基本版。我们相信这应该是团队初次接触DAD之时，甚至是敏捷方法的出发点。然而，可以根据需要，对DAD加以裁剪。随着DAD应用经验的不断增加，团队可以选择采取越来越多的精益策略，并最终把生命周期演变成接近于图1.4中所呈现的形式。这种精益版DAD生命周期与基本版相比，主要的不同点是在精益版中，阶段和迭代的节奏消失了，这是为了支持“必需时再做”的工作方式，总之这个策略更适合于纪律严明的团队。
描述过程框架的挑战在于，为了帮助人们理解该框架，必须提供足够的指导，但如果提供太多的指导，就有指手画脚之嫌。在过去的几年里，我们已经帮助各种组织改善了他们的软件开发过程，在此期间，我们发现，各种流程的专家领袖不是偏向这一极端就是偏向那一极端。在描述过程时，要么详尽入微，IBM Rational统一过程（RUP）就是一个例子；要么无足轻重，Scrum正是这样一类的例子。采用RUP的挑战在于，许多团队没有能力对RUP的实施进行恰当的简化，反而往往会导致额外的工作。另一方面，很多Scrum团队存在的问题正好相反，即不知道如何适当地加强过程，所以为了解决Scrum没有涉及的种种问题（这一点在第3章会讨论），团队往往需要投入巨大努力来彻底改造或重新学习有关技术。无论针对哪种方式，看来，如果能在这两个极端之间存在一种中间方法，那么大量的浪费原本就可以避免。
为了应对这一挑战，DAD过程框架提出了目标驱动这一思想，总结参见图1.5。当然，条条大路通罗马，要达成这些目标，有许多条路径，所以简单地描述这些目标是没有价值的。第6章～第19章会按顺序逐一描述DAD的每个阶段，并为实现这些阶段中的目标，提出特定策略、通用策略以及介于两者之间的折中策略。我们的经验表明，这个目标驱动的建设性方法为解决方案交付团队提供了足够多但足够灵活的指导，这样，团队就可以对过程进行适当裁剪，从而解决自己所面对的具体问题。挑战在于，它需要严谨的纪律，这样才能帮助敏捷团队考虑每个目标相关的问题，然后选择出最适合自己的策略。这可能并不是网络上人人都在高谈阔论的时髦的新战略，它需要团队做一些扎实的、必要的工作，而不是接受现成但并不适合自己的策略。
图1.5并不是一个完整的目标清单。有些个人目标，如具体的学习目标和想做有趣工作的愿望、报酬、工作认可度以及项目特别的目标，都没有列出，在实际中可以根据团队自己的情况决定是否增加。
敏捷开发的3C节奏
多年来，我们已经注意到，在各种各样的敏捷过程中都存在一个明显的节奏，或者叫韵律。我们将其称为敏捷开发3C节奏：协调、协作、结束。这类似于戴明提出的概念：计划、执行、检查、行动，即PDCA循环，协调对应于计划，协作对应于执行，结束对应于检查和行动。DAD过程框架从三个层面都体现了敏捷开发的3C节奏。
1）发布节奏。三阶段交付周期中的先启阶段、构造阶段和移交阶段分别对应协调、协作和结束。
2）迭代节奏。DAD构造阶段的迭代始于迭代计划讨论会（协调），做好实施工作（协作），并以演示和回顾结束迭代（结束）。
3）每日节奏。典型的一天以一个简短的协调会开始，接着团队协作开展他们的工作，并以一个可用构建版本（但愿有）结束当天的工作。
为了更好地了解DAD过程框架的内容，下面对DAD中的各个阶段逐一进行概述。
1.8.1 先启阶段
团队在决定直接扎进开发或购买一个解决方案之前，非常有必要花些时间确认项目的目标。在传统的开发方法中，团队会投入大量的时间和精力做前期项目规划。而敏捷方法建议，预先涉及太多细节是不值得的，因为在时间和预算限制内，很少有人能知道真正的需求是什么，真正要实现的是什么。主流敏捷方法建议，在前期规划中只需投入非常小的精力。他们的口号可以简单地解释为“让我们开始吧，我们边走边决定到哪里去”。公平地说，有些敏捷团队会在项目开始前，做一个短期计划迭代，或者做一些计划。有些Scrum团队会把这部分工作称作“Sprint 0”，尽管用词不那么恰当。在极限编程（XP）中，对应的是“规划游戏（Planning Game）”。事实上，在2009年由Ambysoft发起的一项调查发现，团队平均用3.9周来启动一个项目。在DAD中，我们认识到，在典型情况下，启动项目需要几天到几周时间。图1.6概述了先启阶段可能会发生的一些活动，第6章～第12章将对这些活动展开详细的描述。这个阶段结束的标志是，团队为该发布制定了愿景，并得到了利益相关者的同意，同时获得了利益相关者对项目其余阶段至少是下一个阶段的支持。
1.8.2 构造阶段
DAD中的构造阶段是这样一段阶段：在此期间完成对所需要功能的构建。把时间轴分成基于时间盒的多个迭代。对于具体的项目来说，这些迭代应该有相同的持续时间，并且迭代之间通常没有重叠。在图1.7中综述了迭代中可能的活动。对于有些项目来说，其迭代持续时间通常从1周到4周不等。而对于大多数项目来说，最常见的迭代持续时间是2～4周。在每次迭代结束时，团队都应生产出一个可以演示的解决方案的增量版本，这个版本是潜在可利用的，并应完成回归测试。这时，还需要考虑下一步的策略：我们该如何推进项目。在构造阶段，我们可以执行一个额外的迭代，并决定是否要在客户方部署解决方案。如果我们确定有足够的功能来抵消产品化或移交的成本，或者团队生产出了一个有时称为最简市场发布（Minimally Marketable Release，MMR）的版本，那么我们的构造阶段就可以结束，并进入移交阶段。构造阶段的详细内容会在第13章～第17章中进行描述。
1.8.3 移交阶段
移交阶段的重点是把交付的系统部署到生产环境中（或者指商业产品进入市场）。如图1.8所示，在移交时有很多事情要做，而不仅仅只是向服务器复制一些文件。移交所花费的时间和精力会因项目不同而不同：套装软件需要制造和分发软件及相关文档；部署内部系统通常比部署外部系统简单；高可见性系统在向大群体发布前，可能需要由一些小型团体进行广泛的Beta测试；全新的系统发布版可能包含硬件的采购和设置，而更新现有系统可能需要数据转换，以及与用户社区的广泛协调等。项目不同，做法不同。从敏捷角度看，移交阶段结束的标准是，利益相关者准备接受，系统已经完成部署；而从精益开发的角度看，这个阶段结束的标志是，利益相关者已经可以在生产环境中运行解决方案，并对此欣然接受。有关移交阶段的更详细内容会在第18章和第19章中进行描述。
有些敏捷开发人员可能会注意到并提问：图1.8中所列出的有些活动为什么不能在构造迭代中进行？简单的回答是，肯定可以这样做，因为在整个生命周期中，都应努力做尽可能多的测试，都应努力编写和维护所需的文档，等等。在构造迭代的后期，甚至可能需要对利益相关者进行培训，在解决方案已经发布到生产环境中后，就更有可能需要做这样的培训了。在构造阶段，这些事情做得越多，移交阶段就会变得越短。但实际情况是，许多组织只要求在生命周期结束时做测试（即使最后只运行一次回归测试套件），并且在这个时候才开始整理支持文档。2010年11月，在Ambysoft进行的敏捷现状（Agile State of the Art）调查中发现，移交或发布阶段平均花费4.6周。