把敏捷融合到瀑布式环境中

每位项目经理都可以成功地将敏捷融合到瀑布式环境中，这样可以提高项目的可预测性、提高成本效益，并促使项目最终获得成功。

曾经项目管理人员认为敏捷只是一种时尚。敏捷宣言发表 10 年来，这种方法已经渐趋成熟：它已经从边缘方法逐渐成为核心方法，并且从只应用于小型软件公司，发展到已应用于大多数的企业组织。敏捷不是银弹，它也需要适应复杂多变的企业环境。本文的目的正是要说明在企业环境里，项目经理怎样才能成功地在项目中应用敏捷。

我认为敏捷方法最好用于管理产品，不过用于管理项目也很有效。只是项目经理必须理解三条关键原则，那样才能充分发挥敏捷的力量，从而改善项目的交付成果。在本文中，我将讨论并破除关于人们通常认为“项目不是敏捷模式就是瀑布模式”的两个神话，再与大家回顾四种增量敏捷模型，并说明项目经理和其他特定的敏捷团队负责人如何使用这些模型。最后，我会推荐一个三层嵌套的“信封”模型，讲解在瀑布环境中，利用你对项目管理和产品管理的理解、结合你精心选取的管理方法，如何使用信封模型来管理敏捷项目。项目经理大可放心，在敏捷项目里他们的作用非常重要，不仅如此，对于大型项目的成功，他们也是必不可少的。

介绍

今年人们庆祝了敏捷宣言发布 10 周年。在这十年间，敏捷从项目管理界中的无名小卒发展成了主流的方法。2009 年，在 Version One 的敏捷调查中，有 84%（Version One，2009）的调查对象表示，他们在某种程度上使用了敏捷。2010 年，这个数据跃至 90%（Version One，2010）。然而，对许多企业高管、总监和经理来说，敏捷仍然让他们感到困惑、模糊并且不可信。

理解以下三条关键原则，每位项目经理就都可以在瀑布环境中成功地融合敏捷的价值准则和实践，从而提升项目的可预测性，促使项目最终获得成功：

1. 敏捷不是用于 PMI 所指的那类项目的
2. 敏捷中的计划工作，是一系列连续的步骤，没有明确的界限划分
3. 混合使用敏捷方法和瀑布方法

在继续讲解前，我先介绍一下本文内容所基于的情境。我定义了两种企业类型：软件公司（独立软件供应商）和“其他公司”。由于敏捷方法能较容易地适用于“软件公司”，本文的重点放在如何在“其他公司”中使用敏捷方法。

软件公司的主要产品是软件，或者其产品的主要交付渠道是软件。按照这个定义，微软和 Adobe 公司是软件公司，亚马逊和易趣也是软件公司。我们之所以认为亚马逊和易趣是软件公司，是因为软件是他们交付产品或服务的主要渠道。与这种软件公司相对的是麦当劳和宜家。可以肯定，麦当劳和宜家也使用软件，但软件并不是它们的主要产品，也不是它们产品或服务的主要交付渠道。当然，它们确有自己的网站，但麦当劳并不通过互联网卖汉堡包。同样，虽然你可以通过网站订购宜家的产品，但是商店才是他们的主要售货渠道。

有一种处于灰色地带的第三类公司我也需要说明一下。这类公司在哪里都有一席之地。美国的银行和保险公司大都是此类灰色地带的公司。银行和保险公司既可以算是软件公司，也可以算是“其他公司”，这取决于他们的组织构成。如果企业按照产品或服务的业务线以水平形式构成，并且（或者）公司组织结构是由产品驱动的，软件是其产品或服务的主要交付渠道，那它就是软件公司。相反，如果组织结构基于工作职能划分，以垂直形式构成，例如分为市场营销、IT、和产品部门，那它就不是软件公司。这听起来很复杂，但在实践中，用这个定义，简单地确认公司中几个特定角色和他们的权力范围，就能较容易地判断出这家公司是不是软件公司。例如，如果公司有负责特定产品或服务的产品负责人，确认他的权力范围，看他能否为产品做所有的决策：市场营销决策、IT 决策、网站用户体验决策等。如果产品负责人拥有对产品的所有控制权，并且能够做出从概念到客户的所有决策，那它就是软件公司，在这种企业环境中，推行敏捷方法会很容易。要不然，它就是非软件公司，想在这类非软件公司成功实施敏捷就需要做很多工作了。本文的重点就在于如何在这类“非软件公司”中实施敏捷。

敏捷不是用于 PMI 所指的那类项目的

根据美国项目管理协会（PMI）的定义：

项目是为了创造独特的产品、服务或成果所做的临时性工作。

2001 年 2 月在美国 Snowbird Utah 举行的软件开发者大会上，人们第一次提出“敏捷”一词。早期，敏捷只是指一些轻量级过程的集合，是针对那时更广泛使用的“重量级的”（笨重的）方法的回应（Hunt 2010）。与会者制定并发布了敏捷宣言（Beck et al.，2001），这成为为敏捷运动开始的里程碑。参加这次会议的所有人都是软件开发人员。他们的关注点在于创建软件产品，而不是项目管理过程。通过我的个人访谈（van Bennekum，Hunt，Cunningham，Schwaber， & Cockburn, 2010，2011），我发现他们关注的是：重量级的过程无法适应网络公司快速变化的特性，这种情况该如何应对。为软件公司做开发工作时，人们永远不会有软件即将开发完成的想法。软件项目经常会被改进、增强或以其他形式变更，而不像建筑项目或设计洗碗机这类项目。建筑物一旦建成，或者洗碗机一旦被设计出来并交付生产，项目工作就完成了。有可能你再去做内部改进（Interior Improvement，TT）项目或再设计新型的洗碗机，但是原来的项目仍然是完成了，要做的新工作是新的独立的项目。

这与现行的产品管理的本质形成了鲜明的对比：

产品管理是控制产品从概念到推向市场或向客户交付成果和服务的规程和业务流程，用以产生最大可能的商业价值。（Ebert，2009）

产品管理关心的是产品的整个生命周期：从概念、发展，直到废弃。项目是关于创造事物的，当事物创造完成，项目也就结束了。项目不关心产品在整个产品生命周期的发展和改进。管理产品是敏捷能最有效地发挥作用的地方。花点儿时间思考一下敏捷的术语：产品负责人、产品需求列表、产品愿景、产品路线图，所有这些词语都关注于产品。敏捷实践能适用于需求变化的情况，也同样完全能够适用于产品管理。当你得知你将有第二个、第三个甚至第二十个发布时，它也只是简单地增加产品需求列表的范围，你知道，通过这样做，假以时日就能实现这些特性。而项目管理却不同，项目需要严密地管理范围、进度和预算，因为它们是结束项目的决定因素。

使用敏捷管理项目

人们无法普遍理解一些细微的区别。如果你理解了那些简单的区别，就可以成功地使用敏捷来管理项目。你需要做以下三件事情：

1. 知道项目管理与产品管理的区别
2. 规划好碰到项目 / 产品管理差异的临界点时应该做些什么
3. 每一步都与管理层沟通

项目管理中需要管理三角约束：范围、进度、预算（有时人们把质量和 / 或资源也加到约束中）。产品管理也关注这些约束，只是对产品而言，它们是一些更加宽松的概念。

图 1

如果你用于开发产品的钱花完了，只要这个产品还在为客户创造价值，那么公司很可能在下一年制定一份新预算，让产品负责人去实现上一年没能实现的功能。而项目却不会如此，钱用完了，项目也就结束了。类似地，时间进度对产品也会比对项目更宽松一些。项目经常要关注时间表。项目经理要按时满足里程碑要求，并按时结束项目。产品也关注时间表，也关注满足里程碑要求，但不关注结束的时间，因为产品开发更关注下个版本中的优化工作。

你该做些什么？

使用敏捷的方式管理项目时，了解了项目管理和产品管理处理三角约束的不同，计划好下一步要做什么是非常重要的。

这里是一些来自于我个人经验的建议和技巧。首先，你需要确定对于你的项目什么是真正最重要的。是范围最重要？还是进度、预算？这听起来很容易判断，但在现实中，很难让项目发起人保证只有一件事情最重要。（ Rob Thomsett 的滑块是一种很有用的工具，通过它我们可以识别出最关键的驱动因素）不要让他们告诉你有两个。我做过美国联邦政府委托的一个健康保险公司的项目。当说出了项目日期，人们就开始站在桌子上叫喊，让我们不能误了这个日期，可实际上只有项目内容全部完成后，项目才能算完成。如果日期到了，而范围没完成，项目就会被认为失败了，而只有内容完全实现了，项目才能算完成。你知道了什么最重要，才可能知道你需要管理些什么。例如，如果你在做一个纯研发项目，那么范围、进度、预算确实不会是驱动因素。如果你做的是即将到来的假期的项目，那么进度对你就是最重要的。一旦你知道了这个问题，你就会更多地关注最重要的因素。你应该基于最重要的因素来调整你的管理方式。

在敏捷项目中，你仍然可以管理范围、进度和预算。然而，因为在项目管理和产品管理中，处理这些因素的方式会有根本的不同，所以我们就要仔细规划当发生冲突时我们应该做些什么。做好准备，当冲突发生或将要发生时，管理起来会更容易。

图 2

在敏捷项目中，范围管理是最常让人产生误解的问题之一。敏捷实践者会告诉你，在敏捷中，范围可以随时改变。的确如此，敏捷宣言的四条价值准则之一就是“响应变化胜过遵循计划（Beck，et al.，2001）”。对客户和市场要求的需求变化能及时响应，是组织接受敏捷的首要原因（Version One，2010）。用敏捷方式管理项目时，你会定义项目 backlog 和产品 backlog。在项目开始前，你会就项目与产品的功能列表，与项目发起人进行讨论，如果可能的话，在整个项目生命周期中再与发起人进行多次讨论。项目 backlog 是项目需要做的具体的工作集合。当这些工作做完了，项目也就完成了。产品 backlog 是另外的一些特性，它们可能将来成为产品的一部分，但不是当前项目的一部分。在管理时，要非常清楚哪些内容在项目 backlog 中、哪些内容在产品 backlog 中，并且需要与发起人反复沟通。如果识别出新的产品特性，就愉快地接受它们，并毫不犹豫地把它们加入到产品 backlog 中——而不是项目 backlog 中。如果项目领导要求把它们加入到项目中，那就通过变更流程，把它们加入到项目 backlog。变更流程可能像批复邮件一样简单，但是你有必要记录下来：新特性加入到了项目中、它对进度和预算将产生怎样的影响。尽管它可能是一个更简洁的流程，实际上这种做法与传统的管理范围的瀑布方式并无不同。

关于范围管理的最后一句话是：对产品 backlog 的优先级要持续地进行再评估。产品负责人可能想重新调整产品 backlog，在项目或产品 backlog 中加入或去除一些特性。这与管理上述的新工作没有差别。弄清楚这些变化的影响，并通过尽可能简单、轻量级的流程把它们文档化，这是我们作为项目经理的职责。注意，产品负责人不要试图增加或去除当前正在开发中的工作项，那是不可行的，因为这些工作已经被团队选走了。如果对正在进行中的工作要做的变更十分重要而且必须要做，那么就要终止（在 Scrum 中）当前的这次迭代，然后再去规划新的迭代。我们可以通过减少“打回”来鼓励迭代范围的稳定性。

对进度和预算我们也可以采用类似的处理方式。你需要清楚地界定什么是项目预算、什么是运营中的产品预算；什么是项目的进度、什么是运营中的产品生命周期的进度。然后你需要就此与项目发起人频繁且清楚地交流，这样不久后，项目发起人就能铭记这两者的区别，并且成为项目 / 产品 backlog、进度、预算的捍卫者。

沟通

你需要做的第三件事，是频繁地与产品负责人沟通项目与产品间的分界线。与产品负责人紧密合作，确保他们清楚地理解这个分界线。你要非常注意自己的语言，讲清楚“项目”和“产品”，清楚地描述产品 backlog 和项目 backlog。这是你作为项目经理能最大地发挥价值的地方：你帮助公司在产品的背景下，保持对项目交付物的关注。

敏捷 / 瀑布连续体

_“敏捷和瀑布 ——哪种方式正确？”_ 我每天都会看到很多诸如此类标题的博客文章。这样的陈词滥调仍然有人谈论。“敏捷 Vs. 瀑布”制造了非此即彼的命题。把敏捷和瀑布视为战争中的敌人，只能有一个胜者。大量的文章纠缠于敏捷与瀑布辩论的两个核心问题：迭代 VS. 线性计划，命令式管理 VS. 交互式管理。看（关于两个团队的一个故事，2008）下面的例子：

神话 1：敏捷关注人 / 传统的项目管理是命令和控制式的。

从事越来越复杂的咨询和系统设计项目工作 6 年后，我发现自己管理别人做技术工作的时间多于我自己做设计网络工作的时间。2000 年，Cisco 公司的一位销售代表告诉我，我在做的事情实际上应该算是项目管理。我在 2001 年通过了 PMP 考试，现在成了“正式的”项目经理。

在接下来的几年里，我使用顺序式的方法，管理了大大小小很多个项目。正如古语所说，“当你只有锤子时，你就会看什么都像是钉子”。幸运的是，我这些项目都很适合顺序式的模型。我经常负责在华盛顿西雅图的 Fred Hutchinson 肿瘤研究中心新建筑项目中的 IT 工作。这些建筑物不仅要安装重要的网络基础设施和服务器，也要安装高度敏捷的技术医疗设备，在设备安装时往往并不需要我的帮助。这些项目工作是由建筑物的施工进度驱动的，是一个非常有序的过程。

在 2005 年，建筑项目放缓了，我开始做更多的软件项目。与建筑项目不同，软件基本上是无形的。传统的项目管理有一个未阐明的假设，它假设你一直可以看到一些东西，如地面上的大坑挖好了、地基打好了、钢筋也铺好了。软件项目却不是这样。如果按顺序的方法管理，软件项目直到项目结束才能看到东西。当项目结束时，你指望所有的事情都做好了软件就能运行。但是你用这种方式管理过软件项目的话，你就知道这是行不通的。

经历过一次特别沮丧的项目失败后，我对软件项目的发展趋势作了广泛的研究，我觉得 Scrum Master 课程对我会有比较大的帮助。碰巧 Ken Schwaber（Schwaber，Scrum.org，2010）当时在西雅图授课。在 Scrum Master 课程中，我学到了与结构化的软件项目完全不同的管理方式，这种方式使人们能接受变更，并能随时清楚地显示项目进展，即使像软件这种无形的产品也不例外。并且我发现，它潜在的哲学更有趣。

图 3

我一直采用服务型领导的方式管理项目。我是技术人员，但我也知道，致力于具体的数据库、网络、程序语言的研发人员，对技术领域的了解远胜过我，他们知道怎样才能把工作做好。作为项目经理，我的工作是帮他们把工作需要的知识组织起来，使之可管理并能汇报给老板和管理层，消除障碍，识别可能发生的风险，让他们能消除或减轻风险。我总是竭尽所能来帮助项目中的技术人员，让他们可以自由地去做自己最擅长的事情，而不用被虽有必要但却会打扰工作的项目预算、报告项目状态等其他事情干扰。Scrum 也分享了这个观点。像“鸡”和“猪”（Schwaber & Sutherland，2010），由被激励的个体来建设团队，并相信他们可以做好工作、可以自组织、以平衡的速率工作，这些都表明了对人的持续的关注。

神话2：项目不是敏捷模式就是瀑布模式，没有中间地带。

既然我们已经解开了管理风格和交付方式的谜团，接下来我们再讲一下关于二元决策方法的神话。Robert K. Wysocki 定义了项目交付物的五种离散的模型（Wysocki，2009）。Chri Ward 和Leonardo Legorreta 对Wysocki 的模型进行了改进（Legorreta，2009）。

Wysocki 和 Legorreta 定义的项目管理的五种类型是：

1. 瀑布式
2. 迭代式
3. 增量式
4. 自适应式
5. 探索式

根据我的经验，自适应式和探索式的方法大致相同。大多自适应的方法都允许范围变更（随时可以向 backlog 增加故事卡片），区别仅仅是理论在现实生活中的一些不同。所以在此次讨论里，我把这两个模型合为一个，称为敏捷。

顺序式——顺序式模型是用于中小型项目交付物的传统方法。项目工作可以按此顺序进行：明确项目目标、确定项目范围、做总体的项目计划、开发、测试、部署。这个模型适用于：小型或中型的、工作成果可以一次性有效地交付、需求非常清楚、不产生变更（如来自政府或行业法规要求的需求）的项目。

增量式——增量式模型是一种特殊的顺序式模型，只是它能够按阶段或者以迭加的方式交付成果。就像顺序式模型，增量式模型先确定了项目范围并提前做好计划，因此它最适合需求明确而且不易发生变更的项目。在每个增量中，团队可以选择 **怎样工作来满足交付要求，但不会讨论“做什么”和“为什么做”**。

迭代式——迭代式模型与“提前做好计划”的顺序式模型、增量式模型相反。大多迭代模型实际上是迭代和增量。在迭代式模型中，随着项目的进展，项目计划也按迭代逐步细化。项目初期会为整个项目做高层次的计划，但是计划的粒度比较粗且常会变更。人们只对即将要做的工作做详细的计划。通常只对1 周到1 月内的短期工作做详细计划，其它的工作以后才会做详细计划。迭代式模型采用了增量式模型中延期规划的方法，并且从精益概念中借用了尽快交付的概念：尽可能晚做决定、根据流程工作（Womak & Jones，1996）。在增量式敏捷的工作中，团队从项目发起人和/ 或客户那里获取工作内容。在每次迭代中，团队既可以选择**如何工作来满足交付需求，也会询问发起人或者客户要做什么事情 **。我们可以根据发起人和 / 或客户的输入来调整工作的优先级，完成更重要的功能特性，满足客户的交付要求。不过所有要求的特性（由于监管或遵从）最终都将被交付。

敏捷式——敏捷式模型允许在每次迭代开始时添加或移除工作范围。在敏捷项目中，需要客户经常反馈，以确保功能特性是按照对客户具有最高价值、对客户最有益的顺序交付的。此外，来自产品负责人或客户的任何新的想法都可以加入到 backlog 中。经常展示可运行的软件，其作用就如同 Heisenberg 的“测不准原理”——测量的结果会影响测量（Cassidy，2002），所以，看到的可运行的软件也会影响客户的需求，让客户产生新的更好的想法（Barry Boehm 有一个首字母缩略词：IKIWISI- 虽然我不知道我要什么，但是“当我看到了我就知道了”）。有的项目问题很复杂，甚至早期对问题都还没完全理解，这时去理解解决方案就更难了，因此对这类项目需要采用敏捷灵活的流程。

如果你理解了瀑布方法和敏捷方法是连续体，它们之间并没有明显的界限，那么你就能更成功地交付敏捷项目；而且，你能更成功地向你的同事介绍你所采用的项目管理方法的价值和原因，不管他们采用的是敏捷式方法还是瀑布式方法。

混合使用敏捷式与瀑布式方法

在本节中，我们要看一下，利用你对项目管理和产品管理的理解，结合你精心选取的管理方法，该如何在瀑布的背景下管理敏捷项目。

有些迭代或敏捷项目必须与瀑布式项目在企业中共存，这种现象并不稀奇。可能是你部门的项目正向敏捷转型，而公司里的其他项目却没有。似乎这两种项目不能很好地在企业中共存，实际上创造一种可行的并存模式并不太困难。为了与瀑布式项目团队的成员和其他合作者更好地沟通，你需要弄清楚你实际上在使用哪种项目管理模型（迭代式或敏捷式），这有助于你制定清晰的沟通计划。

图 4 信封方法

当与没有实行迭代或敏捷方法的部门沟通时，讲清楚你的流程、程序和你对瀑布团队的期望、他们对你的期望，是很重要的。

我在跟他们沟通时会使用一种我称为“信封法”的方法（图 4）。信封法是在同一项目中整合瀑布和敏捷模式的一种框架。这个方法由一系列嵌套的隔层或信封组成，用信封来隔离开不同层间的内容。

项目经理可以使用这种方法来保护敏捷团队，尤其是在迭代期间。在迭代结束前，任何事情都不应该干扰团队创建可以运行的软件。项目负责人可能要更改 backlog，平台服务组可能要修改环境。这时项目经理都应该不遗余力地来保护团队, 使他们能不受干扰地做他们最擅长的事。

第一个信封

最里面的信封是由敏捷团队来执行的工作：软件开发、单元测试、组件测试、集成测试和缺陷修正。敏捷团队负责人（在 Scrum 中是 Scrum Master 或迭代经理）是第一位的问题解决者。敏捷团队负责人要负责团队内部的沟通、指导开发团队、工作阻塞时帮忙区分团队工作的优先级。通常，敏捷团队负责人要负责团队的健康和快乐。敏捷团队负责人不能解决的问题会升级到项目经理那里。项目经理也像团队的保护者一样，会保护团队正常工作、免受复杂的外部组织的干扰。为了达到这种微妙的平衡，敏捷团队负责人和项目经理的工作关系要非常融洽才行。如果项目相对较小，那么敏捷团队负责人和项目经理可能就是同一个人。不过我尽量避免这样做，因为我认为敏捷团队负责人是一个非常关键的角色，他必须独立。这个角色可以由团队中负责其他事情的人员兼任，但最好不是项目经理。

在多团队项目中，敏捷团队负责人和项目经理会组织一些会议，一起处理团队的工作：

1. 联合的迭代计划
2. 迭代协调
3. 联合迭代演示
4. 联合回顾

联合的迭代计划——迭代计划应尽可能由统一的团队在同一天、同一个房间中做出。在撰写本文时，我正在协助项目团队准备迭代计划会议，它由四个敏捷团队、超过 100 人组成，其中包括项目发起人和外部（瀑布）成员。每隔一次迭代（两周一个迭代），整个团队（很多人距离很远）会参加联合的迭代计划会议。会议需要 8 小时。前两个小时是集体讨论。每个项目团队都会分享关于他们 Sprint 的主题，以及关于这个主题的目标。他们也讨论所有识别出的跨团队依赖关系。其他团队可以对这个团队自由提问，以找出所有潜在的包括资源或人员的跨团队依赖关系。如果所有的团队都分享过了，并且已经识别了所有的跨团队依赖关系，这群人就在这个房间里分散成他们的小团队，每个小团队都有投影仪。而每个单周，人们不来现场，每个团队就会召开电话会议。团队开始分解他们在当前迭代中所选的工作。这是一个嘈杂却高度协作的过程，一些人为团队分享专业技能，非常活跃。此外，当他们遇到跨团队的工作任务时，他们会邀请涉及到的团队来一起计划如何开展工作。这天结束后团队一起回来，并对迭代成果互相作出承诺。最后，在当天举行简短的回顾，以找出下次可以改进的地方。

迭代协同——在迭代期间，敏捷团队负责人和项目经理可能会遇到许多需要跨团队协作的问题。为促进跨团队协作顺利进行，我鼓励团队在迭代计划会议上讨论并确定下来他们将会与哪些团队有协作需求：可能是由于共享了人员或资源（如服务器、共享的网络服务、或其他的技术资源）而需要协作。鼓励敏捷团队负责人去参加其他团队的关键迭代会议（如每日站立会议、同行评审等）。此外，项目经理和敏捷团队负责人常常会一起讨论已识别的跨项目依赖关系，以及敏捷团队负责人通过参加其他团队的关键迭代会议所了解到的其他新情况。项目经理参加这个会议是为了了解跨团队的依赖关系，并确定项目团队是否需要他们帮忙解决问题。

联合迭代演示——在每次迭代结束时，团队会向项目发起人演示可以工作的软件。演示是由几个团队联合起来做的。应该按照客户在生产系统中所需遵循的流程来演示，这样才有意义。即使流程需要在几个团队间流转，也要按照系统的正常逻辑顺序来确定迭代演示的顺序。让所有团队参加系统全程完整的演示非常重要，因为软件是所有团队共同完成的，而且也是对大家工作成果的尊重。演示是庆祝迭代成功和认可你同事们工作的好时机。在迭代演示时，项目经理的主要职责是帮忙让演示顺利进行。这是项目经理当服务型领导的时候：如果投影仪坏了，或者电话会议时电话出问题了，项目经理要负责解决这些问题，以便让团队能专注于向发起人演示他们的成果。

联合回顾——迭代结束后，每个团队都要回顾他们的工作过程以便于以后工作的改进。这时项目经理和敏捷团队负责人都可以当回顾会议的主持人。我发现让敏捷团队负责人当主持人是很有帮助的，因为在下次迭代中主要由他们负责帮助团队进行改进。除了单个团队的回顾外，整个团队还应该参加联合的回顾。虽然没必要每次迭代都召开这样的回顾会议，但是我建议至少每隔一个迭代要召开一次。联合的回顾关注团队内的协作情况，以及为了改善工作环境、提高工作效率、促进沟通和协作，团队能做哪些改进工作。

第二个信封和第三个信封

预测性的元素位于信封框架的第二层和第三层。第二层信封包含的是是项目中要计划和管理的瀑布模式中的元素。硬件部署就是一个很好的例子。第三个信封包含的是项目与企业中的其他项目组合要交互的工作内容。在这一层，项目经理需要与外部项目协调、处理企业发布计划和企业报告。

第二个信封 预测性元素

预测性元素的这个信封包含了没有在敏捷模式中管理的项目工作。一个很好的例子是为项目获取新硬件。期望新硬件在迭代一开始就采购好、并且在迭代期间就安装好，这是不合理的，尤其是当迭代非常短时，例如只有 1-2 周的迭代时间。按月来衡量硬件的交付周期并不罕见。采购和实施硬件的工作不先做好充分的计划，对于项目经理来说是不够专业的，预测性元素所在的信封提供了一种框架来管理这类工作。团队在做高层次的初步计划时，就应该列出迭代对预测性元素的预期要求。此外，如果是按顺序式模型管理项目的，那么企业测试是在这个信封里的。一些组织虽然能够按迭代管理企业测试，但是如果需要配合企业发布委员会来管理全部的发布时间表，那么企业测试也应该放在第二个信封里。但是，如果团队能够按迭代模式交付成果，并且按迭代模式执行单元测试 / 组件测试和集成测试、向最终用户演示可工作的软件，企业测试执行起来很可能会更快。我看到过给定六周时间来做的企业级用户可接受性测试，按迭代模式只用了 20 分钟就完成了。

第三个信封 企业整合

第三个信封包含了敏捷项目跟其它的企业项目组合、项目发起人、督导委员会、高管交互所做的工作。在信封框架的这一层，项目经理负责项目管理、解决项目和项目组合层级的问题。目的是让敏捷团队可以完全不必关注这些事情。例如，项目经理负责与职能经理一起识别并解决项目组合与项目的问题。在处理跨项目的依赖关系时，可能需要由项目经理和敏捷团队负责人一起识别依赖关系并确定它们对项目的影响，重要的是避免让正在工作的敏捷团队受到影响。如果确实需要敏捷团队参与，建议最好等到迭代计划完成了再打断他们，以便让团队能专注于执行迭代工作。

这一层也包含了项目经理向企业管理层汇报项目状态的工作内容。项目经理需要像翻译一样，把敏捷指标转化成可以接受的企业报告的结构。敏捷对完整、勇敢和透明的关注，使项目经理很容易就能获取所要求的任何报告结构的信息，包括挣值（Suliaman，2007）（Rusk，2009）。可能出现这种情况：随着组织中成功的敏捷项目越来越多，企业开始修改报告的结构，以包括进一些敏捷的元素。不过无论如何，项目经理都要清楚地向企业汇报项目的健康状况。这些报告可能也会用来向管理与督导委员会作汇报。在信封框架的这一层级上，项目经理和项目发起人一起来管理项目和产品的关系，并确保项目范围、进度和预算是受控的。

最后，第三个信封还包含部署项目交付物到企业生产系统的内容。因为目标是要限制对敏捷团队工作的影响，这可能是管理敏捷项目最棘手的部分。项目经理和敏捷团队负责人应该一起制定项目发布计划。敏捷团队的最终目标是实现无缝部署，这样就不会对工作中的团队产生影响。但是，很可能项目团队需要从迭代中分出一部分时间用于规划、部署和签出发布包。如果可能，应该从迭代中分配一小部分储备时间（减少他们的预留时间），从团队专门抽出一个人来负责处理部署问题，以使部署中出现任何问题都能被迅速解决。

总结

在瀑布式和敏捷式项目混合的环境中使用敏捷方法是复杂的。项目经理必须高度注意产品需求和项目需求的区别，按项目发起人的委托来管理项目的范围、进度和预算。项目经理可以使用信封方法来维持三者之间的关系：敏捷团队、项目中的非敏捷元素、企业中其它因素。

我经常被问到在敏捷环境中，项目经理的角色是怎样的。他们害怕在敏捷项目中不再需要项目经理这个角色了。在业务背景简单（如小型或中等规模的业务）的小型敏捷项目中，项目经理是不需要的。想要指挥项目团队工作的项目经理在敏捷项目中也没有合适的角色。怀着为项目服务的心，并且愿意迎接更大型项目的挑战的项目经理，在敏捷项目中将有不止一个角色。对项目的成功他们是必不可少的。

关于作者

Joseph Flahiff是一位广受欢迎的演说家和项目交付顾问。他通过综合敏捷、精益和新兴的项目管理方法，帮助企业组织改善他们的项目交付物。作为一位在敏捷和传统项目管理方面具有 15 年以上经验的专家，Joseph 在世界各地讲授敏捷模式和瀑布模式的整合方法。关于在企业中敏捷项目管理最新趋势的视频、文章和免费资源可以在他的 Whitewater Projects 博客中找到。

参考文献

• A tale of two teams. (2008, April 25). Retrieved January 29, 2011, from Youtube.com
• Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001, 2 11=13). The Agile Manifesto. Retrieved 1 21, 2011, from agilemanifesto.org
• Cassidy, D. (2002, 5). Quantum Mechanics: 1925-1927 THE UNCERTANTY PRINCIPLE. Retrieved January 20, 2011, from American Institute of Physics
• Ebert, D. C. (2009). Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 15-19.
• Hunt, A. (2010, September). The Agile Manifesto a decade later. (J. Flahiff, Interviewer)
• Legorreta, C. W. (2009, April 2). Beyond waterfall and agile methods:Towards a new contingency model for IT Project Management. Retrieved January 30, 2011, from Social Science Research Network
• Rusk, J. (2009). Earned Value for Agile Development. Retrieved January 30, 2011, from agilekiwi.com
• Schwaber, K. (2010). Scrum.org. Retrieved January 30, 2011, from Scurm.org
• Schwaber, K., & Sutherland, J. (2010). Scrum Guide. In K. Schwaber, & J. Sutherland, Scrum Guide (p. 5). scrum.org.
• Suliaman, T. (2007, October 5). AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. Retrieved January 30, 2011, from InfoQ
• van Bennekum, A., Hunt, A., Cunningham, W., Schwaber, K., & Cockburn, A. (2010, 2011). Whitewater Projects Podcasts. (J. Flahiff, Interviewer)
• Version One. (2009). 2009 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com
• Version One. (2010). 2010 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com
• Wikipedia. (2011, 1 5). Product management. Retrieved 1 21, 2011, from wikipedia.com
• Womak, J. P., & Jones, D. T. (1996). Lean Thinking. Simon & Schuster.
• Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme, 5th Edition. John Wiley & Sons.

查看英文原文： Integrating Agile into a Waterfall World

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。