本文内容包括：

定义 了解风险 细化 VS. 细化 其他风险缓和策略 重叠迭代的两个简单规则 一个建议 结束语 注释 参考资料

本文来自于 Rational Edge：以迭代方式工作的软件开发团队常常会考虑让一些团队成员在他们当前进度之前达到用于之后迭代的目标集。虽然有风险，但是如果能对重叠迭代技术有适当的理解和管理，那么该技术就可以带来益处。

 当计划并执行 RUP 项目时，大多数（如果不是全部的话）开发团队会遇到一个有趣的问题：“我们应该让迭代‘重叠’吗？”在我进行服务性约谈过程中，常常从客户那里听到这个问题，并且该问题常出现在外部的 RUP 论坛（您可以在此论坛中通过将含有“subscribe rup”字样的电子邮件发送到 majordomo@lists.us.ibm.com 处来订阅）中。

这是其中一个能够导致较深远的思索的争议话题。IBM Rational 对该问题的正式立场是不能重叠您的迭代。但许多成功的项目都宣称按此方式运作的。它致使许多人怀疑，“非重叠迭代”策略是否仅是对于实践概念的一种教条，或者在该策略背后是否真的存在某种原因。

本文将描述“重叠迭代”的含义以及为什么会首先出现关于该技术的使用的问题。我将以不同的观点提出一些建议并用我个人的建议作为总结。

定义

在开始之前，让我们对重叠迭代的含义取得一致意见。我已经听说过此概念的其他名称，如“极限迭代”、“分级迭代”和“栈式迭代”。

RUP 中的标准迭代如下图 1 中所展示的。三个迭代，I1、I2 和 I3，从左到右顺序发生。在每个迭代中从上到下顺序发生的 R、D、C 和 T 表示在每次迭代中执行的一些标准规程（需求、设计、代码和测试）。（虽然 RUP 中有九个规程，所有这些规程都有可能在一个典型的迭代中执行，但是为了简便我只涉及 RDCT。）

图 1：标准迭代。I1、I2 和 I3 代表三次迭代，从左到右顺序发生。在每个迭代中从上到下顺序发生的 R、D、C 和 T 表示在每次迭代中执行的一些标准规程（需求、设计、代码和测试）。

一旦项目经理（project manager，PM）开始为项目的迭代布置计划，他或她就可能会问：“当需求团队将 I1 的需求交给设计团队后他们要做些什么？我不能让他们闲坐着直到 I2 的开始，等待 I1 的结束。”该问题也波及到所有其他的团队，因为各团队要等待后继者为他们完成迭代的工作，或者等待前驱者给予他们工件进行工作。

所以有些人开始问：“为什么需求团队不能先于其他团队进行工作？”当该思想遍及到所有其他的角色时，我们以如图 2 中的内容来告终。

图 2：重叠迭代

重叠迭代的基本思想是需求团队可以处理未来迭代的需求，比方说迭代 3，而设计团队还在处理来自前一个迭代的需求，比方说迭代 1 或 2。

如果您在我们其中一个聊天论坛中询问关于重叠迭代的事，大多数 IBM Rational 顾问会告诉您这不是 RUP 所推荐的。一些人甚至会说这是绝对不允许的。那么不妨说 Rational 的官方立场是不要这么做。但此概念具有意义。要处理的风险和一些要整理的定义是存在的，但如果能小心地管理，重叠迭代可以成为一个组织项目的有用方法。

一个有成就的项目经理，也是朋友，John Stonehocker 经常帮助企业采用 RUP。他向我解释说，如果您将迭代定义为一个没有目标的“时间框”，那么重叠迭代的整个概念就没有意义了。

作为一个时间框，“未来迭代”的概念的确没有意义。假设您正在处理那些直到随后的时间框才进行编码的需求，从技术上说，该需求工作仍旧是此迭代的一部分 —— 而不是下一个迭代 —— 即使在当前时间框中没有完成编码。 要在未来的迭代中进行工作，您简直就需要一部时间机器！

图 3 显示出一些利用了一种时间框迭代方法的迭代会是什么样子。

图 3：一个使用时间框迭代的例子，而不是使用能够允许工作提前的重叠迭代。在一边的任务是需求（Requirements，R）、设计（Design，D）、编码（Code，C）和测试（Test，T）。迭代 I1、I2 和 I3 说明那些任务可能要处理的用例（use case，UC）是什么。

在时间框迭代中，迭代被认做一个时间段，在这期间，所有的工作都计划得很谨慎。那是时间框迭代和重叠迭代的一个区别。在重叠迭代方法中，如果需求团队完成了 I1 中的 UC1 及 2，那么他们就可以提前工作直至迭代结束。在时间框迭代中，我们为需求团队将 UC1、2、3、4 及 5 规划到 I1 中。通过预先计划，我们可以真正地开始了解需求团队的能力了。他们用光时间了吗？他们还有时间剩下吗？用任一种方式我们都能够为下一次迭代提出评估并为团队规划更大量的用例以详述需求。

不过以重叠迭代的立场来考虑图 3，在其中迭代是作为“功能集合”，如一组具体的用例、特性或在当前迭代末端团队所用来编制功能的任何东西。所以上面的 I1 等同于功能集合 UC1 和 2（只有这些用例是在 I1 的末端进行编码和测试的），I2 是功能集合 UC3 和 4，I3 是功能集合 UC5、6 和 7。在 I1 中，注意到，可以考虑让需求团队处理 I2 和 I3 的功能集合。这就是团队所说的“重叠迭代”的意思。他们正在处理迭代 2 和 3 的预定功能。

如果您到现在一直跟着我，那么您可能会注意到，总的来说，重叠方法和时间框方法都会导致在已知时间段内进行的几乎相同的实际工作！所以，重叠迭代和时间框迭代之间的区别与倾向于整体策略上的工作相比更倾向于语义和基本原理。在此实例中，不论是考虑重叠迭代还是时间框迭代，需求团队在 I1 中仍旧会处理 UC1、2、3、4 和 5，尽管只实现了 UC1 和 2。

确定我们仍在同一页，注意在标准的 RUP 迭代方法中，只允许每个 I1、I2 和 I3 的需求团队处理应该在其迭代过程中完成的 UC。因此对于 I1，需求团队只能处理 UC1 和 2，并且要等到 I2 开始才能继续。

了解风险

离开“标准迭代”的决定可以被很好地理解为对一些问题或危机的反应。在提出我的个人建议之前，我们需要了解驱使项目团队考虑重叠迭代（或者允许“提前工作”的时间框迭代）的特别类型的风险。

激发的风险

在我的经历中，遇到过一个主要的驱使项目经理考虑重叠迭代的风险：资源利用风险。换句话说，项目经理看到标准的迭代计划，且每次问同样的问题：“需求人员在完成此次迭代的需求后，到下次迭代之前能做些什么呢？”

事实上，会有各种风险促使我们考虑重叠迭代。不论风险是什么，重要的是它们都列在项目风险列表中。

结果的风险

如果允许重叠迭代，那么重要的是应将该技术所产生的风险加入到风险列表中并进行分析。

为节省您的一些时间，我将说明我认为的重叠迭代（OI）技术所带来的风险。如果您选择继续进行重叠迭代，那么以下这些是会使迭代开发方法所需的调整更加困难的缺陷：

1. 增加的碎片和重复工作
   如果您极端地追求重叠迭代技术，那么您会沿着瀑布模型。例如，您可能发现，需求分析员在第一次迭代（曾经发布所有要评估的值）之前完成所有用例的详述工作。那意味着您在前面做完了所有的需求，正如瀑布模型。
   其中的一个危机是：迭代团队应根据来自 1) 分析可行性的客户，和 2) 了解解决方案的架构师、测试人员和其余的设计团队的有价值的反馈来调整对需求的观察的宽度。这意味着，任何由过度积极的重叠迭代团队生成的详细的需求都不得不被扔掉或重写，且增加了开发的成本。
   另一个危机是：在细化阶段，体系架构通常是不稳定的。随着对体系架构的稳定，我们也许会设定优先级或着甚至去掉带来体系架构难点的需求。此外，对那些由 OI 生成的额外用例的详细需求可能不得不被改变，以适应我们不断增长的对解决方案的理解。如果去掉了那些细节，就很容易做出变更，碎片会更少，且开发的整体成本会更少。
2. 增加了取消项目的成本
   迭代开发的一个好处是它赋予您能够在大规模投资到位之前就开始进行项目的能力。如果您堆叠您的迭代，如使用 OI 一样，并决定在第一个迭代末尾就结束，那么取消项目的成本会更高，因为所有早期规程中进行的未来的工作都将没用了。
   此概念会出现在制造业，在其中会计算废料和存货。如果其中一个制造点运作的太快，那么就将生成需要下一个岗位来消耗的存货。如果在上游发现什么错误，或着我们停止生产产品，那么由于在生产的存货而生成的废料会更多。
3. 低士气
   重复工作和废弃常常导致士气问题。当人们摒弃艰苦的工作成果，或不得不重新工作，特别是因为糟糕的计划时，挫败程度会增加。在瀑布和重叠迭代开发项目中，能够很普遍地听到“如果你事先告诉我，我第一次就会做正确了，”或“我重做只是因为你改变了主意。”这是对被要求更改深度的工作的回答。宽度的工作常常更容易更改，所以人们不太舍不得改。如果您提前工作，那么很可能会重做或废掉深度的工作。
4. 受影响的过程改进
   当我们执行过程时，每个过程都会改进，特别是软件开发过程，即使您采用了 RUP。特别地，当设计人员和测试人员第一次得到用例并与需求团队交流从他们的规程的观点所看到的缺点时，书写用例的需求过程就需要改进了。一旦需求团队收到了这些改进建议，他们就会立刻将改进应用到下一次迭代。
   但是在 OI 项目的环境中考虑此点：不久我们将得到许多撰写的不好的用例，因为反馈不会结合到“提前工作”的用例中。他们要么重做那些用例，要么以更低的质量将它们传递下去。（设想当已经解释过从设计人员和测试人员角度看，式样是如何薄弱的设计人员和测试人员从需求团队那里得到了那样的垃圾。下次他们就很难帮忙了！）
5. 竖井心理
   允许团队提前工作的另一个风险是您可以创建 —— 或促使一个现有的 —— “竖井心理”，在此团队会着重于规程而不是着重于迭代或着重于功能。在一些我所观察的使用 OI 方法的团队中，需求人员开始接受变更请求或进行会面以澄清第一次迭代需求中的问题。然而，他们没时间处理这些问题，因为他们要出席有冲突的风险承担者的会议，或者正在经受着完成下游“未来功能”用例的最终期限的压力。当他们应该考虑“我不得不让迭代 1 取得成功”的时候，他们相信“我不得不完成这些需求。”团队需要记住的是，成功完成迭代是每个人的第一目标，不管他们所处的是什么规程。
6. 瀑布的危险
   总之，提前工作所带来的问题是它假设您对当前景象的理解是近乎完美的。因此我们会做比当前迭代所需的更多的深度的工作。 当当前的景象和与其相关的需求改变时，我们不得不废掉相当大量的工作，因此增加了开发成本并降低了士气。
   
   换句话说，对 OI 使用的许可使您灾难性的急剧下滑到瀑布模型，在其中我们大多数人作为冒险的人接受了，在瀑布开发中，团队是脱节的，并且从本质上缺少不确定性，直到最终可执行版本的交付。

细化 VS. 细化

当团队创建了他们的需求时，他们需要生成对需求的宽度视角（RUP 远景）和深度视角（Software Requirement Specification，或 SRS）。在瀑布方法中，在需求阶段的末尾，宽度和深度都百分之百的完成了。在 RUP 中，我们只在初始阶段的末尾尝试获得宽度视角的百分之百的完成，但尽管那样，我们也足够聪明，知道不能百分之百正确，并且在细化过程中还要根据事实进行调整。然而，到构建阶段，需求的宽度视角，或 RUP 远景就将稳定了。

在第一次迭代后的每一次中，我们通过深入钻研具体功能领域（用例）来创建需求的深度视角，因而为每个迭代建立一个 SRS。当我们为每次迭代创建深度视角 SRS 时，我们要根据事实调整宽度视角。这并不困难，因为宽度视角的级别足够高能够允许简单的修改。此外，一旦宽度视角稳定了（以及体系架构，但那是个不同的主题），项目就从细化阶段迁移到构建阶段。

所以，在细化阶段，需求的宽度视角（远景）是不稳定的，会随着对深度视角的理解和可执行性的生成而变化。这意味着在细化阶段利用 OI 提前工作将比在构建阶段出现更高的风险。 在构建阶段，体系架构和远景最初是稳定的（此稳定性是细化阶段的退出标准），这意味着如果一个团队选择在构建阶段利用 OI 提前工作，那么就会有更少的废物和重做。

一个例子

设想团队在细化阶段计划两次迭代（E1 和 E2），这显然会失败。现在设想我们允许运用 OI。需求书写者将为 E1 详述需求。然后他将为 E2 详述需求（对于时间框迭代的人来说，这意味着他们在为随后的功能版本处理需求）。他们甚至可能为下一次迭代详述需求。

奇怪的是，根据计划，下一次迭代是 C1，构建的第一次迭代。但是应该是吗？注意我们所选择在构建阶段进行工作的方式与细化阶段是不同的。在细化阶段，我们根据用例流稳定体系架构的能力来挑选用例流。在构建阶段，我们根据将在构建阶段的末尾要交付给客户的最终解决方案集中的价值最大化的能力来选择用例流。

所以在此处是有风险的。在 E2 的结尾，很可能不能达到细化阶段的出口标准（稳定的远景，稳定的体系架构）。如果这样，团队要做一些选择：废弃项目、进行 E3，或者解决任何剩余的体系架构问题：

• 如果您选择废弃整个项目，注意我们取消项目的成本可能会比不提前工作要高。在要废弃的项目中所做的额外工作已经完成。
• 如果我们选择要 E3，我们将不知道选择哪些用例流。为什么？因为用来选择（一般的是下一个）C1 用例流的技术应该就是选择 E3 用例流的技术，所以现在详述了错误种类的流。此外，如果设计团队也提前工作，那么由于我们改变了关于体系架构的决策，他们会发现所有的工作都作废了。
• 如果我们选择改变项目的范围，那么我们也许会找到许多废掉的工作，如果重新定范围的工作去掉了团队已经提前处理的用例流！

当两次迭代完成时细化阶段不会中止，而是当体系架构和远景都稳定时。所以很可能到 E2 的结尾，团队会说“我们仍旧很不稳定，所以下一个迭代是 E3，不是 C1。”

其他风险缓和策略

记得大多数项目会采取 OI 计划来缓和资源利用风险（例如，拥有未利用的资源的风险会导致我们让他们提前工作）。在您进行 OI 计划之前，您应该探究一下与 OI 不同的有潜力的其他资源利用缓和策略。我在下面描述六个。 在最后一部分中，我会描述一个简单可使用的 OI 方法，以防这六个缓和策略没有满足您的投资组合的管理需求。

1. 多项目。我曾经见到有图这样显示，最佳的是，将单个资源分配到两个项目中。只在一个项目中，空闲时间会增加，在多于两个的项目中，时间将花在“环境切换”上，当团队成员每次在项目间转移时，他或她在此不得不在精神上、电力上，甚至很可能身体上进行切换。
   与其让团队成员在一个项目中提前工作，倒不如让他们转移到公司投资组合中的另一个项目中去。设想您的公司不熟悉 RUP。您的试验项目团队完成初始阶段并撰写所得到的许多经验。现在团队成员转移到细化迭代 1，详述一些用例，然后做完工作。如果您让他们提前处理未来迭代的用例，他们很可能面临着重做，由于需求和过程的改变，这也将提高他们的挫败等级。
   取代让他们提前工作，您可以将他们的部分时间分配到第二个项目的初始阶段去。这些人员刚刚完成他们在第一个项目的初始阶段所进行的工作，并可以马上将那些经验应用到第二个项目中去。注意您只需要将一些分析人员的部分时间分配到第二个项目，因为他们必须随时到项目 1 的团队以确保第一个项目的迭代进行成功。
   对于面对深度的任务，我相信两个项目对于每个团队成员来说是最有效的数字。但对于面向宽度的任务来说，我相信个数还可以更高，也许三个或四个项目。我没有确实的数据来支持它，但我的经验表明这是合理的。
2. 多任务。另一个策略是让人们在项目中多于一个的任务中工作。例如，如果需求分析人员也能够帮助创建分析模型或测试模型，他或她将比处理迭代的需求工作更加忙碌。同样，这也可以在某种程度上提高团队士气。一些团队成员会想要此机会做多于一个单一的再三重复的工作，所以他们在这种模型下是更快乐的。对于那些不愿意或没有能力在多于一个的任务中工作的人来说，您可以对他们使用不同的策略，如上面的多项目。
3. 多用例流。不要忘记单个的迭代经常分配有多于一个的用例流。设想我们有三个用例分配到迭代中，且每个用例都有三个流要进行详述。在详述九个流的第一个之后，我们可以立即将它们转到设计团队，并花时间观察此单个流如何指导工作。在需求分析人员满意之后，他们可以回去并详述更多余下的八个流，将每一个都按照完成的那个处理。这意味着不存在那种巨大的勉强通过的压力。
4. 矩阵型机构。矩阵型机构也可以帮助您减少资源利用的风险。在矩阵型机构中，每个人向两个经理汇报：“资源经理”和“过程经理”。 ¹
   资源经理的工作是确保他们的资源完全应用到重要的项目上了。他们通过提高人力的能力来服务于过程所有者的需求，并通过维持与过程所有者的关系来确保他们了解项目的类型和人员所需要的过程所有者所拥有的东西来实现这一点。资源所有者不会因为预算而得到钱。他们要通过让他们的人员给过程所有者开据时间帐单来挣钱。然后他们利用那些资金通过培训和工具等来提高人力的水平。资源所有者一般是根据资源利用的方式而得到报酬。 此处的一个典型的错误是根据应用衡量资源。这没有一点意义，因为应用资源是资源所有者的工作。例如，如果一个人在其每项工作中都保持良好的工作水平，但只用了他 20％ 的时间，是谁的错？而如果 100％ 的时间都使用一个中等水平的人员又如何？此外，这要更多地责备资源所有者而不是资源本身。
   过程所有者的工作是执行过程并实现对组织的某种价值。他们需要从资源经理那里得到用来运作项目并能够清楚 过程领域的价值，以及其过程领域的实例的资源。例如，过程领域可能是“执行 IT 项目”。每个 IT 项目都是该过程领域的实例，并且每个都应当能够清楚其价值。过程领域实例（如一个项目）能够得到预算。他们必须花费预算来从资源经理那里得到资源，并要花费更多以获得更好的资源。过程所有者根据两个基本内容得到报酬：完成他们的项目及为企业带来可度量的积极的价值。
   在我们“执行 IT 项目”的实例中，过程所有者创建了过程（希望利用了 RUP）。他们需要项目经理、分析人员、设计人员及架构师等。每个任务所需的人都要向资源所有者报告 —— 例如，分析人员。一旦将资源分配到项目中，他们就有了两个经理：IT 项目的项目经理和分析人员的资源所有者。过程所有者根据资源在项目中的表现来进行评估。资源所有者也以对资源池重要的东西的观点来评价资源。
   以此方式使用矩阵型机构可以极大的缓解资源利用的风险。当项目任务很少时，资源经理会确保雇员临时为不同的项目工作。如果已知项目中的迭代没有成功，项目经理（PM）可以将此写在资源的表现评估上。PM 不关心需求，他们关心迭代是否成功，及如何度量这部分内容。
   换句话说，如果 PM 有任何取得资源的困难，这都反映到资源经理的表现评估上。
5. 接受。在此策略中，人们接受他们的团队成员将在每次迭代中有空闲时间。他们不想使用上面任何一个策略来缓和此点，而简单地接受一些停工期是开发成本的一部分。在这些公司中团队士气常常是非常高的，尽管一些人会狂热并单个地使用上面的技术之一来保持工作的愉快。（其他人像这样写文章。）如果您采用了此策略，就紧紧地追踪开发成本并与那些采用了更积极的缓解策略的人比较。
6. 减小的团队大小。很明显的是，空闲资源成本随着团队大小的增长而提高。因此，团队越小，开发成本就越低，如果很可能出现空闲资源的话。说得这样明确可能很愚蠢，在细化阶段，使您的团队大小保持小规模。对于细化阶段，八个分析人员可能太多了，但一旦远景和体系架构稳定下来，对于构建阶段这个数就非常大了。
7. 投资组合管理。您可能注意到了策略 1、2 和 4 有一些共同点。他们是拥有强大投资组合策略的所有部分。对于那些不熟悉投资组合管理的人来说，投资组合是由某个权威人士管理的一组项目。
   
   这不同于计划，计划将技术上相关的项目关联起来。换句话说，要使得计划成功，所有包含在内的项目需要一起工作。 ²
   
   在一个投资组合中，所包含的项目之间可能没有任何关系。投资组合对组织来说具有项目价值（比方说，到 2006 年末，该项目投资组合会为该部分节省 IT 开销 630 万美元）并且每个项目都为整体价值做出贡献。但每个项目都会有与其相关的级别的风险。投资组合允许投资组合经理可以了解其对组织的价值，以及哪些项目很容易失败，不能给予任一或所有的项目价值。
   
   包含在投资组合管理中的任务是管理您的资源以确保它们被应用于最大化投资组合价值。一般意义的最佳实践 —— 如“将您最好的人员加入到最重要的项目中”—— 由投资组合管理技术来形式化了。在此领域内的 IBM Rational 的工具叫作 Rational Portfolio Manager（RPM）并且当是时候扩展团队大小时能够较大地帮助将 1、2、4 甚至 6 自动化。
   
   这对矩阵型机构（策略 4）尤为正确。强大的投资组合管理工具和策略能够帮助过程所有者证明他们的项目对投资组合的价值，并将资源多给那些有技术的人，而不是多给认识的朋友。这些人员会了解，当他们被拉入到大的项目中时，他们的投资组合管理策略正在工作，不是因为他们认识谁，而是因为他们知道什么！

重叠迭代的两个简单规则

如果您不能采用上面的投资组合管理技术来缓和资源利用策略，或者您仍旧觉得利用 OI 或时间框迭代提前工作对于您是正确的选择，那么这里有一个您可以尝试的具有两个最佳实践的技术：

1. 由于太不稳定且因此更可能导致废弃和重做，所以在细化阶段不接受 OI，而只在构建阶段允许。
2. 在构建阶段，只允许团队提前一个迭代工作（或只对时间框迭代提前处理下一个迭代的一组功能集）。

规则 2 是简单规则，其不需要更多技术上的解释。但必要的逻辑会用到一些例子。我在先前的公司目睹了一个训练，帮助说明了为什么提前一个迭代工作是一个好的限制。

在此训练中，一队人员被要求在生产线上组装“产品”。 产品是折叠的纸板砖，每一个都粘了胶带以保持矩形外形。团队由五人组成，且每对成员之间是一个循环。第一个人要裁纸板。第二个人要叠纸板。第三个人粘纸板。第四个人在叠好、粘好的纸板周围绑丝带，而第五个人在最终产品上做标记。这些具体的任务是不相关的。

相关的内容是每个任务所需的不同时间量。团队被告知有七分钟的时间来制作所能做的最多的纸盒。计时器开始了，每个人都疯狂地干自己的工作，将完成的物品放入循环中他们和下一个人之间的装配线上。

我们所有的人都反常地喜欢看到一些障碍形成，一个人那里慢慢地出现一个增长的，不稳定的盒子堆，在其左边等待他去处理。实际上，积压工人左边的人似乎会加速，甚至要看看她如何能够用积压货将可怜的人埋没。而观察者更是哈哈大笑。

在最后，时间用光了，分配来一个新选手来进行质量控制。她得到一个清单，并根据清单数“质量足够”的砖的数量。没有合格的。（为了公平，最开始应发放清单，但那是不同的讨论。）

在此之后，他们计算“废物”或由于不好的质量而要扔掉的盒子数。他们还计算了“存货”或半成品（仍旧使公司花钱投入到未进入销售状态的产品）的数量。由于一个快速和慢速作业之间成山的积压物品，所以该数量是巨大的。所有事情都十分糟糕。

然后该训练重复进行，此次他们加入了一个规则：每个成员都只能在循环上他们和下一个团队成员之间放一个物品。一旦该物品被拿走了，该成员就可以放上另一个。快速工作的参与者将完成工作，把物品放入循环，将第二个完成，并等待该位置空了，他可以将其填上并制作下一个。

此改变是非常好的。每个成员马上更轻松了。速度较快的参与者也不再急于将邻居埋没。速度较慢的参与者也不再经受等待他的堆成山的物品的压力了。在最后，几乎每个产品都质量合格，并且积压品也大幅度减少。

工作在底线，每个人更轻松，一些人站着等一小段时间不做任何事，但结果是更少的废品、更少的积压品、更多成品，及所有人更高的士气！这就是为什么一些人使用该策略，并只允许在构建阶段将工作提前到下一个迭代。

一个建议

管理您的资源利用风险的最佳方法不是必须利用 OI 或时间框迭代计划使您的资源提前工作，而是获得对 IT 投资组合的控制。常识和经验将帮助您满意各种上述技术的组合。一般而言，在细化阶段，您应该使用标准的迭代，且不让团队超过当前功能集提前工作。 使用小型团队，通过减少空闲资源的影响来减少开发成本。 将团队成员分配到两个项目中，但确保第二个项目的优先级比第一个项目低。在构建阶段，允许团队成只进行从当前到下一个迭代的工作，而不超过那些。

如果您不能使用以上多项目、矩阵机构，或其他技术中的一个投资组合管理技术，那么一定让您的团队可以提前工作。但要跟踪废品和重做，并缓解其他风险。

结束语

在标准的迭代技术中，我们只将工作限定在当前的迭代功能（用例）中。您将需要前面描述的一种风险缓解策略，如多项目、多任务、多流、矩阵机构、接受，或其他明智的缓解策略。好的投资组合管理将帮助您使此技术有效。

在重叠迭代中，也称为极限迭代、分级迭代，和栈式迭代等，迭代被定义为装有一组功能集合（用例、特性，不论什么）的容器。如果团队完成了当前迭代的工作，就可以提前到未来迭代的工作中。在这种情况下，您需要适当地加入缓解策略和指示度量来最小化重叠迭代所产生的风险：增加的废物和重做、低士气、受影响的过程改进，和竖井心理。

在时间框迭代中，迭代中包含所有相关的工作，不论工作所属于的是哪个功能集合。这迫使团队试图计划将工作精确地放入一个给定的时间框内。 如常常做的那样，您可以添加或去掉范围，但在时间框方法中，这是作为对计划的背离而被跟踪的，并辅助您未来的计划。人们将在整个迭代中都十分忙碌，但不能在同一时间处理同一功能集合。因此，重叠迭代从字面上看是不可能的 —— 除非您有时间机器！

因为当使用重叠迭代或时间框迭代时完成的策略上的工作结束时很相似，所以风险也一样。所以重要的是项目经理适当地加入为重叠迭代定义的相同策略和度量：例如，增长的废物和重做、低士气等。

使用重叠迭代会成功吗？我的一个项目经理朋友，Ruth Nantais，拥有一个关于指导不同项目的高度成功的跟踪记录，且她有时候也使用此方法。 她的团队称之为“极限迭代。”另一个拥有强大的成功跟踪记录的公司称之为“分级迭代。”不论您使用什么名字，只要您限制重叠迭代的应用，它将会是有用的项目管理技术。

注释

¹ 这些也常常被分别称为“资源所有者”和“过程所有者”。

² 一个投资组合实际可以包含多个计划。基本上说，一个计划比投资组合更像是一个大项目。在项目中，目的是确保项目成功，不论对投资组合的意义是什么。这对计划也一样。只有投资组合会着重于项目或计划是如何贡献出团体价值的（与其他项目和计划比较起来）。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。