“今天想跟大家讲一个比较励志的故事，给大家分享一下我们这五年来的心路历程和一个真正转型的过程。”微软全球开发平台事业部的资深副总裁潘正磊在北京举办的微软技术暨生态大会的分论坛上如是说道。
自年成立以来，微软就以Windows和Office而闻名于世，但微软真正的灵魂却是它的开发工具，年微软成立后的第一个产品就是为Altair微机开发的编程语言BASIC，年又发布了著名的开发工具VisualStudio。在PC时代，微软最为成功的就是开发语言、开发工具和开发者生态，而微软的软件开发方法论也成为了商用软件开发的主流。
进入云计算和移动计算时代，微软的开发体系和开发方式都发生了巨变。VisualStudio在过去15年，一直是整个Windows开发的基础，随着Windows、Office等从商用套装软件走向按订阅方式计费的云服务，VisualStudio也跟随着经历了重大转型。
投资内部统一的工具
（微软开发平台事业部全球资深副总裁潘正磊）
早期的VisualStudio遵循微软传统的“瀑布型”开发模式，从产品开发、发布到维护需要三年的时间。当时微软的软件发布工作是完全手工方式，由几位工程师花差不多五周的时间，才能将所有不同的配置、包括多种语言的版本，全部都放到微软和其它相关的网站上供下载。但从年开始，微软意识到随着互联网的不断发展，用户的需求不断改变，为了适应这种快速变化，微软决定从VisualStudio开始，改为每个季度推出一次更新。
潘正磊说，当时将这一思路展示给团队之后，遭遇了很大的阻力。“老实话说，我们一开始把这个思路，拿去跟下面很资深的总监讨论的时候，是有很多阻力的，因为从来没有做过这件事情。你怎么样把一个三年的开发和发布的过程缩短到三个月？这对每一个开发组、每一个工程师，都是非常大的挑战。”
通常，构建一个新的VisualStudio需要96个小时，而对软件进行模拟用户行为的测试则需要长达一个月的时间，并且在产品交付测试之前，需要反复构建以保证程序的稳定性，那么三个月的时间内可反复构建VisualStudio的次数就很有限。想要在三个月的时间内完善程序、测试并交付，挑战无疑是巨大的。
为此，VisualStudio团队内部从年开始全面推行敏捷开发模式，这种开发模式要求团队在每个新功能嵌入主程序之前，就要做到高质量并得到用户的认可，从而提升整个VisualStudio软件的开发速度。而不是在开发了一个新功能之后，再花一大堆时间找Bug，然后再在发布前把Bug解决掉。
在VisualStudio实现多次版本更新之后，VisualStudio团队从软件工程体系入手，进一步加速版本迭代。VisualStudio团队有几千工程师，虽然每个小组都在采用敏捷开发方式，但每个组都是自行设定冲刺时间，并没有统一规定。有的组是两周、有的组是四周或五周，每个组都有自己的算法，但由于各小组之间的功能相互依赖，因此当时就出现了“鸡同鸭讲”的局面：不同的小组在互相沟通时，都需要根据对方的时间点再重新算一遍自己的开发时间。
因此在开发VisualStudio的过程中，VisualStudio团队引入了三周冲刺快速迭代模式。这种模式规定每个小组每三周完成一个冲刺计划，并将结果进行一次内部发布，以保证整个团队高效、统一的开发步调。而对于每个小组的每一次内部发布，其他小组就会直接使用这些未测试的功能进行工作，新功能中许多严重的bug能够直接在内部快速解决，这种在微软内部称为“吃狗食”的机制也保证了新功能在最终发布时的稳定性。
除了统一开发进度之外，VisualStudio团队也会在每轮三周冲刺的开始提交冲刺计划，并在三周之后提交完成报告，以展示最终完成的工作。这套高效的迭代机制不仅能够帮助团队中的各个小组互相了解相互之间的进度，还能协助领导层了解工程整体的开发进度。
除了通过内部的机制转变以强化开发速度和质量，VisualStudio的开发过程还集成了用户反馈机制，以帮助团队了解用户需求。不仅如此，VisualStudio团队内部的反馈门户还会收集来自软件、调研表、UserVoice网站以及更多第三方网站的数据，为VisualStudio团队提供一站式用户反馈门户。而所收集的不仅有对VisualStudio产品的反馈，也有在不同国家和地区的使用问题与体验等的反馈。
开发VisualStudio过程的另一大转变就是对测试环节的改进。以往的VisualStudio版本都会进行黑盒测试，这种测试不仅非常耗时，同时也不透明。所谓黑盒测试，就是模拟用户点击微软产品的测试，因为微软的产品要涵盖几百万用户、支持十多种不同的地方语言，而且还要跑在不同版本的Windows、Office等之上，所以需要耗时耗力的黑盒测试，才能把所有的场景都跑一遍。
VisualStudio团队内部开始鼓励工程师采用单元测试和功能测试，也称为白盒测试。所谓白盒测试，就是测试工程师直接了解开发工程师的想法，想用什么的功能来实现什么样的愿景或用户场景，可能还会要求开发工程师另外开发内部API以供测试工程师做测试。白盒测试的方式，大幅提升了测试工程师与开发工程师的沟通效率。
通过引入统一的生产工具、开发流程和用户反馈机制，加上对测试流程的优化，VisualStudio的构建时间从96小时优化到了24小时，这样就能在一天之内跑完一个构建。
“所以，如果现在反过来看我们当时在做的工作，实际上是投资了很多内部的工具，因为提升整个团队的效率，需要统一的工具，不管是做构建还是让团队互相之间知道进度、如何用同样的语言来描述代码何时候完成等等。在没有统一化之前，感觉好像去了没有欧盟之前的欧洲国家，每个国家都有不同的货币、不同的语言，都要进行一番兑换。我们觉得为了提高内部生产力，一个统一的工具还是非常重要的。”
拥抱客户、重新定义成功
VisualStudio团队当时还遇到了一个痛点：在三年一个版本的年代，是没有软件更新一说的。这就好像购买了一整套百科全书，过五年再购买一套更新版本的百科全书，原来购买的百科全书就全套弃掉；而不能做到其中的某个章节不要，或增加一个新的章节。之前的VisualStudio软件版本更新与百科全书的更新是一个方式，但在敏捷开发时代却要求更加灵活地更新某个功能而保留其余的功能，于是组件化就提上了日程。
VisualStudio团队一开始尝试组件化就失败了。当时让一个内部开发小组尝试了6个月，却一直没有做出来。为什么？“是因为我们一开始没有想清楚，这个组件到底应该多大，什么功能可以变成一个组件，在什么范围内变成一个组件，我们当时没想清楚。结果，一开始把组件做的太小了，就变成整个产品有很多组件，变成没有办法管理了。”
“学习了第一次的经验和教训，我们当时的思路改为要以‘客户为上’，也就是说如果客户认为这几个功能是一套功能的话，那在做版本更新的时候，一般这一套功能是要一起更新的。而一般需要同步更新的一套功能，我们做把它做成一个组件。”潘正磊回忆道。
那么，谁是VisualStudio的客户呢？在年、年的时候，微软还仅把在Windows上面做微软应用开发的程序员定义为客户，这是一个相对来说比较狭窄的定义。在年，微软当时一个非常大的战略改变就是要拥抱开源。于是，VisualStudio团队决定要支持移动开发，而移动开发就一定要涉及iOS和Android开发，因此开源程序员也成为了VisualStudio的客户。VisualStudio软件的构建与发布系统进行了彻底的改造，让软件适应MacOS和Linux等，同时软件工具链也开始支持诸如git等开源产品。
于是，在针对VisualStudio的开发中，开发团队正式引入产品组件化和OOB（out-of-band）机制。程序的组件化意味着开发团队能够以组件为单位，实现快速迭代；OOB机制则允许用户在对VisualStudio进行更新时只更新单一组件，而无需更新全部内容。这些机制的引入不仅加速了团队的开发进度，同时也提升了用户体验。
在VisualStudio推出后，潘正磊还有一个反思，就是如何帮助客户成功。以前微软发布完软件版本后，就不再白癜风怎么引起的原因白殿疯病正常生长在哪里
转载请注明地址:http://www.yujinxiangqiangzhi.com/rjgc/rjgc/10384.html
