一种简单实用的迭代化开发方法

迭代化开发做为一种软件开发方法，已经逐渐的得到应用。本文的目的是介绍一种可实践操作的迭代化开发方法，这种开发方法描述了如 何以一种简单实用的方法来进行迭代化开发。通过采用本文所描述的迭代化开发的这种方法，能够降低项目组引入迭代化开发的难度和复杂度，从而尽可能的保证迭 代化开发使用成功。

1. 前言

迭代化开发做为一种软件开发方法，相比传统的瀑布式开发方法而言，具备很多无可比拟的优势。正是因为看到迭代化开发的这些优势，越来越多的开发组织正在内部推行核心业务流程的变革，将软件开发这种在开发组织中最核心的业务流程，由以前的瀑布式开发转换到迭代化开发。

在 从瀑布式开发向迭代化开发的转换中，我们发现，相对来讲，很多的开发组织将迭代化的开发过程定义得太复杂，引入的技术太多，同时加上项目组本身对迭代化开 发不熟悉，很难在短时间内掌握这些方法，就造成很多的项目组在使用迭代化开发的过程中，遇到相当多的困难甚至是最终失败。

从 我们的经验来看，要成功的引入迭代化开发，必须转变一下思维的方式，必须从最简单做起，越简单，就越容易被理解和执行，就越容易成功。也就是说，在迭代化 开发引入的过程中，不能再像以前一样，定义一个庞大而完善的迭代化开发过程让项目组去裁减，而是应该定义一个小的、简单的内核，这个内核很精简，不会包括 迭代化开发所需要执行的方方面面，只包括迭代化开发所应该执行的核心的活动。因为这个内核很精简，不需要项目组再去裁减，项目组需要做的是要么直接使用 它，要么以扩展的方式去使用它。

本文就是向大家介绍这样一种迭代化开发方法，这种迭代化开发方法尽量的简单但是够用，它只包含迭代化开发的核心的集合，以及执行这些集合的简单的方法。我们期望通过这种迭代化开发方法能够先让项目组将迭代用起来 – 因为迭代首先能够用起来，比什么都重要。

2. 迭代化开发方法

本文介绍的迭代化开发方法主要包括以下四个方面：制订迭代计划；监控迭代执行；在迭代中执行测试；进行迭代评估。

制订迭代计划主要关注我们应该如何划分迭代，如何制订每个迭代的迭代目标；监控迭代执行主要关注如何处理迭代执行中遇到的相关情况；在迭代中执行测试主要关注如何将测试和迭代目标关联起来；进行迭代评估主要关注如何评估迭代，保证每个迭代都能够有所收获。

2.1 制订迭代计划

一般来讲，在项目开始的时候，项目经理会对当前项目的工作范围、项目的周期有简单的了解，此时就可以开始制订迭代计划。

第一步，根据项目的周期，来划分当前项目总共应该有多少个迭代，并且要求每个迭代的周期是一致的。其实到底一个项目应该划分多少个迭代，是仁者见仁、智者见智的事情。所以，可以参考以下的列表来划分迭代：

项目组人数 一个迭代多长时间（月） 15 人以下 15~30 人 大于 30 人

1 个月

2 个月

3 个月

 

第 二步，将第 1 个迭代（或者最前的几个迭代）保留下来，用来安排进行需求调研。然后根据现在所知的粗粒度的需求，以技术的难度、业务的优先级为判断依据，分配到剩余的迭 代中，技术难度越大、业务优先级越高的需求，分配到越靠前的迭代中。分配完成后，再根据需求之间的依赖关系、工作量这两个因素进行调整。此时，可以得到以 下示例的迭代计划（假设第 1 个迭代留给需求调研）：

迭代 分配的需求 第 2 个迭代 第 3 个迭代 第 n 个迭代

功能模块 A；功能模块 C；功能模块 D……

功能模块 B；功能模块 E；功能模块 H……

功能模块 F；功能模块 G……

 

第 三步，执行第 1 个迭代（或者是要进行需求调研的迭代），执行完成后，得到详细的需求。此时，不管以何种方法来记录需求，唯一要做的就是将这些需求条目化。也就是将这些需 求，划分成一条一条的这种形式，然后，再以条目化之后的需求，去更新在第二步中分配的粗粒度的需求。此时，可以根据情况对各个迭代中分配的需求进行调整 （假设第 1 个迭代留给需求调研）：

迭代 分配的需求 第 2 个迭代 第 3 个迭代 第 n 个迭代

第 1 条需求；第 2 条需求；第 5 条需求……

第 4 条需求；第 6 条需求；第 11 条需求……

第 7 条需求；第 10 条需求；第 18 条需求……

 

总结下来，制订迭代计划的过程如下图：

图 1：迭代计划的过程图

2.2 监控迭代执行

在 迭代中，按照分配给这个迭代的需求，以此作为当前迭代的范围，开始按照需求、分析设计、开发和测试这个流程执行，这个流程和瀑布式是一样的，所以就按照项 目组以前的瀑布式方式执行就可以，项目组不需要做任何的改变。在监控迭代执行的时候，只需要注意的是以下几个方面的情况：

分配给迭代的需求如果不能按时开发完成，应该如何处理

迭 代是时间盒的，也就是说，每个迭代有明确的开始和结束时间，并且到达结束时间时，一定要结束这个迭代，不能延期，这是做迭代的时候遵循的原则之一。所以， 此时就会产生一个问题，那就是如果在制订迭代计划的时候，分配给这个迭代的需求太多，到迭代后期的时候才发现完成不了，此时应该如何处理？答案就是，缩减 当前迭代的范围，按时结束迭代。

迭代中测试出来的错误，来不及修改完成，应该如何处理

每次迭代中，均会执行测试，有些时候，测试执行完成，但是测试得到的缺陷，却无法在当前迭代结束前修改完成，此时，应该如何处理？答案就是，迭代中的测试要执行完毕，但是错误的修改，可以安排到下一次迭代中进行。

迭代执行过程中，如果发生需求变更，应该如何处理

自 从有软件开发这个活动，变更就从来没有停止过，变更已经是软件开发这个人类认识自然的这个活动中的规律之一，在迭代中也不例外，所以，当在迭代中发生需求 变更时，应该如何处理？此时，分为两种情况，第一种情况是，如果这个需求变更是变更以后的迭代中分配的那些需求的，那么在这种情况下，当前迭代不用考虑； 第二种情况是，如果这个需求变更是变更当前迭代中分配的这些需求的，那么此时要进行判断，如果能够在当前迭代结束前完成此变更，那么就将此变更纳入到当前 迭代中，如果不能在当前迭代结束前完成此变更，那么在当前迭代中就不用考虑。

迭代中开发和测试要配比

要以类似于“权责配比”的原则来处理，即当前迭代中开发那些需求，那么就应该将针对这些需求的测试放到当前的这个迭代中。不要在一个迭代中针对这些需求做开发，而将针对这些需求的测试放到另外一个迭代中。

2.3 在迭代中执行测试

因为每个迭代都是一个瀑布，开发完成后要发布可执行的工作版本，所以在每个迭代中都需要执行测试。在每个迭代中执行测试，可以参考以下的过程：

图 2：在每个迭代中执行测试的过程

开 发结束后发布工作版本，测试针对工作版本进行测试。可以看到，除了在迭代中要执行测试之外，其它的地方和瀑布式开发是一样的，项目组按照以前的方式执行就 可以了。在测试用例中，我们强调从需求生成测试用例，即当前迭代中开发什么，就测试什么，根据分配到迭代中的需求，来创建测试用例：

图 3：根据分配到迭代中的需求，来创建测试用例。

在创建测试用例的过程中，需要创建测试用例到需求的映射：

需求 对应的测试用例 需求 1 需求 2 需求 n

测试用例 1；测试用例 2

测试用例 3；测试用例 4；测试用例 5

测试用例 n……

 

我们在迭代评估中会用到此映射表。

2.4 进行迭代评估

在每个迭代结束的时候，一个重要的工作就是进行迭代评估。迭代评估就像是一面镜子，能够让相关人员，包括项目组自己，看到当前项目的状态，通过迭代评估，能够保证项目行驶在正确的轨道上。迭代评估的时间一般为半天时间。最好让客户/最终用户参与到迭代评估中。

我们以测试结果来进行评估。对于分配到迭代上的每一条需求，如果和它相对应的测试用例均通过，那么就代表此需求通过。当迭代结束时，根据刚才的判断方法，可以看到每一条需求是通过还是不通过，如果不通过，一定要找出原因，总结经验教训，在以后加以改进：

分配到当前迭代的需求 是否通过 如果没有通过，原因是什么 需求 1 需求 2 需求 n

3. 结论

可 以看到，在这种迭代化开发方法中，我们主要关注制订迭代计划、监控迭代执行、在迭代中进行测试和进行迭代评估这四个方面。在迭代评估中，我们就根据简单的 规则划分迭代，然后将需求分配到迭代中即可，操作比较简单；在监控迭代执行中，只需要关注相关情况的处理；在迭代中进行测试，主要的改变是要在迭代中执行 测试，并且要在测试用例和条目化需求之间建立关系；在进行迭代评估中，要根据测试的结果找出需求没有通过的原因。

通过执行以上的这些关键活动，项目组就能够将迭代化开发以简单的方式使用起来，降低项目组引入迭代化开发的难度和复杂度，从而尽可能的保证迭代化开发使用成功。当项目组将迭代使用起来之后，再根据情况进行扩展，相应来讲，就简单得多。

 

参考资料

• 在 developerWorks 上可以找到 RUP 专题 。
  
  
• 参考 “什么是迭代化开发 ”。
  
  
• 参考 “将项目从瀑布式转为迭代过程 ”。
  
  
• 参考 “从瀑布型开发到迭代型开发的转变 ”。
  
  
• 参考 “迭代化软件开发技术: IBM Rational 技术白皮书 ”。
  
  
• 参考 “IBM 如何使用 IRUP 来迭代化地开发软件产品 ”。
  
  
• 请访问 IBM developerWorks 中国网站 Rational 专区 能得到更多关于 IBM IBM Rational 产品的文章、教程和其他参考资源。

 

关于作者

		陈 国伟，IBM 中国软件开发中心实验室服务，高级软件工程师，2005 年加入 IBM，专注于 Rational 软件，拥有 RUP/RMUC/OOAD 认证。目前主要致力于为客户提供软件工程的方法、技术和工具的支持与服务，关注的领域有 Java 开发、RUP 实施、用例建模、OOAD、测试以及配置和变更管理。在加入 IBM 之前，在 ERP、保险、电信等大型软件项目上拥有 6 年开发和管理经验。