任务:制定迭代计划
此任务描述了如何通过定义范围、评估条件、活动,以及通过为迭代分配职责来组成迭代计划。
规程:项目管理
用途

制定包含以下内容的迭代规划:

  • 任务的详细工作分解结构和职责指定
  • 内部迭代里程碑和可交付件
  • 迭代的评估条件
关系
主要描述

迭代本身是一组限定时间任务,这些任务仅仅着重于生成可执行文件。除最后的移交迭代以外,其他所有迭代均是中间产品,生成该产品的目的在于迫使人们关注缓解风险以及推动项目成功交付。着重于可执行的可交付件会迫使人们进行几乎持续集成,并允许项目尽早针对技术风险,从而减小附带风险。

迭代暗含了(对现有工作产品)进行特定量的返工,并且会附带地改变人们对返工的态度。简而言之,特定量的返工对于交付优质产品是必需的:通过尽早地和经常地构造中间产品并评估产品体系结构的适用性,可提高最终产品的质量,而进行变更的成本较小,且更易于包容变更。

步骤
确定迭代范围
目的 选择一组要在迭代期间考虑的用例或场景。
选择一组在迭代期间必须处理的非功能性需求。 
指南迭代计划 

迭代的范围受以下四个因素的驱动:

  • 项目最大的几个风险
  • 系统必需的功能
  • 在项目计划中分配给迭代的时间
  • 阶段及其特定目标(请参阅概念:阶段

在迭代的初始计划中,选择足够的工作以填充已经为迭代计划的时间 - 尽管允许项目经理在制定迭代计划时有余地考虑资源约束和其他战术性注意事项。显然,为先前迭代计划的但未完成的工作(由于为了满足进度安排而缩减了先前的迭代范围)通常具有高的优先级。

工作的范围也不得不受到在迭代的持续时间内为了完成该迭代可以应用的最大人员配备水平的一个明智的方法的驱动。例如,通常不可能通过将迭代所用的人数加倍来将迭代中完成的工作加倍 - 即使您有这么多人。可以有效地使用的大致成员人数由软件总大小和体系结构决定,诸如 COCOMO II 之类的估算模型(请参阅 [BOE00])可提供这些信息。

然后通过限定时间管理迭代的执行 - 也就是,对范围和质量(以发现但未纠正的缺陷表示质量)进行积极管理,以满足截止日期。

精化阶段:

关于定义精化阶段迭代的目标,有三个主要驱动因素:

  • 风险
  • 关键程度
  • 覆盖范围

定义迭代目标的主要驱动因素是风险。您需要尽早地缓解或消除风险。这是精化阶段中的主要情况,您的大部分风险应得到缓解,但这将继续是构造中的关键元素,因为一些风险仍然很高,或者发现了新的风险。但是由于精化阶段的目标是对体系结构设置基线,我们必须开始考虑其他一些注意事项,例如确保体系结构满足了要开发的软件的所有方面(覆盖范围)。这很重要,因为体系结构将用于进一步的计划:团队的组织、要开发的代码的估算,等等。

最后,尽管关注风险很重要,您还应牢记系统的主要任务;解决所有棘手的问题很好,但解决问题时不能损害核心功能:请确保的确包含了系统的关键功能或服务(关键程度),即使未察觉到与它们相关联的风险。

从风险列表中,为危害最大的风险,识别某个用例中的某个场景,它将迫使开发团队“直面”风险。

示例

  • 如果存在集成风险,例如“数据库 D 可正常用于操作系统 Y”,请确保您包含了一个场景,该场景涉及到甚至是非常普通的数据库交互。
  • 如果存在性能风险,例如“到了计算工件轨道的时间”,请确保您有一个包含该计算的场景,至少对最明显最频繁的用例要包含。

对于关键程度,请确保包含系统提供的最基础的功能或服务。 从用例中选择某个场景,该场景代表系统提供的服务或功能的最常见最频繁的形式。软件体系结构文档用于驱动此工作,它提供一组排列了优先级的用例或用例的子流,这些用例或用例的子流由软件设计人员选择以反映在体系结构方面重要的用例或场景。

示例

  • 对于电话交换机,单纯的站到站呼叫很显然是早期迭代的必要条件。在错误处理子系统的操作员配置中获取正确的(而非费解的)故障方式要重要得多。

对于覆盖范围,在精化阶段快要结束时,请包含涉及到您知道需要进行开发的领域的场景,尽管它们既不关键也不具有风险性。

创建详细的、端到端的场景(这些场景同时针对多个问题)通常很经济。

危险通常是使得场景过于“密集”,也就是尝试包含太多不同的方面、变体和错误用例(请参阅迭代计划

另外,在精化阶段,请牢记:一些风险可能更多地具有人类或程序的本质(团队文化、培训、工具的选择、新技术等等),而执行迭代就能够缓解这些风险。

示例

  1. 在客户端工作站上创建一条要存储在服务器上的数据库中的订户记录,包括用户对话框,但未包括所有字段,并假设未检测到错误。
    组合某个关键功能,这会产生一些集成风险(数据库和通信软件)和集成问题(处理 2 种不同的平台)。还要求设计人员熟悉新的 GUI 设计工具。最终生成一个可以向用户演示以获取反馈的原型。
  2. 确保最多可创建 20,000 名订户,且访问一名订户的时间不超过 200 毫秒。
    针对一些关键性能问题(容量或数据,以及响应时间),如果不满足会显著地影响体系结构。
  3. 撤消订户地址的更改。
    一个简单特性,它迫使设计员考虑对所有“撤消”功能的设计。这随后又可能触发用户对以下问题的反思:哪些操作能以合理的成本撤消。
  4. 完成所有关于供应链管理的用例。
    精化阶段的目标还在于完成需求捕获,可能也是逐个组地进行。

构造阶段:

随着项目移至构造阶段,风险仍然是一个关键驱动因素,尤其是当发现新的未知的风险时。但是用例的完整性开始成为一个驱动因素。可以逐个地为各个功能计划迭代,尝试尽早完成一些最关键的迭代,以便它们可以在多个迭代期间进行彻底测试。 在构造阶段快结束时,全部用例的健壮性将是主要目标。

示例

  1. 实施呼叫转移的所有变体,包括错误的变体。
    这是一组相关功能。其中一个可能已在精化阶段实施,并将为剩余的开发充当原型。
  2. 完成除夜间服务以外的所有电话操作员功能。
    另一组功能。
  3. 在 2 台计算机配置上,达到每小时 5,000 次事务。
    这可以提升必需的性能,性能的提升是相对于在前一个迭代中实际达到的性能(只有 2,357 次/小时)
  4. 集成新版本的地理信息系统。
    这可能是中等的体系结构变更,由于较早发现的某个问题而必须这样做。
  5. 修订所有级别 1 和级别 2 的缺陷
    修订在先前迭代的测试中发现的缺陷,这些缺陷当时未立刻修订而延迟到现在

移交阶段:

完成产品的生成是主要目标。在以下方面设置迭代的目标:修订了哪些错误,包含了 哪些性能或可用性方面的改进。如果以前不得不删除(或禁用)功能以及时地到达构造的结尾(IOC 里程碑或“beta”),则现在 就可以完成或打开它们(如果它们尚未危及目前已完成的目标的话)。

示例

  1. 修订所有在 beta 客户站点上发现的 1 级严重性问题。
    质量方面的目标可与市场可信度相关。
  2. 消除由于数据不匹配而产生的所有启动崩溃。
    另一个表现为质量形式的目标。
  3. 达到每分钟 2,000 次事务。
    性能调整,涉及到一些优化:数据结构更改、高速缓存和更聪明的算法。
  4. 将不同的对话框数目减少 30%。
    通过减少视觉混乱提高可用性
  5. 生成德语和日语版本。
    只为英语客户生成了 beta 版,因为时间不够且要减少返工。
定义迭代评估条件

每个迭代会生成可执行的发行版。该发行版通常达不到产品质量(最终移交迭代除外),但可以进行评估。

评估先启迭代

先启迭代通常着重于证明产品的概念和构造必要的支持,以核准项目资金投入。因此,迭代发行版通常是功能性的概念证明的原型,它单薄的用户界面下缺乏真正的实施代码。评估条件面向用户验收和定量度量。

在某些情况下,必须在先启阶段克服关键技术障碍,出资方才会为产品提供资金;如果是这样,评估条件必须反映此情况。

评估精化迭代

精化迭代着重于创建稳定的体系结构。因此,精化评估条件必须着重于评估体系结构的稳定性。可使用的度量有:

  • 接口稳定性(或故障可能性)
  • 体系结构中的变更率(与体系结构基线相比)
  • 关键功能的性能

关键目标是确保构造阶段的变更不会波及整个系统而导致过量的返工。

评估构造迭代和移交迭代

构造迭代和移交迭代通过传统软件测试和变更管理尺度进行度量,例如故障可能性、缺陷密度和故障发现率。这些迭代的重点在于查找错误,以便可以对它们进行修订。

可通过多种方法发现错误:检查和代码复审、功能测试、性能测试和负载测试。每项技术的目标均是发现一组特定的缺陷,每项技术都有其适用场合。在 Rational Unified Process 测试规程中讨论了这些技术的细节。



定义迭代活动

根据迭代目标,必须选择一组要在迭代期间执行的任务。 通常,每个迭代将部分地经历软件生命周期中的所有任务:

  • 选择执行必需功能的用例和场景
  • 研究和记录用例(或场景)行为
  • 分析行为,并在提供必需行为的子系统和类中分配行为
  • 设计与实施类和子系统,并对它们进行单元测试
  • 集成系统并作为一个整体进行测试
  • 对于外部发行版(alpha 版、beta 版和一般可用性),将产品封装为可发布的形式,并转换到用户环境中。

这些任务执行的程度随迭代以及项目阶段的不同而不同。各个规程(需求、分析和设计、测试等)定义了一般任务,这些任务又依次在流程配置期间针对组织进行了定制。

识别受影响的工作产品和涉及到的工作产品

一旦选择了要开发的场景或详细描述的用例(加上要修订的缺陷)并对它们进行了简要概述,您需要明了哪些工作产品将受到影响:

  • 要重访哪些类?
  • 哪些子系统受影响,或者甚至创建了哪些子系统?
  • 可能要修改哪些接口
  • 必须更新哪些文档

然后从流程规程中抽取涉及到的任务,并将它们放在您的计划中。一些任务在每次迭代执行一次(此处是例子),一些活动必须每个类、每个用例和每个子系统执行一次(例子)。将任务与它们明显的依赖关系连接,并分配一些估计的工时。为流程描述的大部分任务很小,小到足以由一个人或一个人数很少的团队在几小时或几天内完成。

可能发生以下情况,即您发现迭代中没有足够的时间来完成所有这些活动。此时我们不是扩展迭代(因此要么推迟最终交付时间,要么减少迭代数),而是降低迭代目标。根据您所处的阶段,可以简化场景,可以消除或禁用功能。

分配职责

一旦为迭代定义了一组任务,它们必须分配给各个项目团队成员。 根据可用的人力资源和迭代范围,任务可以由单个成员执行或由团队执行。当然,复审和检查的本质就是团队任务。其他任务(例如编写用例或设计和实施类)的本质是个人任务(以下情况除外,即一名初级团队成员与一名资深团队成员组成一个团队,后者担当前者的指导者)。

通常,以下每种工作产品必须是个人的职责,即使工作是由团队完成的:

  • 用例
  • 子系统
  • 测试和测试计划
  • 等等

没有单一的联系点,几乎不可能确保一致性。



关键注意事项

在项目规划中,项目经理实例化项目的特定交付流程(随后管理该流程的执行)(请参阅工作产品:开发流程)。这通常被称为流程制定。

“实例化”流程是可规定的项目/迭代/活动计划(它包含实际活动和实际项目的工作产品)。交付流程可以通过从 Rational Method Composer交付流程导入到 Rational Portfolio Manager(RPM)进行实例化,然后通过复制设置为 isRepeatable 或 hasMultipleOccurences 的活动和任务、创建实际的工作产品、将实际资源分配给角色等操作来进行实例化工作。

更多信息