全面解析瀑布式开发和敏捷式开发
发布网友
发布时间:2024-10-13 04:34
我来回答
共1个回答
热心网友
时间:2024-11-24 04:06
毕业后,许多人都从事着与所学专业不同的工作,有人感到迷茫,有人则习以为常。
作为一名编导生,我毕业后从事了抗战纪录片制作,工作中接触更多的是历史、影像与表达。但一个偶然的机会,我转战互联网产品行业,工作中对接的是产品经理、开发和测试,也接触到了用户画像、CDN、UV、PV等新概念。
后来,我又逐渐深入到软件行业。有人认为这是新世界的大门,有人则觉得这是当下社会的缩影,各行各业的发展都牵动着人性的各种追求与*,人们总是追求新事物。对我而言,每天推陈出新,不断收获,享受当下就好。然而,接纳新事物其实并不简单。
最初接触软件行业时,最常听到的是瀑布式开发和敏捷开发。我查阅了各大网站,观看了B站上的相关视频,结合自己的理解,整理了一份有关敏捷式开发与瀑布式开发的概念解析。
参考资料推荐:禅道官网、CSDN博客、B站视频
一、什么是瀑布式开发
瀑布式开发的基本流程是需求 → 设计 → 开发 → 测试,是一种更倾向于严格控制的管理模式。它要求有明确的需求,大家按照需求一步步做好规划,每一阶段工作的完成是下一阶段工作开始的前提。每一阶段都要进行严格的评审,保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B端的项目。
不得不说,瀑布项目失败率会比较高,因为它有一个很大的缺陷,就是受各种条件的制约。当产品研发完成后,到了产品测试阶段,如果发现问题,或者发现其无法满足市场需求,就需要重新开发,甚至重新规划产品,这间接导致了产品延期发布的高发性和不确定性。
微软的瀑布式开发模式就是一个很好的例子。随着用户对软件的需求越来越苛刻,微软的软件产品曾经遭受了大家的不满,原因并非是产品的使用问题,而是其更新周期太过漫长。
比如微软Office、Windows等主打产品的更新周期长达3年左右,软件延期发布实属家常便饭。此时,微软的瀑布式开发模式已经难以满足新型软件的开发要求,不得不改变产品的研发策略。
随着网络的逐渐兴起,软件交付模式发生了巨大变化,也正是在那个时候,“敏捷开发”模式被国外的软件先行者们探索出来了。
二、什么是敏捷式开发
简单地来说,敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把用户(客户)最关注的软件原型做出来,交付或上线,在实际场景中去快速修改弥补需求中的不足,再次发布版本。通过一些敏捷实践方式,细化story,提供更小的迭代。如此循环,直到用户(客户)满意。适用于需求不明确、创新性或者需要抢占市场的项目。
还是拿微软来说,微软的Visual Studio 2010是公司内部首个因敏捷开发模式而受益的Visual Studio版本,该软件发布于2010年4月,耗费了两年的时间完成开发。但随后研发团队发现软件中的许多模板对于敏捷开发者来说太过笼统,几乎没有太大的实际意义。微软的软件研发策略也就从此开始发生了巨大变化。以往的产品更新周期为两到三年,目前的版本更新速度已经缩短至一个季度左右,这在瀑布式开发模式下是难以想象的。
敏捷式开发在国外大放异彩,当然在国内也不例外。国内很多研发者们结合当下软件市场环境,也有了新的研发策略。
国产开源的禅道项目管理软件,2009年开始遵循Scrum(敏捷式开发中比较流行的一种方式)的管理思想,发布了第一个产品版本。自发布以来,禅道曾连续四年荣膺国内外软件测试行业最常用测试管理工具第一名,也算是国产软件的骄傲了。
在产品开发过程中,禅道研发团队认为Scrum方法虽然注重实效,操作性强,非常适合软件研发项目的快速迭代开发,但它只规定了核心的管理框架,还有很多细节流程没有完善。于是禅道团队结合国内研发现状,整合了Bug管理、测试用例管理、发布管理、文档管理等功能,完整的覆盖了软件研发项目的整个流程。
在禅道软件中,明确将产品、项目、测试三者概念区分开,产品人员、开发团队、测试人员,三者分立,互相配合,又互相制约,通过需求、任务、Bug来进行交相互动,最终通过项目拿到合格的产品,是敏捷式开发的优秀案例。
三、瀑布式开发与敏捷式开发对比
很显然,敏捷式开发与瀑布式开发有着质的区别,但总的来说,在管理项目过程中,都不会严格按照完全的敏捷或完全的瀑布模式进行开发,而是各自掺杂了其他的方式。
可见,项目管理过程中,过于强调模式并没有意义,重要的是要能预防问题的发生,在问题发生之后,能用最小的成本解决,模式起到的更多是一个参考作用。
接受新事物的过程虽然不易,但每天有所收获是件多么幸运的事儿啊。但愿无论何时我们,都拥有一颗拥抱新事物的心,对这个世界永远保持好奇,这样我们就不会变老吧。