敏捷项目管理模式(第五章)

本书的第1版重点介绍了敏捷流程架构的几个主要项目阶段。

然而，在过去5年中，敏捷方法已经开始广泛应用于较大型的项目和组织中，因此构建一个较为全面的敏捷企业架构显得尤为必要。

例如，在大型跨国组织中，其项目并非都是敏捷项目，即使都是，某些地区可能使用不同于其他项目的敏捷方法。

一个机构地区用Scrum，一个用极限编程(Extreme Programming，XP)，而另一个使用功能驱动开发(Feature Drivern Development，FDD)，这种情况一点也不稀奇。

并且，应该鼓励使用这种多样性的方法！因为很有可能的情况是，在中国的项目可以得到Scrum的良好支持(如培训、辅导等)，而澳大利亚的项目得到FDD支持会更好些。

敏捷开发的信条之一是适应不同情况。

《相互依赖宣言》的6个原则之一是：通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。

因此，很难在一个跨国组织中，只使用单一的标准化敏捷方法。

然而，使用一个共同的架构，而且能在其中选择各自不同的敏捷方法，对于较大型组织来讲，无疑具有很大的吸引力。

第5章敏捷项目管理模式5.1 敏捷企业架构敏捷企业总体架构如图5-1所示。

投资组合治理层提供一些常见的检查点；项目管理层对各种项目的管理提供指导。

项目管理层和迭代管理层不同，其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。

最后，区分迭代管理层和技术做法层，有助于把核心技术做法融合到几个项目或者迭代管理方法中去。

投资组合治理项目管理迭代代理技术实践图5-1 敏捷企业架构这个结构有利于组织采取混合的敏捷方法，即每层使用不同的敏捷方法，以满足组织的特定需要。

该架构倡导底层(技术实践层)具有较大灵活性，上层(项目管理层)灵活性较小。

这种结构认同没有哪一种敏捷方法适合所有层次。

事实上，组织中使用的所有敏捷方法都是混合型的。

例如，一个组织的项目管理层可能采用APM(和部分PMBOK 的组合)，迭代管理层用Scrum, 而在技术层选用XP做法。

通过汲取几种敏捷方法的优点，公司可以构建高效的混合方法，或者可以为组织的不同部分构建几种不同的组合方法。

5.1.1 投资组合治理层大公司拥有数以百计(如果不是数以千计)的项目。

其中，有的敏捷，有的传统；有的使用这种敏捷方法，有的使用另外一种；有的使用敏捷和传统的混合方法。

即使一个组织已经决心向敏捷组织转变，在维期几年的转变期间，将会混合使用各种方法。

主管们需要的就是一个通用的架构，可以用来评估所有项目。

这个架构涉及主管们所关心的主要问题——投资和风险。

主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。

他们不会真的关心需求文档是否完成了。

他们想了解项目进程、投资57敏捷项目管理(第2版)和风险。

因此无论项目是什么类型——敏捷或是其他，都需要创建一个管理机制，解决这两个关键的代表项目属性的指标。

第12章将会详细讨论投资组合治理层。

5.1.2 项目管理层许多人认为项目管理即是与核心小组的外围利益相关者打交道，而迭代管理与核心小组的内部利益相关者打交道。

这的确是两者差异的一部分，但只是一半。

另一个很大的不同是一个是管理发布，一个是管理迭代。

一个完整的项目发布计划(见第7章和第8章)，涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。

项目管理还包括与核心小组外围的利益相关者和供应商合作。

因此，项目管理层关注全面的项目/发布活动，协调多功能团队和管理项目外围事件。

除此之外，像风险分析、合同管理等凡是对项目有用的做法，无论敏捷与否，都属于这个管理层的管理范畴。

(这些做法可能来源自美国项目管理协会的PMBK)。

需要指明的是项目管理和迭代管理是可以是同一个领导者，也可以是不同的领导者，取决于项目的大小。

例如，一个有4个团队的大项目可能每个团队有一个迭代经理，整个项目有一个项目经理。

5.1.3 迭代管理层迭代管理层关注每个短期迭代的计划、执行和团队领导。

本章最后一节会概述一下区分迭代和项目管理层的原因，基本上区分的是发布和迭代工作，以及项目内部和外部的管理活动。

5.1.4 技术实践层软件项目中的技术实践，包括从持续集成到结对编程，从测试开发到重构等做法。

硬件项目可能采用一系列工程做法，从电子到机械不等。

虽然本书的重点是其他三层，但是项目有效执行的基础在于技术领域。

在各种各样的组织中，变革技术实践是实施敏捷方法的关键。

例如，持续集成和自动化测试是不能忽略的核心敏捷软件做法。

分离出技术实践层的另外一个原因是，使敏捷项目管理更适合各种项目和产品类型。

尽管我很难做到让电子工程师或者机械工程师准备结对编程，但是事实证明，敏捷58第5章敏捷项目管理模式软件的等值做法在各种产品开发领域都很有价值。

此外，除了硬件项目中可能存在较长时间的迭代外，投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

5.2 敏捷交付架构流程也许不如人那么重要，但它绝非不重要。

在敏捷圈内，流程被指责为静止的、常规的和难以改变的。

就流程本身而言，不应该是负面的，它必须同企业目标联系起来。

如果目标是重复性的制造，那么常规性流程是完全合理的；而如果目标是可靠的创新，则流程架构必须是有组织的、灵活的和容易适应的。

敏捷交付架构需要体现前几章描述的原则，除了支持企业目标之外，该架构还需要：●支持构想、探索、适应文化；●支持自我组织、自律的团队；●根据项目的不确定性程度，尽量提高可靠性和连贯性；●保持灵活和易于适应；●支持流程的透明化；●合并知识；●囊括支持各个阶段的做法；●提供管理检查点。

敏捷项目管理模式的结构：构想—推测—探索—适应—结束，重点在交付(执行)和适应(如图5-2所示)。

它基于Adaptive Software Development(海史密斯，2000)一书提出的一个模式。

59敏捷项目管理(第2版)60构想故事清单推测构想适应探索发布计划结束适应性行动最终产品完成的故事图5-2 敏捷项目管理交付架构该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同，其意义重大。

第一，“构想”代替较传统的“开始”，指出构想的重要性；第二，推测阶段代替计划阶段。

每个词都传达一定的意义，而各个意义来自他们长期的系统用法。

“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。

许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。

我们必须学会推测和适应，而不是计划和建造。

第三，敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。

以迭代交付的方式，很明显探索是非线性的、并存的、非瀑布式的模式。

在推测阶段提出的问题需要“探索”。

鉴于结果不能完全预测，推测暗示着灵活性的需求基于现实。

敏捷项目管理模式强调执行以及探索性而非确定性。

实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段。

最后，敏捷项目管理模式以结束阶段收尾，这个阶段的主要目标是传递知识，当然它也是一个庆典。

总之，敏捷项目管理的5个阶段是：●构想：确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。

●推测：制定基于性能和/或功能的发布计划，确保交付构想的产品。

●探索：在短期内计划和提供它经测试的功能，不断致力于减少项目风险和不第5章 敏捷项目管理模式61确定性。

●适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。

● 结束：终止项目、交流主要的学习成果并庆祝。

图5-2展示了所有的阶段和工作流程；图5-3表示的是两个主要的合作周期(构想周期和探索周期)中的相同活动。

构想周期包括构想和推测阶段(产品构想、项目目标和约束、发布计划)；而探索周期包括探索和适应阶段(迭代计划、开发和审核/调整)。

图5-3强调周期而不是流程，说明在整个项目中，全部或者部分构想周期可能会多次执行。

例如，可能(应该)每次或者每两次迭代就需要构建一个修改后的发布计划。

在费时较长的项目中，可能会定期修正整个构想周期的结果。

构想周期产品构想 发布计划 项目范围 和界限 审查和适应 开发产品：模拟、模型、实际产品、工程面包板、关键中间件 迭代计划探索周期图5-3 敏捷项目管理的构想和探索周期5.2.1 阶段：构想构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。

如果没有构想，其他的项目启动活动都是无用之功。

用商业用语来说，构想是项目早期“成功的关键因素”。

首先，我们需要构想提供什么，即产品及项目范围构想；其次，我们需要构想参与者都有谁：客户、产品经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作。

5.2.2 阶段：推测“推测”一词首先让人们想到的是不计后果的冒险，但实际上字典上它的定义是“根敏捷项目管理(第2版)据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情1。

“计划”一词具有确定和预测的含义，至少对于探索性项目来说，计划的更有用的定义是基于不完全的信息推测或者猜测。

肯·德科尔评论道：“人们认为制定计划就是引进确定性，但事实并非如此。

他们带来的只不过是衡量绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能重新计划。

”敏捷项目管理包括的构想和探索比计划和执行要多，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。

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

5.2.3 阶段：探索探索阶段交付产品功能。

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

5.2.4 阶段：适应控制和纠正是这个周期阶段常用的术语。

计划制订了，结果监控了，纠正也完成了：这个流程意味着计划是正确的，而如果实际结果与计划不同，则表明计划是错误的。

适应意味着修改或改变而不是成功或失败。

如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”，则将失败归罪于对计划的变动是没有成效的。

非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键部分。

在适应阶段，需要从客户、技术、人员和流程绩效，以及项目状况等方面对结果进行检查。

该分析将会对比实际结果和原计划结果，但更重要的是，要根据项目得到的最1. 摘自微软的电子百科全书中的世界英语词典，该书1999年和2000年版权属于微软公司。