敏捷项目管理流程图

相关推荐

敏捷项目管理流程图

　　敏捷项目管理流程是怎么样的？你知道吗？各位，看看下面，了解一下吧！

　　敏捷项目管理流程图

　　敏捷项目管理模式的结构：构想—推测—探索—适应—结束，重点在交付(执行)和适应(参见图4-1)。

　　图4-1 敏捷项目管理流程架构

　　1. 构想：确定产品构想、项目范围、项目社团以及团队共同工作的方式。

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

　　2. 推测：制定基于功能的发布计划、里程碑和迭代计划，确保交付构想的产品。

　　“推测”一词首先让人们想到不计后果的冒险景象，但实际上字典对它的定义是“根据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情。“计划”一词具有确定和预测的含义，而计划的更有用的定义，至少对于探索性项目来说，是基于不完全的信息推测或者猜测。我的同事肯·德科尔提出了他的伟大看法：“人们认为制定计划可以产生确定性，但事实远非如此。他们带来的只不过是衡量他们绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能重新计划。”

　　敏捷项目管理更多的'是构想和探索，而不是计划和执行，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。推测阶段实际上是构想阶段的延伸并与它相互影响，它包括：

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

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

　　制订一个交付计划(发布、里程碑和迭代)，其中包括那些功能的进度表和资源分配；

　　在估计项目成本这个计划中加入风险降低策略，并生成其他必要的行政管理和财务信息。

　　3. 探索：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。

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

　　控制和纠正是这个周期阶段常用的术语。计划制订了，结果监控了、纠正也完成了：这个流程暗示着计划是正确的，而如果实际结果与计划不同，则是错误的。

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

　　“适应”意味着修改或改变而不是成功或失败。如果项目的指导哲学认为适应变化比执行计划更重要，则将失败归罪于计划的变更是不会有任何结果的。非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键。

　　自构想阶段以后，其循环通常是推测—探索—适应，每次迭代都不断对产品进行提炼。但要是团队收集到新的信息，定期地回到构想阶段也很有必要。

　　在适应阶段，需要从客户、技术、人员和流程绩效、以及项目状况等方面对结果进行评估。该分析将会对比实际结果和计划的结果，但更重要的是，要根据项目得到的最新信息，思考实际的与修订后的项目前景。修改后的结果将返回、融入到重新计划工作中，开始新的迭代。

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

　　在某种程度上，项目根据开始和结束来界定。许多组织由于没有明确项目的终结点，通常在客户之间会造成理解问题。项目应该以庆祝方式结束。结束阶段以及每次迭代末尾的“小型”结束的主要目标是：学习并将学到的东西融入到下一次迭代工作中，或者传递给下一个项目团队。

　　须具备的判断力

　　产品和项目管理长期以来受顺序开发流程的熏染，像图4-1那样的图看起来都像是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序，但我们不应该将整个模式看作是固定的。生产型模式所用的阶段词语暗示着一个线性模式：开始、计划、管理、控制，而这里选用的敏捷项目管理术语是用来表示迭代演变的：推测、探索、适应。

　　过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是愚蠢的变化。对于任何一种模式，开发团队成员、客户团队成员和高级主管在应用时都需要作出敏锐的判断。

　　项目规模

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

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

　　敏捷做法

　　在敏捷项目管理的每个阶段中都有与敏捷价值观和指导原则相一致的具体做法。这些做法应该看作是一个“做法系统”，因为它们作为一个系统相互补充，与价值观和原则保持一致。但它们并不局限于保持一致，它们还着眼于实施。没有做法的原则只是个空壳，而没有原则的做法往往会毫无判断地被生搬硬套。没有原则，我们就不知道“如何”实施做法，比如说，没有简单原则，我们往往会过多地看重做法的形式和仪式。原则指导做法，做法用实际例子证明原则，它们是相辅相成的。

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

【敏捷项目管理流程图】相关文章：

传统项目管理与现代项目管理的优缺点03-14