长久以来，身为“软件开发商”的微软的名声并不太好，倒不是人们对微软的软件产品不满意，而是其更新周期太过漫长，比如Office、Windows、SQL Server和Exchange等主打产品的更新周期都长达3年左右，这其中的主要原因就是微软在软件项目的开发中采用了瀑布式开发模式。但随着用户对软 件的需求越来越苛刻，瀑布式开发模式已经难以满足新型软件的开发要求，而微软也不得不改变自己的软件研发策略。
国外科技媒体Arstechnica日前发文对微软软件研发策略的转变之路进行了分析。
以下是文章的主要内容：
在 大部分人的印象里，微软的新版本软件好像很少按照既定时间发布（Windows 95、Windows 2000和Windows Vista均延期发布），而微软本身也很少就软件延期发布正式的官方声明，所以此时关于微软的各种传闻、假设和猜测似乎已经成了惯例。尽管如此，微软仍然 取得了巨大的成功，因为许多竞争对手的情况也大同小异，大家针对付费软件的更新速度都比较慢，所以微软也就显得没有那么突兀了。
瀑布式开发模式
客 观地讲，延期发布在大型软件项目的开发中非常普遍，毕竟这其中充满了各种未知的复杂因素，而目前尚未出现一套行之有效的方法来对此进行管理，所以许多软件 项目最终都很难在既定的时间和预算内完成开发。针对这种情况，许多计算机领域的科学家和工程师尝试了多种正规化的方法来改善软件开发的流程，这其中就包括 微软和大部分软件企业普遍使用的瀑布式开发模式。
瀑布式开发模式将软件开发的过程分为系统计划、需求分析、系统设计、系统编码、系统测试、系统运行和维护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比较严重的话，可能就只能到下一个版本的开发阶段再对其进行修复，这显然会影响该软件的最终质量。
敏捷开发模式
网络的逐渐兴起开始对软件交付模式产生巨大影响，用户是在体验某款软件时无需再将其安装到本地计算机上，只需访问某个网站就能够体验到具体的外观和功能，这对于软件测试来说无疑是非常方便的。也正是在这个时候，“敏捷开发”模式开始出现在软件开发领域之中。
“敏 捷开发”一词最早出现在上世纪的90年代，并在2001年被正式定名，当时一组开发人员公布了所谓的“敏捷开发宣言”：“个体和交互胜过过程和工具、可以 工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划、虽然右边的项也具有价值，但我们认为左边的项具有更大的价值。”
简 单的说，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测 试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
很显然，敏捷开发与瀑布式开发有着质的区别，前者采用了“迭代式”的开发模式，事先并不先入为主地确定用户的需求，而是先做一些原型试验品来让那些关键用户去体验，然后再根据用户的反馈意见不断做修改和调整。在整个研发流程中，产品的最初设想和最终设计往往是不相同的。
敏捷开发模式在微软的应用
微 软的Visual Studio团队是公司内部首个采用敏捷开发模式的研发团队，尽管最初微软内部仍然以使用瀑布式开发模式，但由于Visual Studio的第三方开发者强烈要求使用敏捷开发模式，所以微软的研发部门不得不做出改变，这也为敏捷开发模式在Visual Studio中的应用铺平了道路。
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的阵营中来，从而实现良性循环。
而微软也在内部大力推动敏捷开发模式的进展，毕竟这种模式明显提升了软件项目研发的速度和质量，同时该模式所带来的优质体验也让用户变得更加忠诚，所以我们有理由相信敏捷开发模式未来将会在微软逐渐普及，并推动这家软件巨头打造出更为优秀的应用软件。
