敏捷开发和迭代开发

阅读更多

敏捷开发与迭代式开发是整体与局部的关系

 

敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发过程中，只有开发团队，没有各个开发环节工种（分析师、设计师、架构师等）的划分，所有的工作都是团队会议明确、按照时间节点和任务节点交付。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

迭代开发：每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。迭代是敏捷开发中被划分出来的一个周期实现方式。可理解如下： 迭代一般指某版本的生产过程，包括从需求分析到测试完成； 版本一般指某阶段软件开发的结果，一个可交付使用的产品。迭代开发和敏捷开发都是弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

 

1、在项目初期先挑选系统核心架构的需求来实现，待系统核心架构完成后，再在系统核心架构的基础上不断的添加其他功能模块，通过累加开发的方式，来不断的完善系统，并在完善系统时，对系统的瑕疵或不足，不断的进行重构和改进设计工作。通过多个迭代的敏捷开发，并且每个迭代都会产生一个可使用的产品。这样一来，我们就会达到降低产品开发风险的目的。

 

敏捷建模不可缺少，UML规范就是给我们提供建模标准的，建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通，通过画一两张图来代替几十甚至几百行的代码，建模成为简化软件和软件（开发）过程的关键，而且比代码更容易控制和改变。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

3、有目的的建模，开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，但是要特别强调，我们没有必要每次应用所有的模型，而应该针对系统的具体情况，挑选能够解决问题的模型，不应该毫无意义的建模。首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单和完整。

4、并行创建模型，和团队他人一同开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。例如你在收集需求时，你需要开发一些基本用例或用户素材，一个基本业务流程等。敏捷建模者会发现在任何时候，同时进行多个模型的开发工作，要比单纯集中于一个模型要有效率的多。

5、持续测试和集成，每个迭代，我们都在做增加新功能和变更需求，产生新的版本，因此不断进行测试和集成，已达到可交付的产品，但是无论如何变更，模型都可以是最轻量级的持续改进，以保证最终的完整性和准确性。

 

针对中大型的软件开发来说，用例驱动、架构为中心的，无论是从需求用例还是测试用例，都可以统一对应，保证过程的完整统一。敏捷开发是一个轻装前进的过程，每一个过程都只关注当前的任务，但是在开始之前，我们必须要高瞻远瞩，综合评定，无论是在一开始的架构模型还是开发过程中的每一个系统模型，都要有合适的取舍，但是也要有考虑可扩展，可变更，可迭代的过程。

 

 

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

 

敏捷开发优点：

　1、降低风险
　　2、得到早期用户反馈
　　3、持续的测试和集成
　　4、使用变更
　　5、提高复用性