瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别
瀑布式开发、迭代开发,区别【都属于,⽣命周期模型】
两者都是⼀种开发模式,就像设计模式⼀样,考虑的⾓度不⼀样,个⼈感觉谈不到取代⼀说。
传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交⼤概这样的流程,要求每⼀个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。很多外包项⽬就是这样的流程。
迭代式开发,不要求每⼀个阶段的任务做的都是最完美的,⽽是明明知道还有很多不⾜的地⽅,却偏偏不去完善它,⽽是把主要功能先搭建起来为⽬的,以最短的时间,最少的损失先完成⼀个“不完美的成果物”直⾄提交。然后再通过客户或⽤户的反馈信息,在这个“不完美的成果物”上逐步进⾏完善。        这两种开发模式都各⾃具有⾃⼰的特点, 迭代式开发适合在⼀些需求信息不明确的项⽬中,这样在开发过程中遇到需求的变化时,所带来的影响要⽐瀑布式开发⼩。⽽现在的很多项⽬中,需求在项⽬进⾏中变化的事⼉经常见,所以显得迭代式开发的优势更明显⼀些。
但是,从本质上来说,⼆者都不过是⼀种开发的模式,即使是迭代式开发,在每⼀个迭代的环节中,不也是此从需求到设计,从设计到编码,从编码到测试吗?这不也是瀑布式模型的体现吗?只不过这个瀑布式中的每⼀个阶段不需要做到最优化,都留⼀些任务到下⼀层迭代中去做⽽已。
所以,我觉得⾯对不同的问题采⽤不同的模式,模式是为了⽅便我们开发⽽服务的,不是要求我们必须按照某⼀种模式从头⾛到尾。
就象迭代式开发,我们其实也经常⽤到这种模式。⽐如说开发项⽬中的某⼀个模块。我们先把能够实现主要功能的代码写出来。⽐如⼀个查询模块,先从模块的构思到设计再到编码,先查询功能的代码,测试⼀遍查询成功。这算是完成了第⼀层迭代。然后我们要再考虑⼀层迭代中的⼀些还未完成的细节问题,⽐如查询的check,查询结果的显⽰以及查询算法的优化等等,这就是第⼆层迭代。
瀑布式开发,敏捷开发,区别【⼀种⽣命周期模型,项⽬管理⽅法集合】
瀑布模型的特点(传统的开发⽅式)
1、强调⽂档
前⼀个阶段的输出就是下⼀个阶段的输⼊,⽂档是个阶段衔接的唯⼀信息。所以很多开发⼈员好象是在开发⽂档,⽽不是开发软件,因为要到开发的后期才可以看到软件的“模样”。
2、没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求⾮常不容易适应。瀑布就意味着没有回头路。
3、管理⼈员喜欢瀑布模型的原因是把⽂档理解为开发的速度,可以⽅便地界定不同阶段的⾥程碑。
敏捷开发
极限编程的思想体现了适应客户需求的快速变化,激发开发者的热情,也是⽬前敏捷开发思维的重要⽀持者。
敏捷软件开发是⼀个开发软件的管理新模式,⽤来替代以⽂件驱动开发的瀑布开发模式。
敏捷开发集成了新型开发模式的共同特点,它重点强调:
1.敏捷就是 “快”。快才可以适应⽬前社会的快节奏,要快就要发挥个⼈的个性思维多⼀些个性思维的增多。
2. 客户参与。以⼈为本,客户是软件的使⽤者,是业务理解的专家,没有客户的参与,开发者很难理解客户的真实需求。
3. 强调软件开发的产品是 软件,⽽不是⽂档。⽂档是为软件开发服务的,⽽不是开发的主体。
4.设计周密是为了最终软件的质量,但不表明设计⽐实现更重要。
5. 迭代。软件的功能是客户的需求,界⾯的操作是客户的“感觉”。对迭代的强调是 缩短了软件版本的周期。
6.⼩版本。快速功能的展现,看似简单,但对于复杂的客户需求合理地分割与总体上的统⼀,要很好地⼆者兼顾是不容易的。
xp提交更改迭代开发,敏捷开发,区别【⼀种⽣命周期模型,项⽬管理⽅法集合】
迭代开发是⼀种软件开发的⽣命周期模型,与其对应的还有瀑布模型、螺旋模型等等
敏捷开发是 多种软件开发 项⽬管理⽅法的集合,其中 包括了XP、Scrum等⼗⼏种开发模式,这些开发⽅法有些共同点,⽐如重视响应变更,重视实现客户的价值,重视开发⼈员的⾃⾝发展等等,其核⼼体现在他们著名的四句原则中.这些开发⽅法基本都倾向于采⽤迭代的软件开发⽣命周期模型.
(1)⼈和交互重于过程和⼯具。
(2)可以⼯作的软件重于求全⽽完备的⽂档。
(3)客户协作重于合同谈判。
(4)随时应对变化重于循规蹈矩。
简单来说, 迭代模型是敏捷开发普遍使⽤的软件⽣命周期模型, 敏捷开发所包含的内容⽐迭代模型宽泛的多.
敏捷开发中,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注重强有⼒的⼯程实践约束
作者建议, 在管理模式上启⽤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。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。