2.1 阶段：构想
构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。如果没有构想，其他的项目启动活动都是无用之功。用商业用语来说，构想是项目早期“成功的关键因素”。首先，我们需要构想提供什么，即产品及项目范围构想；其次，我们需要构想参与者都有谁：客户、产品经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作。
2.2 阶段：推测
“推测”一词首先让人们想到的是不计后果的冒险，但实际上字典上它的定义是“根据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情。“计划”一词具有确定和预测的含义，至少对于探索性项目来说，计划的更有用的定义是基于不完全的信息推测或者猜测。肯·德科尔评论道：“人们认为制定计划就是引进确定性，但事实并非如此。他们带来的只不过是衡量绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能重新计划。”敏捷项目管理包括的构想和探索比计划和执行要多，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。
推测阶段包括： ● ● ● ● ●
收集初始的、广泛的产品要求； 将工作量定义为一个产品功能清单； 制订一个迭代的、基于功能的交付计划； 把风险降低策略纳入计划；
估计项目成本，并生成其他必要的行政管理和财务信息。
1
2.3 阶段：探索
探索阶段交付产品功能。从项目管理的角度看，这个阶段有3个关键的活动区域：第一，通过管理工作量和使用适当的技术方法和风险降低策略，按计划交付产品功能；第二，建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代 1. 摘自微软的电子百科全书中的世界英语词典，该书1999年和2000年版权属于微软公司。
- 6 -
领导者推动；第三，管理团队与客户、产品经理和其他利益相关方的相互交流。
2.4 阶段：适应
控制和纠正是这个周期阶段常用的术语。计划制订了，结果监控了，纠正也完成了：这个流程意味着计划是正确的，而如果实际结果与计划不同，则表明计划是错误的。适应意味着修改或改变而不是成功或失败。如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”，则将失败归罪于对计划的变动是没有成效的。非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键部分。
在适应阶段，需要从客户、技术、人员和流程绩效，以及项目状况等方面对结果进行检查。该分析将会对比实际结果和原计划结果，但更重要的是，要根据项目得到的最新信息，思考实际的与修订后的项目前景。修改后的结果将反馈并应用到重新计划工作中，以开始新的迭代。
自构想阶段以后，其循环通常是推测—探索—适应，每次迭代都不断地优化产品。但是对团队收集新信息来说，定期修正构想阶段也尤为重要。
2.5 阶段：结束
在某种程度上，项目由开始和结束来界定。由于许多组织没有明确项目的结束点，而导致与客户之间发生很多问题。项目应该以庆功典礼为结束。结束阶段(以及每次迭代末尾的小型结束)的主要目标是：学习并将学到的东西融入下一次迭代工作中，或者传递给下一个项目团队。
2.6 不是完整的产品生命周期
有人提醒说，本章及后面章节介绍的敏捷流程架构的几个阶段不能构成一个完整的产品生命周期。产品生命周期的前后两个阶段(早期的概念构想阶段和晚期的配置阶段)没被包含在这个架构中，不是因为它们不重要，而是因为它们超出了本书的范围。
- 7 -
2.7 选择和整合做法
接下来的几章将介绍APM交付架构每层的具体做法。这些做法应该看作是一个做法系统，因为只有作为一个系统，他们才能相互补充，从而与价值观和原则保持一致。但他们并不局限于保持一致，他们还着眼于实施。没有做法的原则只是个空壳，而没有原则的做法经常会被毫无判断地生搬硬套。没有原则，我们就不知道如何实施做法。比如说，没有简单原则，人们往往会过多地看重做法的形式和仪式。原则指导做法，做法用实际例子证明原则，两者是相辅相成。
使原则和做法保持一致昭示了这样一个现实：“最好做法”只是虚假的无法实现的梦想。对于某个项目团队非常奏效的做法也许对另一个团队是极其糟糕的。做法就是具体做法，它仅是实现一些目标的方式。一个具体做法只有在特定的环境中，才能知道它是好是坏，这个特定环境可能包括原则、问题类型(如探索性)、团队动力和组织文化。
没有最好的做法，只有更适合具体情况的做法。 后面章节中论述的做法已经在多个不同场合得到证明，其中一些可能在生产型项目中也很有用途，就像本书中没有提到的一些做法同样对敏捷项目也有用一样。在选择和使用这些做法时，作者采用了如下指导原则：
● ● ● ● ● ●
简单的；
再生的而非常规性的； 与敏捷价值观和原则一致的； 关注交付活动(增值)而非合规活动； 最少数量(刚好可以完成工作)的； 相互支持的(做法系统)。
在后面章节中描述，基本上不是新的做法。其中一些是其他人描述的某类做法的变种，一些是为人熟知的，其他的则是人们不太了解的。例如，风险控制做法在项目管理书籍里被广泛论述，而其他的(如参与式决策)则很少论述到。因此，对于风险控制这些通用做法，将作简要论述，或者只提供其他的参考资源，而对于其他地方很少涉及的做法(如决策)，将在本书中较详细地论述。
- 8 -
2.8 需具备的判断力
因为产品和项目管理长期以来受到顺序开发流程的熏染，所以看起来像图5-2那样的图例都被认为是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序，但人们不应该将整个模式看作是固定的。生产型模式所用的阶段名称暗示着一个线性和重复的模式：开始、计划、定义、设计、构建、测试，而这里选用的敏捷项目管理术语是用来表示迭代演变：推测、探索、适应。
过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是盲目的变化。对于任何一种模式，开发团队成员、产品团队成员和高级主管在应用时都需要作出敏锐的判断。
关于敏捷项目管理的一个最常见的问题是：“计划、架构和需求阶段如何？”最简单的答案是：这些是活动而不是阶段。敏捷方法中这些活动所用时间和传统的序列方法一样多，只是在敏捷方法中这些活动被分配到几次迭代和多次功能开发中。
第二个令人关注的是：在初始的软件架构工作中(这节的讨论指的是构建、计划和需求)忽略了一个关键项目，而导致的敏捷开发返工的风险问题。其实与其相当的一个的更大难以形容的风险—— 即前期架构工作出错—— 在顺序开发中也存在。在序列开发过程中，早期的架构决策在项目晚期及实际的构建出现时才能得到验证。到那个时候，已经花费了大量的时间和金钱。到时再改变这个架构，就成为一项重大的耗时的决定，但通常已经不可能修改了。
一切工作都应该是循序渐进的，即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差，因为没有人能够承受得起在项目晚期再改变架构。 2.9 项目规模
敏捷项目管理的核心价值观和原则适用于任何规模的项目，相似的，在后面章节描述的做法也适用于任何规模的项目。但是，对于超过100人的项目团队，可能除了本书中描述的做法外，还需要其他做法或本书描述做法的延伸，其中一些在第11章会有所论述。随着项目团队不断扩大，通常需要有更多的文档、有其他的协调做法、增加仪式或者其他合规活动(如财务控制)，这些扩展的做法同样也受敏捷项目管理的价值观和原则的指导。例如，简化原则仍然适用于大型项目，只不过意味着采用最简单的、适用于
- 9 -
150人而非15人的团队的做法。
一个500人的团队可能不如一个10人团队敏捷，但它可以比竞争对手的500人团队更敏捷。只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化。
3 扩展的敏捷交付架构
图5-4展示的是敏捷交付架构的扩展版。在这个层面上，该架构确定了做法，也有效地成为混合方法的开始。它把探索阶段细化分成在迭代期的工作。这个扩展板的架构也指出了其他每一个阶段的做法。在接下来的几章中，将会详细描述这个架构中概述的做法。
敏捷开发生命周期 构想阶段 项目章程、产品构 想、项目范围和界 限、准备性评估、骨 架结构、团队构想 第1~n次迭代 推测阶段 故事ID 发布计划 探索阶段 迭代交付 项目领导 产品开始阶段 最终评审和接受 最终质量评估和文档 增量交付和最终产品部署 结束阶段 项目反思 最终项目、产品文档 清理余下问题 迭代交付(每1~4周1次) 准备和计划 需求、开发、需求 估计、迭代计划 评审和适应 开发 编程、需求测试(TOO)、演变设计、重组、结对、需求对话 质量评估和接受测试 系统和集成测试、客户接受测试、用途测试 客户关注小组、技术评审、项目状态、迭代反思、更新发布计划 持续：架构和设计演变、持续构建和集成、项目管理、日常站立会议、文档、 变化协调、迁移和集成 故事部署
图5-4 扩展的APM交付架构
- 10 -
4 结束语
像敏捷项目一样，敏捷架构应该在结构和灵活性之间保持平衡。随着组织中敏捷项目的数量和规模不断增大，组织就需要有一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观。同时，假如一个项目团队在中国北京，另外一个在华盛顿的西雅图，他们有着不同的团队成员和不同的环境，他们就需要拥有适应这个通用架构和做法的自由权。这就是“敏捷艺术”，即平衡结构和灵活性的能力。它用有效的领导力和敏捷经验去发现每个组织的最佳平衡点。
- 11 -