文档介绍：传统开发流程的问题传统的软件开发流程是一个文档驱动的流程,它将整个软件开发过程划分为顺序相接的几个阶段,每个阶段都必需完成全部规定的任务(文档)后才能够进入下一个阶段。如必须完成全部的系统需求规格说明书之后才能够进入概要设计阶段,编码必需在系统设计完成之后才能够进行。这就意味着只有当所有的系统模块全部开发完成之后,我们才进行系统集成,对于一个由上百个模块组的复杂系统来说,这是一个非常艰巨而漫长的工作。随着我们所开发的软件项目越来越复杂,传统的瀑布型开发流程不断地暴露出以下问题:需求或设计中的错误往往只有到了项目后期才能够被发现例如:系统交付客户之后才发现原先对于需求的理解是错误的,系统设计中的问题要到测试阶段才能被发现。对于项目风险的控制能力较弱项目风险在项目开发较晚的时候才能够真正降低,往往是经过系统测试之后,才能确定该设计是否能够真正满足系统需求。软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱,需要进行返工或其他一些额外的开发周期,造成项目延期或费用超支。项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的,当他回答系统已完成了80%的开发任务时,剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。在传统的瀑布模型中,需求和设计中的问题是无法在项目开发的前期被检测出来的,只有当第一次系统集成时,这些设计缺陷才会在测试中暴露出来,从而导致一系列的返工:重新设计、编码、测试,进而导致项目的延期和开发成本的上升。,我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中,我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中,我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标,这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动,在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划,整个迭代过程包含了需求、设计、实施(编码)、部署、测试等各种类型的开发活动,迭代完成之后需要对迭代完成的结果进行评估,并以此为依据来制定下一次迭代的目标。与传统的瀑布式开发模型相比较,迭代化开发具有以下特点:允许变更需求需求总是会变化,这是事实。给项目带来麻烦的常常主要是需求变化和需求"蠕变",它们会导致延期交付、工期延误、客户不满意、开发人员受挫。通过向用户演示迭代所产生的部分系统功能,我们可以尽早地收集用户对于系统的反馈,及时改正对于用户需求的理解偏差,从而保证开发出来的系统真正地解决客户的问题。逐步集成元素在传统的项目开发中,由于要求一下子集成系统中所有的模块,集成阶段往往要占到整个项目很大比例的工作量(最高可达40%),这一阶段的工作经常是不确定并且非常棘手。在迭代式方法中,集成可以说是连续不断的,每一次迭代都会增量式集成一些新的系统功能,要集成的元素都比过去少得多,所以工作量和难度都是比较低的。尽早降低风险迭代化开发的主要指导原则就是以架构为中心,在早期的迭代中所要解决的主要问题就是尽快确定系统架构,通过几次迭代来尽快地设计出能够满足核心需求的系统架构,这样可以迅速降低整个项目的风险。等到系统架构稳定之后,项目的风险就比较低了,这个时候再去实现系统中尚未完成的功能,进而完成整个项目。有助于提高团队的士气开发人员通过每次迭代都可以在短期内看到自己的工作成果,从而有助于他们增强信心,更好地完成开发任务。而在非迭代式开发中,开发人员只有在项目接近尾声时才能看到开发的结果,在此之前的相当长时间,大家还是在不确定性中摸索前近。生成更高质量的产品每次迭代都会产生一个可运行的系统,通过对这个可运行系统进行测试,我们在早期的迭代中就可以及时发现缺陷并改正,性能上的瓶颈也可以尽早发现并处理。因为在每次迭代中总是不断地纠正错误,我们可以得到更高质量的产品。保证项目开发进度每次迭代结束时都会进行评估,来判断该次迭代有没有达到预定的目标。项目经理可以很清楚地知道有哪些需求已经实现了,并且比较准确地估计项目的状态,对项目的开发进度进行必要的调整,保证项目按时完成。容许产品进行战术改变迭代化的开发具有更大的灵活性,在迭代过程中可以随时根据业务情况或市场环境来对产品的开发进行调整。例如为了同现有的同类产品竞争,可以决定采用抢先竞争对手一步的方法,提前发布一个功能简化的产品。迭代流程自身可在进行过程中得到改进和精炼一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况,而且还要分析组织和流程本身有什么待改进之处,以便在下次迭代中更好地完成任务。迭代化方法解决的主要是对于风险的控制问题,从下图可以看出,传统的开发流程中系统的风险要到项目