瀑布式开发模式将软件开发的过程分为系统计划、需求分析、系统设计、系统编码、系统测试、系统运行和维护6个阶段,每一阶段工作的完成是下一阶段工作开始的前提,每一阶段都要进行严格的评审,保证各阶段的工作做得足够好时才允许进入下一阶段。
瀑布式开发模式在上世纪70年代被正式命名之后就备受争议,尽管有不少公司在软件开发中使用该模型,但它一直未能获得业界的广泛认可,相反,还有许多业内人士该模型是造成软件开发延期或失败的主要原因。
尽管如此,瀑布式开发模式在如今的制造业和建筑业领域中应用仍然非常广泛,因为这两个行业中的项目进度大多是不可逆的,所以使用这套略显刻板的模型反而能够避免一些不必要的成本支出。
相比之下,软件项目在后期进行修改的成本要比一栋楼简单许多,同时软件开发过程中的不确定因素也要更多一些,所以许多软件项目往往会在某一阶段的开发完成之后再对需求做出修改,这显然与瀑布式开发模式的理念是相悖的。
瀑布式开发模式在微软的应用
虽然微软在软件开发中并没有使用纯粹意义上的瀑布式开发模式(部分开发过程有所反复),但总体上来说还是沿用了瀑布式开发流程,其中的一个代表作的就是Visual Studio。
相对于Windows和Office等软件3年的更新周期来说,Visual Studio的版本更新速度要稍快一些,为两年左右。这两年通常会被分成若干个阶段,其中软件的规划和设计工作要占到4到6个月,之后是6到8周的代码编写和为期4个月的测试阶段,接下来如果出现较大的需求变更,就需要6到8周的时间来进行第二轮的代码编写和4个月的第二轮测试,如果无需大的调整,则进入到4个月的稳定期直到产品最终发布。
从中不难看出,即便在需求发生变更的情况下,软件代码的编写时间也不过只有4个月,而软件测试阶段所需的时间却是代码编写的两倍左右,多少有些本末倒置。
其实微软的组织结构也符合瀑布式开发模式的要求,其在软件开发项目中主要有三个角色,分别是负责功能说明和设计的项目经理、负责代码编写的开发人员以及负责功能实现的质保人员,这三个角色在管理架构上属于平级,三方相互合作和制约来完成一个软件项目的开发。
上 述的这种开发流程和架构看似很是严谨,但操作起来却不甚理想。举例来说,当某个用户安装了Visual Studio的Beta版本并进行了1个月的测试之后发现并提交了其中的一个Bug,而此时对于开发人员来说,是应该对这个Bug进行修复的,但由于此时 软件的开发已经进入尾声,所以如果这个Bug比较严重的话,可能就只能到下一个版本的开发阶段再对其进行修复,这显然会影响该软件的最终质量。
敏捷开发模式
络的逐渐兴起开始对软件交付模式产生巨大影响,用户是在体验某款软件时无需再将其安装到本地计算机上,只需访问某个 站就能够体验到具体的外观和功能,这对于软件测试来说无疑是非常方便的。也正是在这个时候,“敏捷开发”模式开始出现在软件开发领域之中。
Visual Studio 2010是首个因敏捷开发模式而受益的Visual Studio版本,该软件发布于2010年4月,当时同样耗费了两年的时间完成开发,但随后研发团队就发现软件中的许多模板对于敏捷开发者来说太过笼统, 几乎没有太大的实际意义。针对这种情况,微软的研发部门推出了鼎鼎大名的Team Foundation Server(TFS),这个功能强大的服务器平台能为微软的产品提供源代码管理、数据收集、定义工作流程和管理项目进度等,而微软的软件研发策略也就从 此开始发生巨大变化,以往两到三年的产品更新周期逐渐变得更短,软件开发的流程也变得更加灵活高效,而敏捷开发模式也开始在微软内部流行开来
尽 管敏捷开发模式已被证明是非常高效的软件开发模式,但在微软这种规模庞大的公司中推行起来还是颇为困难的,微软拥有大量的软件开发者,其中仅研发部门的员 工就在3000人以上,同时还有数百个研发团队,所以要想让大家从早已习以为常的瀑布式开发模式转换为敏捷开发模式,其难度不亚于“壮士断腕”。
然 而,微软的管理层已经意识到敏捷开发模式对于公司未来发展的重要性,于是开始积极地制定各种措施来推动这一模式在各个研发团队进行普及,其中包括知识培 训、改变研发团队组织结构、建立新的层级汇 机制等等,这都在一定程度上盘活了微软内部的研发资源,明显提升了产品的研发进度。以Visual Studio为例,目前的版本更新速度已经缩短至一个季度左右,这在瀑布式开发模式下是难以想象的。
“保守”的微软Office
Office应该算是微软最为传统的应用软件了,由于该软件拥有非常广泛的用户群,所以微软在Office的开发策略上相对比较保守,而Office用户也大多不喜欢比较频繁的版本更新,因为这样可能会打乱他们既有的工作流程。

但是,微软另辟蹊径地鼓励用户转向Office 365订阅服务,该服务为用户提供定期的版本更新以及新的功能。同时,微软的iPad版Office团队在进行产品研发时也采用了敏捷开发模式,通过定期产品迭代来为用户带来更棒的使用体验。
就 目前情况而言,微软是否会将敏捷开发模式应用到桌面版Office的研发中还不确定,但至少微软已经主动进行了若干尝试,虽然公司并未改变Office为 期3年的产品更新周期,但微软也承认如今的用户期待获得更多的功能,所以未来微软会通过其他方式来满足用户的需求。由此不难看出,一旦微软发现敏捷开发模 式能够为用户带来更棒的使用体验的话,那么完全有可能在未来数年内抛弃瀑布式开发模式。
结语
对于微软的用户来说,敏捷开发模式为Visual Studio的开发而带来的改进是显而易见的,每隔数月该产品就能进行一些版本更新( 络版的更新速度更快),这无疑将会吸引更多的开发者积极加入到Visual Studio的阵营中来,从而实现良性循环。
而微软也在内部大力推动敏捷开发模式的进展,毕竟这种模式明显提升了软件项目研发的速度和质量,同时该模式所带来的优质体验也让用户变得更加忠诚,所以我们有理由相信敏捷开发模式未来将会在微软逐渐普及,并推动这家软件巨头打造出更为优秀的应用软件。
相关资源:c#编写的鸡兔同笼程序
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!