UML软件工程组织

 

 

一种简单实用的迭代化开发方法
 
作者:陈国伟 来源:IBM
 
本文内容包括:
1. 前言
2. 迭代化开发方法
3. 结论
参考资料
迭代化开发做为一种软件开发方法,已经逐渐的得到应用。本文的目的是介绍一种可实践操作的迭代化开发方法,这种开发方法描述了如何以一种简单实用的方法来进行迭代化开发。通过采用本文所描述的迭代化开发的这种方法,能够降低项目组引入迭代化开发的难度和复杂度,从而尽可能的保证迭代化开发使用成功。

1. 前言

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

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

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

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

2. 迭代化开发方法

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

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

2.1 制订迭代计划

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

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

项目组人数 一个迭代多长时间(月)
15 人以下 1 个月
15~30 人 2 个月
大于 30 人 3 个月

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

迭代 分配的需求
第 2 个迭代 功能模块 A;功能模块 C;功能模块 D……
第 3 个迭代 功能模块 B;功能模块 E;功能模块 H……
第 n 个迭代 功能模块 F;功能模块 G……

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

迭代 分配的需求
第 2 个迭代 第 1 条需求;第 2 条需求;第 5 条需求……
第 3 个迭代 第 4 条需求;第 6 条需求;第 11 条需求……
第 n 个迭代 第 7 条需求;第 10 条需求;第 18 条需求……

总结下来,制订迭代计划的过程如下图:

图 1:迭代计划的过程图
迭代计划的过程图

2.2 监控迭代执行

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

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

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

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

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

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

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

迭代中开发和测试要配比

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

2.3 在迭代中执行测试

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

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

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

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

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

需求 对应的测试用例
需求 1 测试用例 1;测试用例 2
需求 2 测试用例 3;测试用例 4;测试用例 5
需求 n 测试用例 n……

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

2.4 进行迭代评估

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

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

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

3. 结论

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

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

参考资料

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号