| UML软件工程组织 | |||
| |
|||
|
|||
一种简单实用的迭代化开发方法
作者：陈国伟 来源：IBM
迭代化开发做为一种软件开发方法，已经逐渐的得到应用。本文的目的是介绍一种可实践操作的迭代化开发方法，这种开发方法描述了如何以一种简单实用的方法来进行迭代化开发。通过采用本文所描述的迭代化开发的这种方法，能够降低项目组引入迭代化开发的难度和复杂度，从而尽可能的保证迭代化开发使用成功。 1. 前言迭代化开发做为一种软件开发方法，相比传统的瀑布式开发方法而言，具备很多无可比拟的优势。正是因为看到迭代化开发的这些优势，越来越多的开发组织正在内部推行核心业务流程的变革，将软件开发这种在开发组织中最核心的业务流程，由以前的瀑布式开发转换到迭代化开发。 在从瀑布式开发向迭代化开发的转换中，我们发现，相对来讲，很多的开发组织将迭代化的开发过程定义得太复杂，引入的技术太多，同时加上项目组本身对迭代化开发不熟悉，很难在短时间内掌握这些方法，就造成很多的项目组在使用迭代化开发的过程中，遇到相当多的困难甚至是最终失败。 从我们的经验来看，要成功的引入迭代化开发，必须转变一下思维的方式，必须从最简单做起，越简单，就越容易被理解和执行，就越容易成功。也就是说，在迭代化开发引入的过程中，不能再像以前一样，定义一个庞大而完善的迭代化开发过程让项目组去裁减，而是应该定义一个小的、简单的内核，这个内核很精简，不会包括迭代化开发所需要执行的方方面面，只包括迭代化开发所应该执行的核心的活动。因为这个内核很精简，不需要项目组再去裁减，项目组需要做的是要么直接使用它，要么以扩展的方式去使用它。 本文就是向大家介绍这样一种迭代化开发方法，这种迭代化开发方法尽量的简单但是够用，它只包含迭代化开发的核心的集合，以及执行这些集合的简单的方法。我们期望通过这种迭代化开发方法能够先让项目组将迭代用起来 – 因为迭代首先能够用起来，比什么都重要。 2. 迭代化开发方法本文介绍的迭代化开发方法主要包括以下四个方面：制订迭代计划；监控迭代执行；在迭代中执行测试；进行迭代评估。 制订迭代计划主要关注我们应该如何划分迭代，如何制订每个迭代的迭代目标；监控迭代执行主要关注如何处理迭代执行中遇到的相关情况；在迭代中执行测试主要关注如何将测试和迭代目标关联起来；进行迭代评估主要关注如何评估迭代，保证每个迭代都能够有所收获。 一般来讲，在项目开始的时候，项目经理会对当前项目的工作范围、项目的周期有简单的了解，此时就可以开始制订迭代计划。 第一步，根据项目的周期，来划分当前项目总共应该有多少个迭代，并且要求每个迭代的周期是一致的。其实到底一个项目应该划分多少个迭代，是仁者见仁、智者见智的事情。所以，可以参考以下的列表来划分迭代：
第二步，将第 1 个迭代（或者最前的几个迭代）保留下来，用来安排进行需求调研。然后根据现在所知的粗粒度的需求，以技术的难度、业务的优先级为判断依据，分配到剩余的迭代中，技术难度越大、业务优先级越高的需求，分配到越靠前的迭代中。分配完成后，再根据需求之间的依赖关系、工作量这两个因素进行调整。此时，可以得到以下示例的迭代计划（假设第 1 个迭代留给需求调研）：
第三步，执行第 1 个迭代（或者是要进行需求调研的迭代），执行完成后，得到详细的需求。此时，不管以何种方法来记录需求，唯一要做的就是将这些需求条目化。也就是将这些需求，划分成一条一条的这种形式，然后，再以条目化之后的需求，去更新在第二步中分配的粗粒度的需求。此时，可以根据情况对各个迭代中分配的需求进行调整（假设第 1 个迭代留给需求调研）：
总结下来，制订迭代计划的过程如下图： 图 1：迭代计划的过程图
在迭代中，按照分配给这个迭代的需求，以此作为当前迭代的范围，开始按照需求、分析设计、开发和测试这个流程执行，这个流程和瀑布式是一样的，所以就按照项目组以前的瀑布式方式执行就可以，项目组不需要做任何的改变。在监控迭代执行的时候，只需要注意的是以下几个方面的情况： 分配给迭代的需求如果不能按时开发完成，应该如何处理 迭代是时间盒的，也就是说，每个迭代有明确的开始和结束时间，并且到达结束时间时，一定要结束这个迭代，不能延期，这是做迭代的时候遵循的原则之一。所以，此时就会产生一个问题，那就是如果在制订迭代计划的时候，分配给这个迭代的需求太多，到迭代后期的时候才发现完成不了，此时应该如何处理？答案就是，缩减当前迭代的范围，按时结束迭代。 迭代中测试出来的错误，来不及修改完成，应该如何处理 每次迭代中，均会执行测试，有些时候，测试执行完成，但是测试得到的缺陷，却无法在当前迭代结束前修改完成，此时，应该如何处理？答案就是，迭代中的测试要执行完毕，但是错误的修改，可以安排到下一次迭代中进行。 迭代执行过程中，如果发生需求变更，应该如何处理 自从有软件开发这个活动，变更就从来没有停止过，变更已经是软件开发这个人类认识自然的这个活动中的规律之一，在迭代中也不例外，所以，当在迭代中发生需求变更时，应该如何处理？此时，分为两种情况，第一种情况是，如果这个需求变更是变更以后的迭代中分配的那些需求的，那么在这种情况下，当前迭代不用考虑；第二种情况是，如果这个需求变更是变更当前迭代中分配的这些需求的，那么此时要进行判断，如果能够在当前迭代结束前完成此变更，那么就将此变更纳入到当前迭代中，如果不能在当前迭代结束前完成此变更，那么在当前迭代中就不用考虑。 迭代中开发和测试要配比 要以类似于“权责配比”的原则来处理，即当前迭代中开发那些需求，那么就应该将针对这些需求的测试放到当前的这个迭代中。不要在一个迭代中针对这些需求做开发，而将针对这些需求的测试放到另外一个迭代中。 因为每个迭代都是一个瀑布，开发完成后要发布可执行的工作版本，所以在每个迭代中都需要执行测试。在每个迭代中执行测试，可以参考以下的过程： 图 2：在每个迭代中执行测试的过程
开发结束后发布工作版本，测试针对工作版本进行测试。可以看到，除了在迭代中要执行测试之外，其它的地方和瀑布式开发是一样的，项目组按照以前的方式执行就可以了。在测试用例中，我们强调从需求生成测试用例，即当前迭代中开发什么，就测试什么，根据分配到迭代中的需求，来创建测试用例： 图 3：根据分配到迭代中的需求，来创建测试用例。
在创建测试用例的过程中，需要创建测试用例到需求的映射：
我们在迭代评估中会用到此映射表。 在每个迭代结束的时候，一个重要的工作就是进行迭代评估。迭代评估就像是一面镜子，能够让相关人员，包括项目组自己，看到当前项目的状态，通过迭代评估，能够保证项目行驶在正确的轨道上。迭代评估的时间一般为半天时间。最好让客户/最终用户参与到迭代评估中。 我们以测试结果来进行评估。对于分配到迭代上的每一条需求，如果和它相对应的测试用例均通过，那么就代表此需求通过。当迭代结束时，根据刚才的判断方法，可以看到每一条需求是通过还是不通过，如果不通过，一定要找出原因，总结经验教训，在以后加以改进：
3. 结论可以看到，在这种迭代化开发方法中，我们主要关注制订迭代计划、监控迭代执行、在迭代中进行测试和进行迭代评估这四个方面。在迭代评估中，我们就根据简单的规则划分迭代，然后将需求分配到迭代中即可，操作比较简单；在监控迭代执行中，只需要关注相关情况的处理；在迭代中进行测试，主要的改变是要在迭代中执行测试，并且要在测试用例和条目化需求之间建立关系；在进行迭代评估中，要根据测试的结果找出需求没有通过的原因。 通过执行以上的这些关键活动，项目组就能够将迭代化开发以简单的方式使用起来，降低项目组引入迭代化开发的难度和复杂度，从而尽可能的保证迭代化开发使用成功。当项目组将迭代使用起来之后，再根据情况进行扩展，相应来讲，就简单得多。 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
