敏捷项目管理模式

敏捷项目管理模式

本书的第1版重点介绍了敏捷流程架构的几个主要项目阶段。然而，在过去5年中，敏捷方法已经开始广泛应用于较大型的项目和组织中，因此构建一个较为全面的敏捷企业架构显得尤为必要。例如，在大型跨国组织中，其项目并非都是敏捷项目，即使都是，某些地区可能使用不同于其他项目的敏捷方法。一个机构地区用Scrum，一个用极限编程(Extreme Programming，XP)，而另一个使用功能驱动开发(Feature Drivern Development，FDD)，这种情况一点也不稀奇。并且，应该鼓励使用这种多样性的方法！因为很有可能的情况是，在中国的项目可以得到Scrum的良好支持(如培训、辅导等)，而澳大利亚的项目得到FDD支持会更好些。

敏捷开发的信条之一是适应不同情况。《相互依赖宣言》的6个原则之一是：通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。因此，很难在一个跨国组织中，只使用单一的标准化敏捷方法。然而，使用一个共同的架构，而且能在其中选择各自不同的敏捷方法，对于较大型组织来讲，无疑具有很大的吸引力。

1 敏捷企业架构

敏捷企业总体架构如图5-1所示。投资组合治理层提供一些常见的检查点；项目管理层对各种项目的管理提供指导。项目管理层和迭代管理层不同，其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。最后，区分迭代管理层和技术做法层，有助于把核心技术做法融合到几个项目或者迭代管理方法中去。

投资组合治理

项目管理

迭代代理

技术实践

图5-1 敏捷企业架构

这个结构有利于组织采取混合的敏捷方法，即每层使用不同的敏捷方法，以满足组织的特定需要。该架构倡导底层(技术实践层)具有较大灵活性，上层(项目管理层)灵活性较小。这种结构认同没有哪一种敏捷方法适合所有层次。事实上，组织中使用的所有敏捷方法都是混合型的。例如，一个组织的项目管理层可能采用APM(和部分PMBOK 的组合)，迭代管理层用Scrum, 而在技术层选用XP做法。通过汲取几种敏捷方法的优点，公司可以构建高效的混合方法，或者可以为组织的不同部分构建几种不同的组合方法。

1.1 投资组合治理层

大公司拥有数以百计(如果不是数以千计)的项目。其中，有的敏捷，有的传统；有的使用这种敏捷方法，有的使用另外一种；有的使用敏捷和传统的混合方法。即使一个组织已经决心向敏捷组织转变，在维期几年的转变期间，将会混合使用各种方法。主管们需要的就是一个通用的架构，可以用来评估所有项目。这个架构涉及主管们所关心的主要问题——投资和风险。主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。他们不会真的关心需求文档是否完成了。他们想了解项目进程、投资和风险。因此无论项目是什么类型——敏捷或是其他，都需要创建一个管理机制，解决这两个关键的代表项目属性的指标。第12章将会详细讨论投资组合治理层。

1.2 项目管理层

许多人认为项目管理即是与核心小组的外围利益相关者打交道，而迭代管理与核心小组的内部利益相关者打交道。这的确是两者差异的一部分，但只是一半。另一个很大的不同是一个是管理发布，一个是管理迭代。一个完整的项目发布计划(见第7章和第8章)，涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。

项目管理还包括与核心小组外围的利益相关者和供应商合作。因此，项目管理层关注全面的项目/发布活动，协调多功能团队和管理项目外围事件。除此之外，像风险分析、合同管理等凡是对项目有用的做法，无论敏捷与否，都属于这个管理层的管理范畴。(这些做法可能来源自美国项目管理协会的PMBK)。

需要指明的是项目管理和迭代管理是可以是同一个领导者，也可以是不同的领导者，取决于项目的大小。例如，一个有4个团队的大项目可能每个团队有一个迭代经理，整个项目有一个项目经理。

1.3 迭代管理层

迭代管理层关注每个短期迭代的计划、执行和团队领导。本章最后一节会概述一下区分迭代和项目管理层的原因，基本上区分的是发布和迭代工作，以及项目内部和外部的管理活动。

1.4 技术实践层

软件项目中的技术实践，包括从持续集成到结对编程，从测试开发到重构等做法。硬件项目可能采用一系列工程做法，从电子到机械不等。虽然本书的重点是其他三层，但是项目有效执行的基础在于技术领域。在各种各样的组织中，变革技术实践是实施敏捷方法的关键。例如，持续集成和自动化测试是不能忽略的核心敏捷软件做法。

分离出技术实践层的另外一个原因是，使敏捷项目管理更适合各种项目和产品类型。尽管我很难做到让电子工程师或者机械工程师准备结对编程，但是事实证明，敏捷软件的等值做法在各种产品开发领域都很有价值。此外，除了硬件项目中可能存在较长时间的迭代外，投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

2 敏捷交付架构

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

●支持构想、探索、适应文化；

●

支持自我组织、自律的团队； ●

根据项目的不确定性程度，尽量提高可靠性和连贯性； ●

保持灵活和易于适应； ●

支持流程的透明化； ●

合并知识； ●

囊括支持各个阶段的做法； ● 提供管理检查点。

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

构想

故事

清单 推测 构想 适应 探索

发布

计划 结束

适应性 行动 最终产品 完成的故事

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

该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同，其意义重大。第一，“构想”代替较传统的“开始”，指出构想的重要性；第二，推测阶段代替计划阶段。每个词都传达一定的意义，而各个意义来自他们长期的系统用法。“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。我们必须学会推测和适应，而不是计划和建造。

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