瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别

时间 2019-11-24

原文原文链接

瀑布式开发、迭代开发，区别【都属于，生命周期模型】

二者都是一种开发模式，就像设计模式同样，考虑的角度不同，我的感受谈不到取代一说。

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

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

这两种开发模式都各自具备本身的特色，迭代式开发适合在一些需求信息不明确的项目中，这样在开发过程当中遇到需求的变化时，所带来的影响要比瀑布式开发小。而如今的不少项目中，需求在项目进行中变化的事儿常常见，因此显得迭代式开发的优点更明显一些。

可是，从本质上来讲，两者都不过是一种开发的模式，即便是迭代式开发，在每个迭代的环节中，不也是此从需求到设计，从设计到编码，从编码到测试吗？这不也是瀑布式模型的体现吗？只不过这个瀑布式中的每个阶段不须要作到最优化，都留一些任务到下一层迭代中去作而已。

因此，我以为面对不一样的问题采用不一样的模式，模式是为了方便咱们开发而服务的，不是要求咱们必须按照某一种模式从头走到尾。

就象迭代式开发，咱们其实也常常用到这种模式。好比说开发项目中的某一个模块。咱们先把可以实现主要功能的代码写出来。好比一个查询模块，先从模块的构思到设计再到编码，先查询功能的代码，测试一遍查询成功。这算是完成了第一层迭代。而后咱们要再考虑一层迭代中的一些还未完成的细节问题，好比查询的check，查询结果的显示以及查询算法的优化等等，这就是第二层迭代。

瀑布式开发，敏捷开发，区别【一种生命周期模型，项目管理方法集合】

瀑布模型的特色（传统的开发方式）

一、强调文档

前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的惟一信息。因此不少开发人员好象是在开发文档，而不是开发软件，由于要到开发的后期才能够看到软件的“模样”。

二、没有迭代与反馈。瀑布模型对反馈没有涉及，因此对变化的客户需求很是不容易适应。瀑布就意味着没有回头路。

三、管理人员喜欢瀑布模型的缘由是把文档理解为开发的速度，能够方便地界定不一样阶段的里程碑。

敏捷开发

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思惟的重要支持者。

敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。

敏捷开发集成了新型开发模式的共同特色，它重点强调：

1.敏捷就是“快”。快才能够适应目前社会的快节奏，要快就要发挥我的的个性思惟多一些个性思惟的增多。

2.客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。

3.强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

4.设计周密是为了最终软件的质量，但不代表设计比实现更重要。

5.迭代。软件的功能是客户的需求，界面的操做是客户的“感受”。对迭代的强调是缩短了软件版本的周期。

6.小版本。快速功能的展示，看似简单，但对于复杂的客户需求合理地分割与整体上的统一，要很好地两者兼顾是不容易的。

迭代开发，敏捷开发，区别【一种生命周期模型，项目管理方法集合】

迭代开发是一种软件开发的 生命周期模型,与其对应的还有瀑布模型、螺旋模型等等

敏捷开发是多种软件开发 项目管理方法的集合,其中 包括了XP、Scrum等十几种开发模式,这些开发方法有些共同点,好比重视响应变动,重视实现客户的价值,重视开发人员的自身发展等等,其核心体如今他们著名的四句原则中.这些开发方法基本都倾向于采用迭代的软件开发生命周期模型.

简单来讲, 迭代模型是敏捷开发广泛使用的软件生命周期模型, 敏捷开发所包含的内容比迭代模型宽泛的多.

敏捷开发中，XP与SCRUM的区别

区别之一：迭代长度的不一样算法

XP的一个Sprint的迭代长度大体为1~2周, 而Scrum的迭代长度通常为 2~ 4周.编程

区别之二: 在迭代中, 是否容许修改需求设计模式

XP在一个迭代中，若是一个User Story(用户素材, 也就是一个需求)尚未实现，则能够考虑用另外的需求将其替换，替换的原则是需求实现的时间量是相等的。而Scrum是不容许这样作的，一旦迭代开工会完毕, 任何需求都不容许添加进来，并有Scrum Master严格把关，不容许开发团队收到干扰框架

区别之三: 在迭代中，User Story是否严格按照优先级别来实现工具

XP是务必要遵照优先级别的。但Scrum在这点作得很灵活，能够不按照优先级别来作，Scrum这样处理的理由是：若是优先问题的解决者，因为其它事情耽搁，不能认领任务，那么整个进度就耽误了。另一个缘由是，若是按优先级排序的User Story #6和#10，虽然#6优先级高，可是若是#6的实现要依赖于#10，则不得不优先作#10.测试

区别之四:软件的实施过程当中，是否采用严格的工程方法，保证进度或者质量优化

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义很是严格，规定须要采用TDD, 自动测试，结对编程，简单设计，重构等约束团队的行为。所以，原做者认为，这点上，XP的作法值得认同的，可是却把敏捷带入了一个让人困惑的矛盾, 由于xp的理念，结合敏捷模式，表达给团队的信息是“你是一个彻底自我管理的组织，但你必需要实现TDD, 结对编程, ...等等”编码

不难发现，这四个区别显见的是： Scrum很是突出Self-Orgnization, XP注重强有力的工程实践约束spa

做者建议，在管理模式上启用Scrum，而在实践中，创造一个适合本身项目组的XP(“start with Scrum and then invent your own version of XP.”)设计

SCRUM介绍

回顾一下我所认识的scrum，算是对本身知识的一个梳理。
scrum究竟是什么，书中都说，它不是方法学，不是过程，而是一个框架。我并无太理解这句话，因此先把scrum中都有些什么来讲一下。

时间：scrum把时间分红一个个的sprint，也就是迭代周期。这个周期以2-6个星期为宜，但目前使用的最多的，是一个月，即四个星期。

每个sprint的开始和结束都会有一个会议，叫作sprint计划和sprint演示，这很好理解，计划时计划作什么，演示时演示作完的东西。而后，并非演示完了就完事的，sprint还有一个回顾会议，用来对这个sprint进行回顾，哪些作的好，哪些作的很差。这就是改进。

组成sprint的天天中，都会有每日例会，叫作每日站会，因此谓站会，便是时间很是短的会议，众所周知的，没完没了的会议老是让咱们，厌倦不已。而这种站会，我想差很少是从这方面来考虑的。

人物：scrum中有scrum master, product owner和scrum团队。我理解scrum master就是project manager，而product owner就是product manager，团队仍是那个团队，只是这里的团队，在规模上有必定的限制，它要求人员不要太多，不要太少，3-12个，一般4人团队比较多见，固然这个具体还得看实际状况来定。团队中开发测试人员比是1：1，即pair work。

scrum中的需求，采用story的形式进行描述，整个产品的需求，被列成product backlog，而每个迭代周期要作什么，是在每一个sprint的计划会议上进行挑选的，根据po对backlog标记的优先级，团队对其进行estimate并挑选出这个sprint里能完成的story，scrum master把它们列入计划中。

backlog有一个用于统计的东西，叫作燃尽图。从字面理解，就是燃烧掉多少的图，即sprint backlog中的被完成了多少，每完成一个story，就燃烧掉一个story。产品backlog有产品燃尽图，sprint有sprint燃尽图。

以上基本就是我了解的一些scrum知识点，其中忽略了工具部分和工做开展方式部分。由于采用什么工具或采用什么方式来实现，我认为是根据实际状况来定的，并且，在每一个sprint回顾会议中，这些东西都会被改进。使用excel或白板来记录story或backlog并不重要，重要的是，你是否有story或backlog。

所谓框架，是否是就是一种模式？真的很想理解这里的这个词。有知道的，请赐教。