全面解析瀑布式开发和敏捷式开发

2019-08-31 15:44:02
李露露
原创 60
摘要:拥有一颗拥抱新事物的心,对这个世界永远保持好奇。

很多人毕业后,都在从事跟所学专业不同的工作,有的人一筹莫展,有的人习以为常。

 

我是一名编导生,毕业后去做抗战纪录片,工作中接触更多的是历史、影像与表达。但一个偶然的契机,让我转战 互联网产品行业,工作中对接的是产品经理、开发和测试,用户画像、CDN UV PV 等一大堆新概念也扑面而来。后来又从产品逐渐深入到软件行业,有朋友认为这是新世界的大门;也有朋友觉得这是当下社会的缩影,各行各业的发展牵动着人性的各种追求与欲望,毕竟人们总想要追求新事物。于我而言,每天推陈出新,不断收获,享受当下就好,然而,接纳新事物其实没那么简单。

 

最开始接触软件行业,最常听到的就是瀑布式开发、敏捷开发,于是心里就有了疑问,我翻阅了各大网站查找相关的资料,去B 站上观看图文结合的相关视频, 结合自己的理解,以刚入行的视角现给大家整理了一份有关敏捷式开发与瀑布式开发的概念解析。

 

参考资料推荐禅道官网CSDN博客B站视频

 

一、什么是瀑布式开发

瀑布式开发的基本流程是 需求 设计 开发 测试 是一个更倾向于严格控制的管理模式 要求有明确的需求,大家按照需求一步步做好规划,每一阶段工作的完成是下一阶段工作开始的前提,每一阶段都要进行严格的评审,保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B 端的项目。


不得不说瀑布项目失败率会比较高,因为它有一个很大的缺陷, 就是受各种条件的制约。当产品研发完成后, 到了产品测试阶段 万一发现问题 ,或者发现其无法满足市场需求那么就需要重新开发,甚至需要重新规划产品,这 间接导致了产品延期发布的高发性 与不确定性

 

微软 的瀑布式开发模式就是个很好的例子。随着用户对软件的需求越来越苛刻,微软的软件产品曾经遭受了大家的不满,原因并非是产品的使用问题,而是其更新周期太过漫长 比如微软Office Windows 等主打产品的更新周期长达 3 年左右,软件延期发布实属家常便饭,此时微软的瀑布式开发模式已经难以满足新型软件的开发要求,不得不改变产品的研发策略。


 

随着网络的逐渐兴起,软件交付模式发生了巨大变化,也正是在 个时候,“敏捷开发”模式被国外的软件先行者们探索出来了。

 

二、什么是 敏捷 开发

简单的说,敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户(客户 最关注的软件原型做出来,交付或上线,在实际场景中去 快速 修改弥补需求中的不足,再次发布版本。通过一些敏捷实践方式,细化story ,提供更小的迭代。如此循环,直到用户(客户)满意。适用于需求不明确、创新性或者需要抢占市场的项目。

 

还是拿微软来说,微软的Visual Studio 2010是公司内部首个因敏捷开发模式而受益的Visual Studio版本,该软件发布于2010年4月,耗费了两年的时间完成开发,但随后研发团队发现软件中的许多模板对于敏捷开发者来说太过笼统,几乎没有太大的实际意义,微软的软件研发策略也就从此开始发生了巨大变化。以往的产品更新周期为两到三年,目前的版本更新速度已经缩短至一个季度左右,这在瀑布式开发模式下是难以想象的。


 

敏捷式开发在 国外大放异彩, 当然在国内也不例外,国内很多研发者们结合 当下软件市场环境,也有了新的研发策略。

 

国产开源的禅道项目管理软件,2009 年开始 遵循Scrum 敏捷式开发中比较流行的一种方式)的管理思想,发布了第一个 产品版本 。自发布以来,禅道曾数次 打败JIRA 及其他强有力的竞品连续四年荣膺国内外软件测试行业最常用测试管理工具第一名 ,也算是国产软件 的骄傲了。

 

 

在产品开发过程中, 禅道 研发团队认为Scrum方法 虽然 注重实效,操作性强,非常适合软件研发项目的快速迭代开发 但它只规定了核心的管理框架,还有很多细节流程没有完善。于是禅道团队结合国内研发现状,整合了bug管理、测试用例管理、发布管理、文档管理等功能,完整的覆盖了软件研发项目的整个生命周期。在禅道软件中,明确将产品、项目、测试三者概念区分开,产品人员、开发团队、测试人员,三者分立,互相配合,又互相制约,通过需求、任务、bug来进行交相互动,终通过项目拿到合格的产品,是敏捷式开发的优秀案例。

 

(禅道软件界面图)

 

三、瀑布式开发与敏捷式开发对比



 

瀑布式开发

敏捷式开发

 

 

 

 

工作方式


1.重视和强调过程文档,以文档驱动项目,将软件项目开发周期严格划分为几个固定阶段(需求分析,系统设计,软件设计,编码,测试,交付),每个阶段结束都有对应的详细文档作为输出;
2.上一个阶段的输出就是下一个阶段的输入,直至完成整个开发流程。



1.更加强调人的协作(团队之间,客户与团队之间),在高度协作的环境中使用迭代方式进行增量开发;
2.客户可对每次迭代的成果提出修改意见,开发人员进行调整和完善;
3.进行多次迭代直至完成完整产品交付。


 

 

 

 

优点


1.每个阶段目的明确,阶段人员完全专注于该阶段的工作,有助于提高阶段效率;
2. 由于存在详细的过程文档,在早期就能明确出项目的范围和概况,能够更有效的组织和调配资源开展项目。



1.阶段性成果可以在开发过程中被客户查验,从而降低项目开发的风险性;
2.灵活性高,需求的变更可在任何时候进行。


 

 

 

 

 

缺点


1.开发过程中大量的文档,极大的增加了工作量;
2.项目后期才能展示成果给客户,增加了项目开发的风险
(例如项目最终与客户预期差别很大,若要修复会造成项目的延期和成本增加);
3.需求变更的成本较高
(需求的变动理论上也会严格按照各个阶段去实施,导致时间成本过高)



1.最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;
2.敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证。


 

适用项目

软件需求十分明确并且不会有频繁变化的项目

需求不明确、具创新性或者需要抢占市场的项目


很显然,敏捷式开发与瀑布式开发有着质的区别,但总的来说,在管理项目过程中,都不会严格的按照完全的敏捷或者完全的瀑布模式进行开发,而是各自掺杂了其他的方式。可见,项目管理过程中,过于强调模式并没有意义,重要的是要能预防问题的发生,在问题发生之后,能用最小的成本解决,模式起到的更多是一个参考作用。 


接受新事物的过程虽说不易,但每天有所收获是件多么幸运的事儿啊。但愿不论何时的我们,都拥有一颗拥抱新事物的心,对这个世界永远保持好奇,这样我们就不会变老吧。


发表评论
评论通过审核后显示。