指南:软件开发计划
本指南为创建迭代开发周期的软件开发计划提供一些帮助。它还描述如何使传统的瀑布式复审序列与迭代法保持一致。
关系
主要描述

确定迭代的时间长度

我们已将迭代定义为一个相当完整的小项目,经历所有主要规程,并在多数情况下生成可执行但尚不完整的系统 - 一个发行版。尽管周期(编辑、编译、测试、调试)听起来像是一个迭代,但我们此处所说的不是这个意思。每日或每周工作版本递增地集成并测试越来越多的系统元素,这也可能看起来是一个迭代,但我们在这里使用这个术语时,那只是迭代的一部分。

迭代以计划和需求开始,并以(内部或外部的)发行版结束。

迭代的速度主要取决于开发组织的大小

例如:

  • 五个人可以在周一早上做些计划,每天一起吃午饭监视进度、重新分配任务,周四开始做一个工作版本,并在周五晚上完成迭代。
  • 但对于 20 个人来说,实现这项工作将非常困难。分派工作、使各分组之间同步、集成等,将需要更多时间。 一个迭代可能需要三四周。
  • 人数为 40 时,一周时间内要经历“从头脑紧张到全身紧张的过程”。您具有中间管理层,要对目标达成共识,将需要更正式的文档编写、更为形式。三个月可能是更为合理的迭代长度。

其他因素开始起作用:组织对迭代法的熟悉程度,包括一个稳定并成熟的组织、团队用于管理代码的自动化程度(例如,分发式 CM)、分发信息(例如,内部 Web)、自动化测试等。

还应注意迭代(在计划、同步、分析结果等方面)的一些固定开销。

所以,一方面虽确信迭代法所带来的巨大好处,您可能会忍不住进行积极迭代,但贵组织的人力限制将会降低您的热情。

一些经验数据:

SLOC 数 开发人员数 迭代的持续时间
10,000 5 1 周
50,000 15 1 个月
500,000 45 6 个月
1,000,000 100 1 年

  • 超过 6 个月的迭代可能需要内置一些中间里程碑才能使项目持续得到跟踪。考虑减少迭代的范围,以缩短其长度并确保焦点清楚。
  • 超过 12 个月的迭代会自行产生风险,因为迭代跨越了年度拨款周期。在过去 12 个月中未生成任何可见内容的项目有失去拨款的风险。
  • 少于 1 个月的迭代需要谨慎确定范围。通常,较短的迭代更适于构造阶段,其中要包括的新功能度和新颖度都很低。 较短的迭代很少进行或不进行正式分析或设计,可能只是递增地改进已得到较好理解的功能。
  • 迭代不需要长度一致:它们的长度将因目标而异。通常,精化阶段的迭代将长于构造阶段的迭代。在一个阶段内,迭代长度一般是相同的(这使计划更容易)。

一旦在您的粗略计划中想好了迭代数目,您就需要定义每个迭代的内容。最好能找一个名称或标题来限定迭代结束时得到的产品,从而使用户更容易判断。

私人电话交换机的示例迭代

  • 迭代 1:本地电话。
  • 迭代 2:添加外部电话和订户管理。
  • 迭代 3:添加语音邮件和电话会议。

确定迭代的次数

非常简单的项目可能每个阶段仅有一个迭代:

  • 先启阶段中一个迭代,可能生成一个概念证明原型或用户界面实体模型,或在(举例)演进周期的情况下根本没有迭代。
  • 精化阶段中一个迭代,生成一个体系结构原型。
  • 构造阶段有一次迭代,用于构建产品(最高可到“beta”发行版)。
  • 移交阶段中一个迭代,产生成品(完整产品发布)。

对于更重要的项目,在其初始开发周期,准则将是:

  • 先启阶段中一个迭代(可能生成原型)。
  • 精化阶段中两个迭代;一个用于体系结构原型,一个用于体系结构基线。
  • 构造阶段中两个迭代,展示一个部分系统并使其成熟。
  • 移交阶段中一个迭代,从初始运作能力到形成完整产品发布。

对于具有大量未知因素、新技术等的大型项目,可能会有以下情况:

  • 先启阶段中加一个迭代,允许进行更多的原型建立工作。
  • 精化阶段中加一个迭代,允许探究不同的技术。
  • 构造阶段中加一个迭代(由于产品的绝对规模)。
  • 移交阶段中加一个迭代,考虑到操作反馈。

所以,在一个开发周期内,我们有:

  • 低:3 个迭代(0、1、1、1)
  • 一般:6(1、2、2、1)
  • 高:9(1、3、3、2)
  • 极高:10(2、3、3、2)

所以,一般来说,计划使用 3 到 10 个迭代。但要看到,上下限意味着不同寻常的情况,所以多数开发将使用 6 到 8 个迭代。

根据风险、规模和复杂性,可能会有许多变化:

  • 如果产品针对于某一全新的领域,您可能需要在先启阶段中添加一些迭代,以强化各种概念,向具有广泛代表性的客户或最终用户显示各种实体模型,或对客户的标书作出认真的答复。
  • 如果必须开发新体系结构,或者有大量的用例建模工作,或者有很难处理的风险,则应计划在精化阶段进行两到三次迭代。
  • 如果产品大而复杂,并且开发时间较长,则应计划在构造阶段进行三次或更多次迭代。
  • 如果因为您必须最大限度地减少上市时间,而必须交付功能减少的产品,或如果您在使用一段时间后感到需要对最终用户群做许多小幅改编工作,则应计划在移交阶段使用几个迭代。

使传统的瀑布式复审序列与迭代法保持一致

在瀑布式生命周期项目的缺省复审序列中,完成重要的工作产品时将进行一次主要复审,例如:

  • 系统需求复审(SRR)(在系统规范完成时);
  • 软件规范复审(SSR)(在完成软件需求规范时);
  • 初步设计复审(PDR)(在完成软件设计说明的体系结构设计部分时);
  • 关键设计复审(CDR)(在完成软件设计说明的详细设计部分时)。

在 Rational Unified Process(RUP)中,对等工作产品的某些部分在每次迭代中完成时进行复审,但主要里程碑(以及相应复审)与先启、精化、构造和移交阶段结束的时间一致。由于合同上的义务,想要采用 RUP 的项目经理可能必须设法解决这种明显的冲突。理想情况下,项目经理应使客户确信基于阶段和迭代的方法实际上可以使客户更真实地了解项目进度,并降低风险,所以不需要 SRR、SSR 等。但是,这并不总是可行的,项目经理必须适当地安排这些复审。在 RUP 中,确定这些重要工作产品(实际上是它们在 RUP 中的等价物)基本完成的时间点是可能的,虽然这并不总是与阶段或迭代完全一致。

此处,这是通过假设将花费在需求、设计等方面的相关工作在 RUP 中与在(理想的)瀑布式生命周期中近似相同而进行的,但该工作的分发将是不同的。结果如下:

  • SRR(主要与远景有关)可以安排在先启阶段结束时;
  • SSR(主要与软件需求规范有关),在精化阶段进行到 1/3 时;
  • PDR(主要与软件体系结构文档有关),在精化阶段结束时;
  • CDR(主要与设计模型有关),在构造阶段进行到 1/3 时。

为了提高效率,项目经理应与客户协商,尽量合并这些复审与规定的 RUP 复审。这对于 SRR 和 PDR 显然是可能的:它们可以分别与生命周期目标里程碑复审和生命周期体系结构里程碑复审结合。

项目组织

正如软件流程受到项目特征的影响,项目组织也是如此。此处提供的缺省结构(见下图)必须经过改编才能反映下列因素的影响:

  • 业务环境
  • 软件开发工作的规模
  • 新颖度
  • 应用程序类型
  • 当前开发流程
  • 组织因素
  • 技术和管理的复杂性

当分析组织作为整体应如何采用新的开发流程时,它们是主要的区分因素,此处我们将检验它们对项目结构选择的影响。下图提供了一个缺省项目组织,显示职责如何分配给团队结构。

上下文相关的图,显示职责如何分配给团队成员。

显示缺省项目组织的图。请注意,在角色排序中资历或权威是无关紧要的。

此图是用于考虑项目级角色和职责应如何映射到团队结构的起点。另外,此图还可用于强调角色(在黄色框中显示)并不是个人,而是个人(或团队)可能在项目中担任的职务。正是出于此原因,某些角色(例如,项目经理)多次出现。这意味着,有时 RUP 中定义的项目经理的行为可能会在多个团队中出现。例如,在大型项目中,根据工作分解结构而准备状态报告的任务可能分派给管理团队中的个人。但这是 RUP 分配给称为“项目经理”的角色的职责。

在小型项目中,有可能由被任命为项目经理的个人来执行项目经理这一角色的所有任务,在这种情况下,行政管理团队与软件管理团队合为一体。选择团队结构将受到项目性质和规模的影响,但应按照一些比较常识性的规则进行调整:

  • 小型团队通常具有较高的生产效率;但在大型项目中,这必须与团队间的交互量相平衡
  • 应避免使层次结构过深
  • 任何经理或团队负责人的控制跨度都应限制在 7±2
  • 软件开发团队结构应取决于软件体系结构;好的体系结构(子系统之间的内聚度较高、耦合度较低)将使各团队能够以平行的方式更为高效地工作
  • 测试(除了单元测试)理想情况下应由独立于开发团队的团队执行。但请注意,这在小型项目中可能会不太经济
  • 结构必须允许向所有团队和个人提供明确定义的权限和职责。 如果层次结构超过 3 层,这尤其重要。处于此结构中部的经理和团队负责人需要明确在协调技术与管理任务方面对他们的要求。
  • 结构必须支持员工的能力、经验和动力:例如,假设单个团队要执行分析、设计和实施,而没有任何中间的移交,那么它将需要所有必要的技能。熟练的分析人员不一定是好的实施者;
  • 团队结构不应该是刚性的:个人将在项目的生命期内在团队之间迁移,团队的职责将随着项目重点的阶段变化而变化。

缺省组织的基本原理将在 [ROY98] 中详细讨论。特别是,当您向软件评估团队分配部署职责时会发现,在开发项目的所有团队中,软件评估团队将最充分地接触到用户将看到的软件。

在项目生命期内,组织将不断发展以支持项目计划中所包括的工作分解结构。下图(摘自 [ROY98])中显示了这一情况。

显示团队在项目生命周期中演进的图。

此演进强调了在每个阶段的不同任务集:

  • 先启团队:一个专注于计划的组织,将得到其他团队的大力支持,以确保这些计划代表了各方面的一致意见;
  • 精化团队:一个专注于体系结构的组织,其中项目的驱动力量存在于软件体系结构团队中,并在必要时由软件开发团队和软件评估团队提供支持以实现稳定的体系结构基线;
  • 构造团队:一种均衡的组织,该组织中的大多数任务都由软件开发和软件评估团队来完成;
  • 移交团队:即以客户为中心的组织。在该组织中,使用情况反馈将推动部署任务的进行。

这个演进期内的团队间迁移将确保知识和能力得以保留在项目中。例如,精化阶段完成后,一些体系结构团队成员可以分散到开发团队中,可能充当团队主管,或将体系结构“远景”带入开发中。同样,稍后在构造阶段结束时,焦点会转移到评估团队,并且会有员工从开发团队移到评估团队中。在此阶段,不允许随着项目“重心”的转移而减弱体系结构团队的作用,以避免为一时构造丧失体系结构完整性,这也很重要。将一些体系结构团队成员移到评估团队中就是这样一种方式。