迭代 给你一个标准的定义: 在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。 这个定义太学究气,半天看不明白。这样解释可能更容易理解: 我们开发一个产品,如果不太复杂,会采用瀑布模型,简单的说就是先需求定义,然后构建框架,然后写代码,然后测试,最后发布一个产品。 这样,几个月过去了,直到最后一天发布时,大家才能见到一个产品。 这样的方式有明显的缺点,假如我们对用户的需求判断的不是很准确时——这是很常见的问题,一点也不少见——你工作了几个月甚至是几年,当你把产品拿给客户看时,客户往往会大吃一惊,这就是我要的东西吗? 迭代的方式就有所不同,假如这个产品要求6个月交货,我在第一个月就会拿出一个产品来,当然,这个产品会很不完善,会有很多功能还没有添加进去,bug很多,还不稳定,但客户看了以后,会提出更详细的修改意见,这样,你就知道自己距离客户的需求有多远,我回家以后,再花一个月,在上个月所作的需求分析、框架设计、代码、测试等等的基础上,进一步改进,又拿出一个更完善的产品来,给客户看,让他们提意见。 就这样,我的产品在功能上、质量上都能够逐渐逼近客户的要求,不会出现我花了大量心血后,直到最后发布之时才发现根本不是客户要的东西。 这样的方法很不错,但他也有自己的缺陷,那就是周期长、成本很高。在应付大项目、高风险项目——就比如是航天飞机的控制系统时,迭代的成本比项目失败的风险成本低得多,用这种方式明显有优势。 如果你是给自己的单位开发一个小MIS,自己也比较清楚需求,工期上也不过花上个把月的时间,用迭代就有点杀鸡用了牛刀,那还是瀑布模型更管用,即使是做得不对,顶多再花一个月重来,没什么了不起。