時間：2018-01-06 來源：互聯網 瀏覽量：
“今天想跟大家講一個比較勵誌的故事，給大家分享一下我們這五年來的心路曆程和一個真正轉型的過程。”微軟全球開發平台事業部的資深副總裁潘正磊在北京舉辦的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這樣數千人的開發團隊，必須要以標準化和自動化的工具來統一團隊的流程，再加上企業文化和產品架構的同時轉型，才有了今天的新微軟。
