瀑布式开发模式在微软的应用 虽然微软在软件开发中并没有使用纯粹意义上的瀑布式开发模式（部分开发过程有所反复），但总体上来说还是沿用了瀑布式开发流程，其中的一个代表作的就是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为例，目前的版本更新速度已经缩短至一个季度左右，这在瀑布式开发模式下是难以想象的。 |
