微软高管亲述五年转型心路历程

“今天想跟大家讲一个比较励志的故事，给大家分享一下我们这五年来的心路历程和一个真正转型的过程。”微软全球开发平台事业部的资深副总裁潘正磊在北京举办的 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