敏捷项目管理（摘录）——敏捷流程架构

84 阅读 0 评论 56 点赞

我是靠谱客的博主勤恳小馒头，最近开发中收集的这篇文章主要介绍敏捷项目管理（摘录）——敏捷流程架构，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

楚凡科技（www.trufun.net) 10年间致力于做中国最专业的软件工程解决方案提供商

规范软件开发过程优化软件开发流程

保证软件开发质量提高软件开发效率

Trufun UML2建模工具、Trufun Bacon 需求管理工具、 Trufun 研发云管理工具等

流程也许不如人那么重要，但它绝非不重要。像其他事物一样，流程必须与企业目标联系起来。如果企业目标是重复性的制造，那么常规性流程是完全适当的，而如果企业目标是可靠的创新，则流程架构必须是有机的、灵活的和容易改变的。敏捷流程架构需要体现其核心原则，除了支持企业目标外，该架构还需要：

支持构想、探索、适应文化；
支持自我组织、自律的团队；
根据项目的不确定性程度，尽量提高可靠性和连贯性；
保持灵活和易于变化；
支持流程的透明化；
与学习结合起来；
将支持各个阶段的做法包括在内；
提供管理检查点、对该构架进行评估。

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

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

敏捷项目管理阶段的命名既反映了活动，也反映了结果。

例如，构想阶段产生项目构想。而且这个命名与传统的阶段命名 —— 如开始、计划、管理、控制—— 彻底分离，意义重大。首先，“构想”代替较传统的“开始”，表示构想的重要性。

第二，推测阶段代替计划阶段。每个词都传达一定的意义，而各个意义来自它们长期的系统用法。“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。我们知道，任何项目的未来都包含着不确定性，尤其是那些探索系数较高的项目，但我们仍在试图“计划”排除该不确定性。我们必须学会推测和适应，而不是计划和建造。

第三，敏捷项目管理模式用探索代替通常的管理阶段。探索，以迭代交付的方式，明确表示它是非线性的、并行的、非瀑布式的模式。在推测阶段提出的问题需要“探索”。鉴于你不能完全预测结果，推测暗示着需要有灵活性。敏捷项目管理模式强调执行以及这样一个事实：它是探索性的而非确定性的。

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

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

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

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

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

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

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

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

收集初始的、广泛的产品要求；
将工作量定义为一个产品功能清单；
制订一个交付计划(发布、里程碑和迭代)，其中包括那些功能的进度表和资源分配；

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

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

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

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

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

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

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

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

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

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

须具备的判断力

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

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

项目规模

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

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

敏捷做法

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

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

在选择和使用这些做法时，我采用了如下指导原则：