敏捷项目管理模式第五章.docx

敏捷项目管理模式第五章.docx

《敏捷项目管理模式第五章.docx》由会员分享，可在线阅读，更多相关《敏捷项目管理模式第五章.docx（10页珍藏版）》请在冰豆网上搜索。

敏捷项目管理模式第五章

第

敏捷项目管理模式

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

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

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

一个机构地区用Scrum，一个用极限编程（ExtremeProgramming，XP），而另一个使用功能驱动开发（FeatureDrivernDevelopment，FDD），这种情况一点也不稀奇。

并且，应该鼓励使用这种多样性的方法！

因为很有可能的情况是，在中国的项目可以得到Scrum的良好支持（如培训、辅导等），而澳大利亚的项目得到FDD支持会更好些。

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

《相互依赖宣言》的6个原则之一是：

通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。

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

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

5.1敏捷企业架构

敏捷企业总体架构如图5-1所示。

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

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

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

图5-1敏捷企业架构

这个结构有利于组织采取混合的敏捷方法，即每层使用不同的敏捷方法，以满足组织的特定需要。

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

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

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

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

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

5.1.1投资组合治理层

大公司拥有数以百计（如果不是数以千计）的项目。

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

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

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

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

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

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

他们想了解项目进程、投资和风险。

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

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

5.1.2项目管理层

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

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

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

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

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

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

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

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

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

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

5.1.3迭代管理层

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

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

5.1.4技术实践层

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

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

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

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

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

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

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

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

5.2敏捷交付架构

流程也许不如人那么重要，但它绝非不重要。

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

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

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

敏捷交付架构需要体现前几章描述的原则，除了支持企业目标之外，该架构还需要：

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

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

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

●保持灵活和易于适应；

●支持流程的透明化；

●合并知识；

●囊括支持各个阶段的做法；

●提供管理检查点。

敏捷项目管理模式的结构：

构想—推测—探索—适应—结束，重点在交付（执行）和适应（如图5-2所示）。

它基于AdaptiveSoftwareDevelopment（海史密斯，2000）一书提出的一个模式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●构想：

确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。

●推测：

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

●探索：

在短期内计划和提供它经测试的功能，不断致力于减少项目风险和不确定性。

●适应：

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

●结束：

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

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

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

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

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

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

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

5.2.1阶段：

构想

构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。

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

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

首先，我们需要构想提供什么，即产品及项目范围构想；其次，我们需要构想参与者都有谁：

客户、产品经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作。

5.2.2阶段：

推测

“推测”一词首先让人们想到的是不计后果的冒险，但实际上字典上它的定义是“根据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情。

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

肯·德科尔评论道：

“人们认为制定计划就是引进确定性，但事实并非如此。

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

”敏捷项目管理包括的构想和探索比计划和执行要多，它迫使我们面对这样的现实：

不稳定的商业环境和变化多端的产品开发环境。

推测阶段包括：

●收集初始的、广泛的产品要求；

●将工作量定义为一个产品功能清单；

●制订一个迭代的、基于功能的交付计划；

●把风险降低策略纳入计划；

●估计项目成本，并生成其他必要的行政管理和财务信息。

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人团队更敏捷。

只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化。

5.3扩展的敏捷交付架构

图5-4展示的是敏捷交付架构的扩展版。

在这个层面上，该架构确定了做法，也有效地成为混合方法的开始。

它把探索阶段细化分成在迭代期的工作。

这个扩展板的架构也指出了其他每一个阶段的做法。

在接下来的几章中，将会详细描述这个架构中概述的做法。

图5-4扩展的APM交付架构

5.4结束语

像敏捷项目一样，敏捷架构应该在结构和灵活性之间保持平衡。

随着组织中敏捷项目的数量和规模不断增大，组织就需要有一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观。

同时，假如一个项目团队在中国北京，另外一个在华盛顿的西雅图，他们有着不同的团队成员和不同的环境，他们就需要拥有适应这个通用架构和做法的自由权。

这就是“敏捷艺术”，即平衡结构和灵活性的能力。

它用有效的领导力和敏捷经验去发现每个组织的最佳平衡点。