敏捷管理：敏捷交付架构

5.2 敏捷交付架构

流程也许不如人那么重要，但它绝非不重要。在敏捷圈内，流程被指责为静止的、常规的和难以改变的。就流程本身而言，不应该是负面的，它必须同企业目标联系起来。如果目标是重复性的制造，那么常规性流程是完全合理的；而如果目标是可靠的创新，则流程架构必须是有组织的、灵活的和容易适应的。敏捷交付架构需要体现前几章描述的原则，除了支持企业目标之外，该架构还需要：

● 支持构想、探索、适应文化；
● 支持自我组织、自律的团队；
● 根据项目的不确定性程度，尽量提高可靠性和连贯性；
● 保持灵活和易于适应；
● 支持流程的透明化；
● 合并知识；
● 囊括支持各个阶段的做法；
● 提供管理检查点。

敏捷项目管理模式的结构：构想—推测—探索—适应—结束，重点在交付(执行)和适应(如图5-2所示)。它基于Adaptive Software Development(海史密斯，2000)一书提出的一个模式。

图5-2 敏捷项目管理交付架构

该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同，其意义重大。

第一，“构想”代替较传统的“开始”，指出构想的重要性；

第二，推测阶段代替计划阶段。每个词都传达一定的意义，而各个意义来自他们长期的系统用法。“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。我们必须学会推测和适应，而不是计划和建造。

第三，敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭代交付的方式，很明显探索是非线性的、并存的、非瀑布式的模式。在推测阶段提出的问题需要“探索”。鉴于结果不能完全预测，推测暗示着灵活性的需求基于现实。敏捷项目管理模式强调执行以及探索性而非确定性。实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段。最后，敏捷项目管理模式以结束阶段收尾，这个阶段的主要目标是传递知识，当然它也是一个庆典。

总之，敏捷项目管理的5个阶段是：

● 构想：确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。
● 推测：制定基于性能和/或功能的发布计划，确保交付构想的产品。
● 探索：在短期内计划和提供它经测试的功能，不断致力于减少项目风险和不确定性。
● 适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
● 结束：终止项目、交流主要的学习成果并庆祝。

图5-2展示了所有的阶段和工作流程；

图5-3表示的是两个主要的合作周期(构想周期和探索周期)中的相同活动。构想周期包括构想和推测阶段(产品构想、项目目标和约束、发布计划)；而探索周期包括探索和适应阶段(迭代计划、开发和审核/调整)。图5-3强调周期而不是流程，说明在整个项目中，全部或者部分构想周期可能会多次执行。例如，可能(应该)每次或者每两次迭代就需要构建一个修改后的发布计划。在费时较长的项目中，可能会定期修正整个构想周期的结果。

图5-3 敏捷项目管理的构想和探索周期

5.2.1 阶段：构想

构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。如果没有构想，其他的项目启动活动都是无用之功。用商业用语来说，构想是项目早期“成功的关键因素”。首先，我们需要构想提供什么，即产品及项目范围构想；其次，我们需要构想参与者都有谁：客户、产品经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作。

5.2.2 阶段：推测

“推测”一词首先让人们想到的是不计后果的冒险，但实际上字典上它的定义是“根据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情[1]。“计划”一词具有确定和预测的含义，至少对于探索性项目来说，计划的更有用的定义是基于不完全的信息推测或者猜测。肯·德科尔评论道：“人们认为制定计划就是引进确定性，但事实并非如此。他们带来的只不过是衡量绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能重新计划。”敏捷项目管理包括的构想和探索比计划和执行要多，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。

推测阶段包括：

● 收集初始的、广泛的产品要求；
● 将工作量定义为一个产品功能清单；
● 制订一个迭代的、基于功能的交付计划；
● 把风险降低策略纳入计划；
● 估计项目成本，并生成其他必要的行政管理和财务信息。

5.2.3 阶段：探索

探索阶段交付产品功能。从项目管理的角度看，这个阶段有3个关键的活动区域：第一，通过管理工作量和使用适当的技术方法和风险降低策略，按计划交付产品功能；第二，建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代领导者推动；第三，管理团队与客户、产品经理和其他利益相关方的相互交流。

5.2.4 阶段：适应

控制和纠正是这个周期阶段常用的术语。计划制订了，结果监控了，纠正也完成了：这个流程意味着计划是正确的，而如果实际结果与计划不同，则表明计划是错误的。适应意味着修改或改变而不是成功或失败。如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”，则将失败归罪于对计划的变动是没有成效的。非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键部分。
在适应阶段，需要从客户、技术、人员和流程绩效，以及项目状况等方面对结果进行检查。该分析将会对比实际结果和原计划结果，但更重要的是，要根据项目得到的最新信息，思考实际的与修订后的项目前景。修改后的结果将反馈并应用到重新计划工作中，以开始新的迭代。
自构想阶段以后，其循环通常是推测—探索—适应，每次迭代都不断地优化产品。但是对团队收集新信息来说，定期修正构想阶段也尤为重要。

5.2.5 阶段：结束

在某种程度上，项目由开始和结束来界定。由于许多组织没有明确项目的结束点，而导致与客户之间发生很多问题。项目应该以庆功典礼为结束。结束阶段(以及每次迭代末尾的小型结束)的主要目标是：学习并将学到的东西融入下一次迭代工作中，或者传递给下一个项目团队。

5.2.6 不是完整的产品生命周期

有人提醒说，本章及后面章节介绍的敏捷流程架构的几个阶段不能构成一个完整的产品生命周期。产品生命周期的前后两个阶段(早期的概念构想阶段和晚期的配置阶段)没被包含在这个架构中，不是因为它们不重要，而是因为它们超出了本书的范围。

5.2.7 选择和整合做法

接下来的几章将介绍APM交付架构每层的具体做法。这些做法应该看作是一个做法系统，因为只有作为一个系统，他们才能相互补充，从而与价值观和原则保持一致。但他们并不局限于保持一致，他们还着眼于实施。没有做法的原则只是个空壳，而没有原则的做法经常会被毫无判断地生搬硬套。没有原则，我们就不知道如何实施做法。比如说，没有简单原则，人们往往会过多地看重做法的形式和仪式。原则指导做法，做法用实际例子证明原则，两者是相辅相成。

使原则和做法保持一致昭示了这样一个现实：“最好做法”只是虚假的无法实现的梦想。对于某个项目团队非常奏效的做法也许对另一个团队是极其糟糕的。做法就是具体做法，它仅是实现一些目标的方式。一个具体做法只有在特定的环境中，才能知道它是好是坏，这个特定环境可能包括原则、问题类型(如探索性)、团队动力和组织文化。

没有最好的做法，只有更适合具体情况的做法。

后面章节中论述的做法已经在多个不同场合得到证明，其中一些可能在生产型项目中也很有用途，就像本书中没有提到的一些做法同样对敏捷项目也有用一样。在选择和使用这些做法时，作者采用了如下指导原则：

● 简单的；
● 再生的而非常规性的；
● 与敏捷价值观和原则一致的；
● 关注交付活动(增值)而非合规活动；
● 最少数量(刚好可以完成工作)的；
● 相互支持的(做法系统)。

在后面章节中描述，基本上不是新的做法。其中一些是其他人描述的某类做法的变种，一些是为人熟知的，其他的则是人们不太了解的。例如，风险控制做法在项目管理书籍里被广泛论述，而其他的(如参与式决策)则很少论述到。因此，对于风险控制这些通用做法，将作简要论述，或者只提供其他的参考资源，而对于其他地方很少涉及的做法(如决策)，将在本书中较详细地论述。

5.2.8 需具备的判断力

因为产品和项目管理长期以来受到顺序开发流程的熏染，所以看起来像图5-2那样的图例都被认为是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序，但人们不应该将整个模式看作是固定的。生产型模式所用的阶段名称暗示着一个线性和重复的模式：开始、计划、定义、设计、构建、测试，而这里选用的敏捷项目管理术语是用来表示迭代演变：推测、探索、适应。
过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是盲目的变化。对于任何一种模式，开发团队成员、产品团队成员和高级主管在应用时都需要作出敏锐的判断。

关于敏捷项目管理的一个最常见的问题是：“计划、架构和需求阶段如何？”最简单的答案是：这些是活动而不是阶段。敏捷方法中这些活动所用时间和传统的序列方法一样多，只是在敏捷方法中这些活动被分配到几次迭代和多次功能开发中。

第二个令人关注的是：在初始的软件架构工作中(这节的讨论指的是构建、计划和需求)忽略了一个关键项目，而导致的敏捷开发返工的风险问题。其实与其相当的一个的更大难以形容的风险—— 即前期架构工作出错—— 在顺序开发中也存在。在序列开发过程中，早期的架构决策在项目晚期及实际的构建出现时才能得到验证。到那个时候，已经花费了大量的时间和金钱。到时再改变这个架构，就成为一项重大的耗时的决定，但通常已经不可能修改了。

一切工作都应该是循序渐进的，即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差，因为没有人能够承受得起在项目晚期再改变架构。

5.2.9 项目规模

敏捷项目管理的核心价值观和原则适用于任何规模的项目，相似的，在后面章节描述的做法也适用于任何规模的项目。但是，对于超过100人的项目团队，可能除了本书中描述的做法外，还需要其他做法或本书描述做法的延伸，其中一些在第11章会有所论述。随着项目团队不断扩大，通常需要有更多的文档、有其他的协调做法、增加仪式或者其他合规活动(如财务控制)，这些扩展的做法同样也受敏捷项目管理的价值观和原则的指导。例如，简化原则仍然适用于大型项目，只不过意味着采用最简单的、适用于150人而非15人的团队的做法。

一个500人的团队可能不如一个10人团队敏捷，但它可以比竞争对手的500人团队更敏捷。只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化。

1. 摘自微软的电子百科全书中的世界英语词典，该书1999年和2000年版权属于微软公司。

PMP真题：
During the project execution phase, project sponsors communicate directly with team members and subcontractors. Project sponsors occasionally provide them with guidance on implementation methods, work skills, and task sequencing. What should the project manager do?
1).Use interpersonal skills to let project sponsors view communication management plans
2).Update the relevant parties to participate in the plan, prohibit project sponsors from communicating directly with teams and subcontractors
3).Update execution, responsibility, consulting and informed (RACI) Matrix
4).Update the project sponsors and team’s communication with subcontractors to the problem log
在项目执行阶段，项目发起人直接与团队成员和分包商沟通。项目发起人偶尔向他们提供有关实施方法、工作技巧和任务排序的指导。项目经理应该怎么做？
A.使用人际关系技能让项目发起人查阅沟通管理计划
B.更新相关方参与计划，禁止项目发起人与团队和分包商直接沟通
C.更新执行、负责、咨询和知情（RACI）矩阵
D.将项目发起人与团队和分包商的沟通更新到问题日志

答案：A

解析：定位 .（管理）规划沟通管理。说明解析：PMBOK（6）P377-10.1.3.1规划沟通管理-沟通管理计划。描述将如何规划、结构化、执行与监督项目沟通。包括接收信息的人员或群体，他们的需要、需求和期望。包括负责沟通相关信息的人员等。选项B.禁止发起人不能做，也做不到。选项C.在RACI矩阵中界定项目团队的责任，不包括发起人。选项D.更新问题日志时应记录出现的问题及其处理进展和解决办法，采取了解决措施后才更新问题日志。

优培东方
PMP^®2026年报名招生正在进行