微软高管亲述五年转型心路历程
“今天想跟大家讲一个比较励志的故事，给大家分享一下我们这五年来的心路历程和一个真正转型的过程。”微软全球开发平台事业部的资深副总裁潘正磊在北京举办的2017微软技术暨生态大会的分论坛上如是说道。
自1975年成立以来，微软就以Windows和Office而闻名于世，但微软真正的灵魂却是它的开发工具，1975年微软成立后的第一个产品就是为Altair 8800微机开发的编程语言BASIC，1997年又发布了著名的开发工具Visual Studio。在PC时代，微软最为成功的就是开发语言、开发工具和开发者生态，而微软的软件开发方法论也成为了商用软件开发的主流。
进入云计算和移动计算时代，微软的开发体系和开发方式都发生了巨变。Visual Studio在过去15年，一直是整个Windows开发的基础，随着Windows、Office等从商用套装软件走向按订阅方式计费的云服务，Visual Studio也跟随着经历了重大转型。
投资内部统一的工具
早期的Visual Studio遵循微软传统的“瀑布型”开发模式，从产品开发、发布到维护需要三年的时间。当时微软的软件发布工作是完全手工方式，由几位工程师花差不多五周的时间，才能将所有不同的配置、包括多种语言的版本，全部都放到微软和其它相关的网站上供下载。但从2012年开始，微软意识到随着互联网的不断发展，用户的需求不断改变，为了适应这种快速变化，微软决定从Visual Studio 2012开始，改为每个季度推出一次更新。
潘正磊说，当时将这一思路展示给团队之后，遭遇了很大的阻力。“老实话说，我们一开始把这个思路，拿去跟下面很资深的总监讨论的时候，是有很多阻力的，因为从来没有做过这件事情。你怎么样把一个三年的开发和发布的过程缩短到三个月？这对每一个开发组、每一个工程师，都是非常大的挑战。”
通常，构建一个新的Visual Studio需要96个小时，而对软件进行模拟用户行为的测试则需要长达一个月的时间，并且在产品交付测试之前，需要反复构建以保证程序的稳定性，那么三个月的时间内可反复构建Visual Studio的次数就很有限。想要在三个月的时间内完善程序、测试并交付，挑战无疑是巨大的。
为此，Visual Studio团队内部从2012年开始全面推行敏捷开发模式，这种开发模式要求团队在每个新功能嵌入主程序之前，就要做到高质量并得到用户的认可，从而提升整个Visual Studio软件的开发速度。而不是在开发了一个新功能之后，再花一大堆时间找Bug，然后再在发布前把Bug解决掉。
在Visual Studio 2012实现多次版本更新之后，Visual Studio团队从软件工程体系入手，进一步加速版本迭代。Visual Studio团队有几千工程师，虽然每个小组都在采用敏捷开发方式，但每个组都是自行设定冲刺时间，并没有统一规定。有的组是两周、有的组是四周或五周，每个组都有自己的算法，但由于各小组之间的功能相互依赖，因此当时就出现了“鸡同鸭讲”的局面：不同的小组在互相沟通时，都需要根据对方的时间点再重新算一遍自己的开发时间。
因此在开发Visual Studio 2013的过程中，Visual Studio团队引入了三周冲刺快速迭代模式。这种模式规定每个小组每三周完成一个冲刺计划，并将结果进行一次内部发布，以保证整个团队高效、统一的开发步调。而对于每个小组的每一次内部发布，其他小组就会直接使用这些未测试的功能进行工作，新功能中许多严重的bug能够直接在内部快速解决，这种在微软内部称为“吃狗食”的机制也保证了新功能在最终发布时的稳定性。
除了统一开发进度之外，Visual Studio团队也会在每轮三周冲刺的开始提交冲刺计划，并在三周之后提交完成报告，以展示最终完成的工作。这套高效的迭代机制不仅能够帮助团队中的各个小组互相了解相互之间的进度，还能协助领导层了解工程整体的开发进度。
除了通过内部的机制转变以强化开发速度和质量，Visual Studio 2013的开发过程还集成了用户反馈机制，以帮助团队了解用户需求。不仅如此，Visual Studio团队内部的反馈门户还会收集来自软件、调研表、UserVoice网站以及更多第三方网站的数据，为Visual Studio团队提供一站式用户反馈门户。而所收集的不仅有对Visual Studio产品的反馈，也有在不同国家和地区的使用问题与体验等的反馈。
开发Visual Studio 2013过程的另一大转变就是对测试环节的改进。以往的Visual Studio版本都会进行黑盒测试，这种测试不仅非常耗时，同时也不透明。所谓黑盒测试，就是模拟用户点击微软产品的测试，因为微软的产品要涵盖几百万用户、支持十多种不同的地方语言，而且还要跑在不同版本的Windows、Office等之上，所以需要耗时耗力的黑盒测试，才能把所有的场景都跑一遍。
Visual Studio团队内部开始鼓励工程师采用单元测试和功能测试，也称为白盒测试。所谓白盒测试，就是测试工程师直接了解开发工程师的想法，想用什么的功能来实现什么样的愿景或用户场景，可能还会要求开发工程师另外开发内部API以供测试工程师做测试。白盒测试的方式，大幅提升了测试工程师与开发工程师的沟通效率。
通过引入统一的生产工具、开发流程和用户反馈机制，加上对测试流程的优化，Visual Studio 2013的构建时间从96小时优化到了24小时，这样就能在一天之内跑完一个构建。
“所以，如果现在反过来看我们当时在2013做的工作，实际上是投资了很多内部的工具，因为提升整个团队的效率，需要统一的工具，不管是做构建还是让团队互相之间知道进度、如何用同样的语言来描述代码何时候完成等等。在没有统一化之前，感觉好像去了没有欧盟之前的欧洲国家，每个国家都有不同的货币、不同的语言，都要进行一番兑换。我们觉得为了提高内部生产力，一个统一的工具还是非常重要的。”
拥抱客户、重新定义成功
Visual Studio团队当时还遇到了一个痛点：在三年一个版本的年代，是没有软件更新一说的。这就好像购买了一整套百科全书，过五年再购买一套更新版本的百科全书，原来购买的百科全书就全套弃掉；而不能做到其中的某个章节不要，或增加一个新的章节。之前的Visual Studio软件版本更新与百科全书的更新是一个方式，但在敏捷开发时代却要求更加灵活地更新某个功能而保留其余的功能，于是组件化就提上了日程。
Visual Studio团队一开始尝试组件化就失败了。当时让一个内部开发小组尝试了6个月，却一直没有做出来。为什么？“是因为我们一开始没有想清楚，这个组件到底应该多大，什么功能可以变成一个组件，在什么范围内变成一个组件，我们当时没想清楚。结果，一开始把组件做的太小了，就变成整个产品有很多组件，变成没有办法管理了。”
“学习了第一次的经验和教训，我们当时的思路改为要以‘客户为上’，也就是说如果客户认为这几个功能是一套功能的话，那在做版本更新的时候，一般这一套功能是要一起更新的。而一般需要同步更新的一套功能，我们做把它做成一个组件。”潘正磊回忆道。
那么，谁是Visual Studio的客户呢？在2012年、2013年的时候，微软还仅把在Windows上面做微软应用开发的程序员定义为客户，这是一个相对来说比较狭窄的定义。在2015年，微软当时一个非常大的战略改变就是要拥抱开源。于是，Visual Studio团队决定要支持移动开发，而移动开发就一定要涉及iOS和Android开发，因此开源程序员也成为了Visual Studio的客户。Visual Studio软件的构建与发布系统进行了彻底的改造，让软件适应MacOS和Linux等，同时软件工具链也开始支持诸如git等开源产品。
于是，在针对Visual Studio 2015的开发中，开发团队正式引入产品组件化和OOB（out-of-band）机制。程序的组件化意味着开发团队能够以组件为单位，实现快速迭代；OOB机制则允许用户在对Visual Studio进行更新时只更新单一组件，而无需更新全部内容。这些机制的引入不仅加速了团队的开发进度，同时也提升了用户体验。
在Visual Studio 2015推出后，潘正磊还有一个反思，就是如何帮助客户成功。以前微软发布完软件版本后，就不再关注用户是否真正在用其中的某些功能。而潘正磊发现，在产品宣传时所提到的几个很棒的功能，真正的用户数却非常少。因为微软是开发企业级软件，面对数百万的用户，不能因为某个功能的用户数少，就把该功能删掉或不支持。如果仅仅有几千或上万的用户在用某个功能，微软也会一直支持下去，那对于整个软件或微软自身来说都是累赘。为了防止这种现象的发生，就要确保开发出来的功能是用户真正喜欢和开始使用的，这就是“重新定义成功”。
“我跟很多国内外很多企业交流时，在谈到‘定义成功’的时候，都是把成功定义为把软件高质量地交付给用户，用户发现任何问题都能及时解决，并真正把软件的功能用起来，这才是‘做完了’的定义。”潘正磊说。
文化转型更重要
微软开发团队之前有一个非常著名的开发模式：“三驾马车”，即开发人员、测试人员和产品经理组成一个团队，这是PC软件时代最为成功的商用软件开发模式，被很多软件企业效仿。
微软“三驾马车”的后面还有一个文化，就是每一个工程师都有自己独立办公室的“办公室文化”，这已经是微软多年的习惯。但独立的办公室却不便于敏捷开发时代的快速沟通，为此Visual Studio改变了团队文化，第一件事就是把一个功能相关的产品经理、测试工程师、开发工程师都放到一个办公室里，这样达到的效果就是团队的紧密沟通，而不是像以前都关着门，要问一个问题就要去别的办公室找人。而把相关的人员都放在一个办公室，那么敏捷开发的早站会，就能直接在一个房间里开掉了。
另一个改变，是把测试工程师团队和开发工程师团队合并，变成一个工程师团队。这个改变在当时也是非常大的举动，因为微软的开发工程师和测试工程师的职称已经有几十年的历史，在一开始做改变的过程中自然也会遇到非常大的阻力。之后，随着开发的需要，团队中又加入了“数据科学家”这一新的职能，通过收集有效数据帮助整个团队进行更高效地开发。
在开发文化转型方面，Visual Studio团队在2015年还做了一个非常重大的改变。当时从产品战略角度，微软决定拥抱开源，要把最核心.NET技术拿出来开源并且转变成跨平台的框架技术。而在做开源和跨平台中，发现这个过程无法生存在微软内部，而必须要放到外部的开源社区Github上去实现。而放到Github上最大的工作，就是把微软原先的工程化系统，包括软件构建、测试、交付等，都重新写一遍。原来微软的开发都是基于内部的系统，特别是Windows系统，而开源后的微软技术则需要开源社区的工程师能用Linux、MacOS等做贡献，可以构建、编程、测试等，整个工具链的更新在当时是非常重要的工作。
Visual Studio的发布系统也做了重大改造，把之前24小时的构建，缩短到了8小时就可以完成。这是因为对Visual Studio进行组件化和模块化后，在重新构建整个Visual Studio之前，先单独构建每一个模块，最后再“组装”在一起。这样就实现了8小时、一天内多次构建Visual Studio。
所有的产品改进都始于用户需求
通过2013年到2015年的重大变化，“我们学习到的是什么呢？是我们所有的产品改进都开始于用户需求的改进”。
举例来说，微软以前产品出现问题的时候，会以打补丁的方式解决问题，但补丁是一个单独的文件，并不会直接打包到软件的下一个完整更新包里。用户必须在使用的实际过程中踩到“坑”，才会触发打补丁机制。于是，Visual Studio团队改为“Micro update”即微更新的方式，这就意味着更多的发布，这就需要一个新的软件发布流程，把最重要的补丁打到下一个更新包里，而不是几千个工程师把所有的补丁都打到下一个更新包里。这种滚动更新的方式对于提升用户体验来说非常有意义，因为通过几个用户使用发现的问题，可以打包到后面的更新包里，解决了后面用户的体验，这是当时还是盒装软件的情况。
对于Visual Studio这样的盒装或套装软件，微软找到了类似DevOps互联网方式进行敏捷开发运维与管理。这种思维也贯彻到了Visual Studio 2017的开发流程中。在每个版本发布之前，团队内部都会通过Ship Ready工具统计内部在使用时的安装成功率、程序崩溃的比率以及已经修复的问题。依靠这些数据，领导层能够快速决定当前版本是否能够发布，工程师们也能够清晰了解当前最关键工作是修复bug，还是继续新功能的开发。“我们现在做很多决策，完全是靠数据来决策，是数据驱动的方式，从而让团队知道什么工作需要优先、什么工作最重要。”
Visual Studio团队向“用户至上”的文化转型，相当的不容易，也遭遇了团队的抵触。微软以前是工程师文化，在打造新的企业文化的过程，就要关注价值观、行为准则以及优先级设定。如果以“用户为上”为价值观，那么几千人的团队在设定各自工作优先级的时候，就要把用户需求放在第一位。而过去微软工程师的行为方式或定义自己成功的方式，是以在产品演示中增加了一个很酷的新功能为代表；但在“用户为上”的前提下，则要把新功能的开发放在一边，而要优先解决客户发现的问题并进行修复。
“工程师不会自然地这么做，而要重新设立新的鼓励机制，才能帮助工程师重新设定工作的优先级，真正落实‘用户至上’的理念。”以Visual Studio for Python版本为例，当时Visual Studio团队收到Python版本的间歇性崩溃，同时也有用户通过Github把这个问题汇报给Vistual Studio团队。从微软内部的监控系统，可以发现这个崩溃虽然出现了1400多次，但只涉及整个Visual Studio用户的0.004%。虽然对于整体Visual Studio用户的影响并不大，但对于Python开发者的影响却很大，从这个角度来说就急需为Python开发者修复这一问题。
另外，作为一款企业级软件，Visual Studio的开发团队一直在内部使用最新的版本，但所试用的功能可能跟对外发布的产品并不完全一样，而Visual Studio开发团队也可能用不到所有的功能，这就需要鼓励客户和社区能够帮助Visual Studio的开发团队一起在版本发布之前找到更多的Bug。特别是虽然在内部做了足够多的测试，但软件一旦对外发布后，在实际的生产环境中永远会有新的问题，而这些问题在内部测试环境中是无法发现的。
那么，如何解决这一挑战呢？首先，Visual Studio 2017允许用户在一台设备上同时安装预览版和稳定版，通过这一全新的安装机制，以保障用户的使用体验和生产力。实际上很多用户都愿意帮助Visual Studio团队做软件测试，但过去不允许在同一台设备上安装两个版本，那么一旦预览版本里有很严重的问题，就无法完成用户手头的工作。新的安装机制，是一种很重要的策略，但为了实现这一策略，也要对Visual Studio产品架构和产品本身做重大的改变和更新，这对于微软来说就是一笔重大的投资。
另一方面，从Visual Studio 2015开始，为了同时满足不同开发者的需求，而在一个版本里提供了非常多的功能，但实际上没有任何一个开发工程师会同时有这么多的需求，很少会出现同一工程师同时做桌面开发、游戏开发、移动开发、数据库开发等这么多工作。那么在原来三年一次更新的前提下，要求在一台设备上安装所有的功能，现在却是一个模块需要经常更新，如果不常用的话，则对机器和开发者都造成不好的影响与体验。微软也相应投资了一整套新的下载安装机制，允许用户首次安装时只勾选自己所需要的组件，从而省去不必要的安装时间和硬盘空间的浪费。
再一个例子是在2017年3月Visual Studio 2017版本发布后的安装成功率进行监测时，发现美国市场的成功率为91%，而中国市场的成功率只有50%多。仔细检查下来，发现原来是安装包越大，在遇到防火墻的时候越容易被弹回，下载失败的可能性越大。经过详细的数据分析，Visual Studio把安装包拆解成一个一个的小包，再用技术保障在中国市场安装的成功率。当然，这种监测能力也是在Visual Studio 2017版本中才加入进去，因为Visual Studio 2017已经接近互联网服务。而到了2017年7月，实时监测发现中国地区的下载失败率飙升，团队通过工具检测发现是北京地区出现了问题，再仔细检测发现是北京地区互联网服务供应商的缓存出了问题，于是通过直接沟通很快就解决了问题，整个花了不到12个小时。
推动转型的“三驾马车”
在总结微软向DevOps转型的方法论时，潘正磊表示DevOps是企业文化、工具与流程，以及产品架构同时进行转型，三者需要齐头并进、缺一不可，这样才能真正推动向DevOps的转型，“单推一个是推不动的”。
首先，要树立“用户至上”以及成长型思维（Growth Mindset）。在成长型思维方面，要认识到不能一次性解决所有的问题，像Visual Studio一开始做组件化和模块化就失败了，而有的功能做到了第四个版本才可能比较好用，所以这是一个迭代和试错的过程、是一个小步快跑的过程。因为只有通过试验，才能知道什么是对的、什么是错的，如果不试验就永远不知道，“不能用经验来代替试验”，这是潘正磊经常说的一句话。
再有就是要减少技术“债务”，每次工程师的交付都要求是高质量的交付，不要把前面的问题留给后面解决。另外就是持续交付，测试环境中的改变，必须要在生产环境中发生，才是真正的改变。因为只有在真正的生产环境中，才能拿到真实的数据和反馈。
其次是要为团队提供标准化的工具。比如，重视用户反馈很重要，但如何在众多的用户反馈中区分出哪个到底是真正有价值的反馈、哪个能够带来后续可执行的改变、提交的问题是否已经提交并修复过、出现的问题到底根源在哪里等等。一开始，Visual Studio团队尝试让用户送笑脸和哭脸的方式进行反馈，但对于团队来说这样的反馈很模糊，就算想要帮助用户解决问题，也不知道问题在哪、如何下手、不同问题的优先级到底如何等等。
Visual Studio团队把所有用户反馈的问题都放到了开发者社区网站上，再通过机器学习的方式对类似的问题进行归类，而且对新提交的问题也会提醒是否是其他用户已经提交过。对于已经提交的问题，会通过机器学习的方式进行打分，以设置不同问题的优先级，哪个比较着急、哪个可以缓一缓。如果有很多用户都提交或反馈过同一个问题，那么就可以帮助Visual Studio团队优化这个问题的优先级。因此，Visual Studio团队有一套单独的工具，专门用于分析和处理用户的反馈，到了Visual Studio 2017则直接集成到工作流程里。
此外，Visual Studio 2017的构建时间已经缩短为4小时，这样一天可能做多次构建、测试和部署，而当每天的快速部署成为常态时，自动化就成为了团队内部的诉求，因为不可能用人工的方式去发布每一个模块的更新。为此Visual Studio团队开发了VSTS（Visual Studio Team Services）开发计划，将组件的发布和管理集成在同一系统中，自动完成每一次软件发布的质量监控、生产部署、批准记录等，大幅缩短了Visual Studio的发布时间。
而在团队文化转型方面，当给团队设立一个目标后，就要让团队有一种主人公精神，能够真正解决问题、推动进步，而这也需要工具的配合。工具要能够提供用户洞察，让团队真正知道问题在哪里、是什么。其次要让团队能够在生产环境中找问题，而不能用测试环境代替生产环境，提供的工具必须要能够在生产环境中又快又稳的找到问题。第三就全面自动化，不论是测试还是发布，都要全面自动化。第四是质量前移，原来是先把功能全部写完，之后再看质量是否有问题，现在是希望团队在编写代码的时候，就能够尽快知道在生产环境中碰到的问题。
当然，产品架构的转型也非常重要，要将产品模块化或微服务化，利用DevOps实现产品快速迭代。否则，像Visual Studio这样庞大的产品，是无法实现一天多次迭代的。
回顾Visual Studio开发团队的转型，是微软实现数字化转型成功的关键。利用DevOps方法论、以用户为主导，实现产品的快速迭代、持续为用户提供高质量的交付，是Visual Studio成功转型的关键所在。
而从过去五年的转型过程来看，“用户至上”、“以用户为核心”是整个微软转型成功的“真经”，DevOps并非神话而是围绕用户需求不断修改和修正，再通过用户反馈“快速试错、小步快跑”。然后就是大幅提高企业运营的自动化比率，特别是像微软Visual Studio这样数千人的开发团队，必须要以标准化和自动化的工具来统一团队的流程，再加上企业文化和产品架构的同时转型，才有了今天的新微软。
