长期以来，微软作为“软件开发商”的名声并不好。并不是人们对微软的软件产品不满意，而是它的更新周期太长了。例如，Office、Windows、SQLServer、Exchange等旗舰产品的更新周期长达3年左右。造成这种情况的主要原因是微软在软件项目的开发中采用了瀑布式开发模式。但是，随着用户对软件的要求越来越苛刻，瀑布式开发模式已经难以满足新软件的开发需求，微软不得不改变其软件开发策略。国外科技媒体Arstechnica近日发表文章分析微软软件研发战略的转变。以下为文章主要内容：在大多数人的印象中，微软的新版软件似乎很少按预定的时间发布（Windows95、Windows2000和WindowsVista都推迟了），而微软自己也很少推迟发布软件正式的官方声明发布，所以此时关于微软的各种传闻、假设和猜测似乎已经成为常态。尽管如此，微软还是取得了巨大的成功，而且由于其许多竞争对手更新付费软件的速度同样缓慢，因此微软似乎不那么突兀。瀑布式开发模型客观地说，延迟发布在大型软件项目的开发中是非常普遍的。毕竟充满了各种未知的复杂因素，又没有有效的方法去管理，所以很多软件项目最终都难以在预算内按时完成。针对这种情况，计算机领域的许多科学家和工程师尝试了多种形式化的方法来改进软件开发过程，其中就包括微软和大多数软件公司普遍采用的瀑布开发模式。瀑布开发模型将软件开发过程分为六个阶段：系统规划、需求分析、系统设计、系统编码、系统测试、系统运维。每个阶段的完成是下一阶段工作的前提。每个阶段都要进行严格的审核，确保每个阶段的工作都做好了，才能进入下一阶段。瀑布式开发模式自1970年代正式命名以来一直存在争议。虽然很多公司在软件开发中都采用这种模式，但是并没有得到业界的广泛认可。相反，业内人士很多。模型是软件开发延迟或失败的主要原因。尽管如此，瀑布式开发模式在今天仍然广泛应用于制造业和建筑业，因为这两个行业的大部分项目进度是不可逆的，所以使用这种略显死板的模式可以避免一些不合理的问题。必要的费用。相比之下，后期修改一个软件项目的成本，比盖楼要简单的多。同时，软件开发过程中的不确定因素较多，因此很多软件项目往往在开发到一定阶段后就结束了。然后修改需求，这显然是有悖于瀑布开发模式的理念的。瀑布开发模式在微软的应用虽然微软在软件开发中并没有使用纯粹意义上的瀑布开发模式（有些开发流程是重复的），但总体来说还是使用瀑布开发流程。代表作品之一是VisualStudio。与Windows、Office等软件3年的更新周期相比，VisualStudio的版本更新速度略快一些，大约为两年。这两年通常分为几个阶段，其中软件的规划和设计需要4到6个月，然后是6到8周的编码和4个月的测试阶段。对于重大的需求变更，第二轮代码编写需要6到8周，第二轮测试需要4个月。如果不需要大的调整，会进入4个月的稳定期，直到产品最终发布。不难看出，即使在需求发生变化的情况下，软件代码的编写时间也只有4个月，而软件测试阶段所需的时间是代码编写时间的两倍左右，有点把本末倒置。事实上，微软的组织结构也符合瀑布开发模式的要求。它在软件开发项目中主要扮演三个角色，即负责功能描述和设计的项目经理、负责代码编写的开发人员和负责功能实现的质量保证人员。这三个角色在管理结构上属于同一层次，三者相互配合，相互制约，共同完成一个软件项目的开发。上述的开发流程和架构看似很严谨，但运行起来并不理想。例如，当用户安装了VisualStudioBeta版本并进行了一个月的测试时，他发现并提交了一个bug，此时，开发人员应该修复该bug，但是由于软件的开发已经到了此时结束，如果bug严重，可能只能在下一个版本的开发阶段修复，显然会影响软件的最终质量。敏捷开发模型网络的逐渐兴起，开始对软件交付模型产生巨大的影响。当用户体验到某个软件时，他们不再需要在本地电脑上安装它。他们只需访问某个网站即可体验特定的外观和功能。这对于软件测试来说无疑是非常方便的。也正是在这个时候，“敏捷开发”模式开始出现在软件开发领域。“敏捷开发”一词最早出现于1990年代，并于2001年正式命名，当时一群开发人员发表了所谓的“敏捷开发宣言”：“个体和交互胜过过程和工具，能工作的软件胜于综合性文档、客户协作优于合同谈判，响应变化优于遵循计划，虽然右边的项目有价值，但我们认为左边的项目更有价值。”简单的说，敏捷开发是一种以用户需求的演化为中心，迭代的、循序渐进的开发方式。经测试具有集成运行的特点，换句话说，就是将一个大项目拆分成多个相互关联又可以独立运行的小项目，分别完成，软件始终处于可用状态很明显，敏捷开发和瀑布开发有质的区别，前者采用“迭代式”的开发模式，不预先预想用户的需求，而是先做一些原型给那些关键用户体验.，然后根据用户的反馈不断进行修改和调整。在整个研发过程中，一个产品的最初设想和最终设计往往是不同的。敏捷开发模式在微软的应用微软的VisualStudio团队是公司第一个采用敏捷开发模式的研发团队。敏捷开发模式，让微软的研发部门不得不做出改变，这也为敏捷开发模式在VisualStudio中的应用铺平了道路。VisualStudio2010是第一个受益于敏捷开发模型的VisualStudio版本。该软件于2010年4月发布，同样耗时两年才完成开发，但后来研发团队发现软件中的很多模板都不是敏捷开发人员通用的，没有太大的实际意义。针对这种情况，微软的研发部门推出了大名鼎鼎的TeamFoundationServer（TFS），这是一个强大的服务器平台，可以为微软产品提供源代码管理、数据收集、工作流定义、项目进度管理等功能。此后，微软的软件开发战略发生了翻天覆地的变化。近两三年的产品更新周期逐渐变短，软件开发过程变得更加灵活高效，敏捷开发模式也在微软内部流行起来。虽然敏捷开发模式已被证明是一种非常高效的软件开发模式，但在微软这样的大型公司实施起来却相当困难。微软拥有大量的软件开发人员，仅研发部门的员工就有3000多人，研发团队同时拥有数百人。因此，要让大家从早已习惯的瀑布式开发模式转变为敏捷开发模式，难度犹如“壮士断腕”。不过，微软管理层已经意识到敏捷开发模式对于公司未来发展的重要性，因此开始积极制定各种措施来推动这种模式在各个研发团队中的普及，包括知识培训、改变研发组织架构等。团队、建立新的分级报告机制等，在一定程度上盘活了微软内部的研发资源，显着提升了产品研发进度。以VisualStudio为例，目前的版本更新速度已经缩短到四分之一左右，这在瀑布开发模式下是不可想象的。“保守派”MicrosoftOfficeOffice应该算是微软最传统的应用软件了。由于这款软件拥有非常广泛的用户群，微软在Office的开发策略上相对保守，大多数Office用户不喜欢频繁的版本更新，因为这可能会破坏他们既定的工作流程。不过，微软采取了不同的方式来鼓励用户转向Office365订阅服务，该服务为用户提供定期的版本更新和新功能。同时，微软iPad版Office团队在产品开发上也采用敏捷开发模式，通过定期的产品迭代为用户带来更好的体验。就目前的情况来看，微软是否会将敏捷开发模式应用到桌面版Office的开发中尚不确定，但至少微软已经主动做出了一些尝试。虽然该公司并没有改变Office的三年产品更新周期，但微软也承认，如今的用户期待更多的功能，因此未来微软将采用其他方式来满足用户需求。由此不难看出，一旦微软发现敏捷开发模式能够为用户带来更好的体验，未来几年完全有可能放弃瀑布开发模式。结束语对于微软用户来说，敏捷开发模式给VisualStudio开发带来的提升是显而易见的。产品每隔几个月就可以更新一次（在线版的更新速度更快），这无疑会吸引更多的开发者积极加入VisualStudio阵营，从而实现良性循环。而微软也在内部大力推动敏捷开发模式的进步。毕竟，这种模式极大地提高了软件项目开发的速度和质量。同时，这种模式带来的优质体验也让用户更加忠诚，所以我们有理由相信，未来敏捷开发模式会在微软逐渐流行起来，推动这家软件巨头走向创建更好的应用软件。
