微軟千人開發團隊怎麼用Scrum

Visual Studio是微軟最重要的核心開發工具，到去年10月止，全球.NET開發人員近6百萬人，光是VS 2013年版，下載次數就達到7百萬次。參與VS開發的人數超過4,700人，分布在美國、瑞士、中國、印度等地的微軟研發中心。這群人要負責190萬個開發工作項目，完成了近3,600萬個程式碼檔案，累計資料量達到15.3TB。開發團隊平均每個月會組建（Build）22萬多次。

早從2010年時，微軟開發團隊就開始運用開源軟體，但是為了避免軟體產品的程式碼有侵權風險，直到3年前，微軟仍然嚴格禁止開發工程師接觸開源程式碼，連看一下都不行。目前近2千人規模的Visual Studio（簡稱VS）開發團隊，不論是誰，都得經過3道申請程序，上簽到微軟開發平臺負責主管，也就是得到微軟開發平臺事業部全球資深副總裁潘正磊點頭同意才行。

但在微軟宣布擁抱開源，釋出.NET核心程式碼之後，現在，微軟反而鼓勵工程師參與開源社群，任何工程師接觸開源程式碼不需要獲得任何形式的核准，除非要在自家產品內放入開源程式碼，甚至微軟還開始積極招募擅長開源開發的人才。

從看一眼都不行，到現在要能和全球開源社群合作開發，微軟並非一夕之間就有能力跨入開源。過去微軟設計產品只需和內部溝通，現在得和社群合作。開源社群貢獻的程式碼如何和套裝產品整合，也需要新的流程。潘正磊表示，擁抱開源最需要的調整不是組織，而是要改變工作方法。

擁抱敏捷開發是微軟邁向開源的關鍵一步

「過去，微軟開發工作的安排可以是計畫性，但是開源之後，無法預估多少人會有興趣貢獻程式碼。」潘正磊表示：「微軟沒有轉型到敏捷開發，現在就不可能開源。因為無法提供合適的測試、適當的自動化、適當的持續整合機制來確保程式碼的正確性。」擁抱敏捷開發正是微軟能夠邁向開源的關鍵。

早期微軟採用瀑布式開發流程，不論哪一套產品的開發團隊都有各自的瀑布式流程作法，每次要推出一個新版本，往往需要2～3年的時間才能完成。

為了加快產品開發步調，2005年左右，微軟開始在內部推廣敏捷開發模式，2006年擴大訓練Scrum能力，VS開發團隊是率先推廣Scrum的微軟產品團隊，VS也開始支援Scrum。不過，即使微軟開始在內部推廣Scrum，2005年後的3次Visual Studio改版，從VS 2008、VS 2010到VS 2012，仍舊是每隔2～3年才會推出一次大改版。

VS 2012推出後，產品發布策略大轉變

直到2012年版釋出後，VS產品發布策略出現了大轉變。潘正磊表示，微軟做了一個重大決策，要讓開發流程更加敏捷化，來加快產品交付周期。

VS 2012發布後，微軟開始每隔2～4個月就發布一個更新版本，不只修補問題，還會增加新功能。光是從VS 2012年釋出後一年內，就推出了4次更新版本，並且在2013年時還推出了VS 2013的全新改版，從此，微軟發布VS產品的步調有如搭上了順風車，既有版本每隔2～4個月可以發布一次更新，而還未上市的下一版VS也能持續發布預覽版。

過去，微軟盒裝軟體每3年才改版一次的作法就像是發行百科全書一樣，每次推出就是一整套，為了確保內容詳細程度和正確性，需要訂定長期計畫、撰寫大量內容和進行大量校對來確保每一頁內容的正確性。

在微軟舊式的瀑布式開發流程時期，微軟會花3個月時間來訂定長期計畫，部門主管還訂定5年產品計畫，而產品經理則是要想像2年後的市場需求，來擬定2年後產品上市時的功能藍圖。

完成產品計畫後，開發團隊會將2年產品開發時間，預先訂出多個要達成的階段里程碑（Milestone），每一個里程碑會發布一個對應的測試版本。工程師們再依每一個里程碑估算自己的工作進度，並修正產品進度，來計算出2年後的哪一天能發布產品。

每一個里程碑階段內還得設定程式碼開發完成的時間點（Code Complete），因為得預留時間作為測試工作和功能穩定調校，微軟過去至少會預留兩倍的程式碼開發所用的時間。多數情況是，微軟工程師很快就完成程式碼的開發，反而是花了很多時間讓功能穩定，例如整合不同功能間的衝突或整合。

微軟在1995年時曾發生過盒裝產品上市後因為致命問題而全球召回的窘況。為了避免再次發生這種微軟稱為召回等級的臭蟲（Recall Class Bug），因為微軟軟體往往會發布到全球各國，支援多種語言甚至多種OS的版本，因此衍生了大量的測試工作。

在舊式開發階段，微軟得配備了大量測試人力，幾乎和開發團隊的人數規模相當。

到了研發VS 2013版本時，潘正磊決定要改變VS團隊開發產品的方式，導入DevOps思維，要讓微軟開發更加敏捷化。

潘正磊解釋，為了因應網際網路時代非常快速的產品功能交付需求，這是許多新創公司和大型雲端服務業者如Google、臉書等都採用了DevOps思維，將開發和維運一體化的作法，讓「開發團隊要直接為維運環境中的軟體負責。」

而且更重要的是，潘正磊說，在DevOps中的Ops概念，不只是確保網站運作，讓網站不會當機而已，而應該要「擴大Ops（維運）的概念，如何讓使用者順利安裝軟體，也可以是維運的一環。」就算是盒裝軟體，只是產品提供的方式和網站服務不同，但一樣可以套用維運的概念。

開發與測試的結合是落實DevOps的關鍵之一

如何實踐DevOps流程的關鍵是開發工程師與測試工程師角色的結合，不再像過去開發團隊工作完成了才交給測試團隊接手，而是開發與測試工作合而為一，轉變成持續測試、持續整合的開發模式。

因此，微軟在開發組織分工上，也不再像過去分為產品管理、開發和測試等三大類職務，以及各自所形成的3種組織團隊，而改將工程師區分成產品經理和工程師兩種職務角色，同一項功能的架構設計、程式碼開發和測試工作都由同一個人或小組負責。

微軟也改採功能團隊（Feature Team）的團隊工作方式，一個團隊約12～18人，內有1～2個產品經理，搭配一群來自過去開發團隊和測試團隊的工程師，組成一個兼具開發與測試能力的小組，來負責產品中的一項重要功能，例如C#編譯器就由兩個功能團隊負責。

2年半前，微軟甚至還改裝總部的18號大樓，過去微軟辦公大樓是一條走廊貫穿，兩側許多小型辦公室，人人都可以關起門來工作。但是，這棟大樓改裝後，打破了舊有辦公隔間，改成了團隊辦公室（Team Room）的較大空間隔間設計。同一團隊的人都能在同一個開放辦公室內工作，彼此都可以看到對方，聽見其他人的談話，隨時站起來就可以面對面溝通，旁邊再搭配幾間小型空間，作為臨時討論或開會的場所，房間內還設有每天站立會議用的大型螢幕來呈現任務看板。這棟大樓大約進駐了1千名研發人員。因成效不錯，後續3棟大樓的裝修也都採取同樣的設計。

不同於瀑布式開發流程，微軟新開發流程聚焦於改變

敏捷開發流程結合了DevOps思維後，和傳統瀑布式開發最大的不同點，潘正磊說，是聚焦於改變（Focus on Delta），瀑布式開發就像一次推出全套新百科全書似的大改版作法，而DevOps思維更像是快速進行大量的小改版，一次只更新一個章節、甚至只是其中的某一頁。

這也是和微軟過去截然不同的產品生產流程，新作法是聚焦於不斷縮短產品生產周期，來加快交付速度。「因為這是未來的網際網路公司所必備的能力。」潘正磊說。

因此，在產品開發周期上，潘正磊也要求，所有VS開發團隊，不論是盒裝軟體版本或是VS Online雲端服務的研發團隊，都統一改採每3周完成一個Sprint（衝刺階段）作法，不再像過去那樣採取開發里程碑分階段的作法。

微軟也不再制訂產品的5年計畫了，而是縮短為只訂定每6個月的計畫，也就是兩季長的計畫，並每6個月進行市場或競爭對手評估，讓產品能因應市場最新變化。另外還會訂定一個18個月後要實現的產品願景，來規畫如軟體架構調整或本質性需求調整等需要較長時間作業的目標。

Sprint是Scrum敏捷開發中一個計算開發周期的方式，每個Sprint就是一個包括開發、測試到發布軟體的完整過程，微軟等於每3周就會發布1個新的小版本，並在內部試用一周後就對外釋出供外界試用，而不像過去得等到一個里程碑達成後才會發布一個新版本軟體。在每一個Sprint開始第一周的第一天，每一個功能團隊都要完成Sprint計畫，並於第三周結束時發布產品成果。

不過，依據開發產品不同，釋出給外部試用者的時程也略有不同。例如開發Visual Studio Online的新功能就是每一個Sprint完成後就發布到雲端讓使用者試用，而開發VS IDE版本的團隊則是每2個Sprint發布一次技術預覽版。

Scrum模式的開發團隊規模不大，原有上千人的大型團隊重組成很多個小型功能團隊後，潘正磊表示，跨團隊持續保持聯繫相當重要。

所以，每個團隊的PM在每一個Sprint開始時，要發出一封Sprint啟動郵件，將這一次的Sprint計畫描述，如任務目標，這次要完成的用戶情境（User Story）寄給其他團隊或直屬主管。Sprint結束時也同樣要發信將開發完成的項目告訴其他人，還要錄製一段操作新功能的示範影片，來展示已經完成的成果確實可用。

管理整個部門的潘正磊則是依重要性來選擇要密切關注的功能團隊，每3個星期審視一次，例如她最近最常關注的則是負責.NET開源計畫的團隊。其他功能團隊則是每隔3個Sprint親自和團隊成員聊聊。

微軟開發平臺事業部全球資深副總裁潘正磊決定從VS 2012版，要讓開發流程更加敏捷化，來加快產品交付周期，因此決定全面改變微軟研發軟體的流程。

從臭蟲數量變化檢驗是否落實Sprint

微軟VS團隊全面導入敏捷開發流程後，潘正磊經常被質疑的問題是，你們做的是真的Sprint嗎？因為有不少軟體公司在高層要求下，儘管開發團隊導入了敏捷開發，產品發布周期從一年一次縮短到每季發布一次，但其實只是將原來的1年期瀑布式開發流程，縮短為3個月的瀑布式開發流程，而不是真正的敏捷化。

潘正磊檢驗Sprint是否落實的方法是從程式臭蟲（Bug）數量的變化來觀察。倘若程式臭蟲的數量會在程式碼開發結束展開測試之後迅速暴增，再隨著功能穩定修正後再大幅減少。臭蟲數量大起大落的數據變化，代表了這只是壓縮版瀑布式開發。若真有落實Sprint，因為要確保所開發出來的產品是處於隨時可用的狀態，若出現了任何臭蟲，開發團隊會即時修復和更新，臭蟲數量就不會出現大起大落的變化曲線。

用使用者真實數據來引導開發計畫

另一個與瀑布式開發截然不同的新思維是正視真實數據的重要性，潘正磊說：「數據是落實DevOps思維的另一個核心關鍵，線上環境中產生的數據才是真正有說服力的數據，要用這樣的數據來引導所有的開發計畫和流程，而不是測試環境中假想的用戶環境。」

現在微軟每個功能團隊釋出試用版本後，會關注有多少用戶開始使用新功能，若使用人數低於預期，就要找出原因，並解決下一版本要如何改善來提高使用量等問題。

例如VS團隊有次開發了一套結合HTML 5和JavaScript來開發行動應用的套件，釋出預覽版後，產品經理追蹤實際使用數據後才發現，過半數有意下載者所用的作業系統是Windows 7環境，而這個預覽版只支援Windows 8.1。因此，很多使用者連安裝都出問題而無法使用。負責開發的團隊看到這個數據後便決定改變下一個預覽版本的開發計畫，先增加對Windows 7環境的支援。

或是幾個月前，IE瀏覽器內負責執行JavaScript的Runtime是由VS團隊負責開發。兩組功能團隊為了某一個Runtime優化作法該不該做而爭執不休，過去，微軟是由資深主管出面調解擺平，但這樣往往影響了團隊間的合作默契，現在則是靠數據來判斷。這兩個團隊後來開發了一支爬蟲程式，蒐集全球500大網站常用的JavaScript函式庫，發現有40％的網站能夠得益於這種優化方式，就不再爭論該不該這麼做而是直接就這麼做了。

善用使用者真實數據還有另一個好處。有時並非新功能不受使用者青睞，而是因為其他非軟體因素，導致使用者無法進入新功能的使用情境，連試用的機會都沒有。

「團隊要真正注重於用戶的需求和實際體驗。」潘正磊說。所以，每個月，她都會找一天，用一個下午的時間，親自從使用者情境的角度來試用新版功能。甚至，她也要求旗下VS開發人員，要用這一周編譯組建完成的Visual Studio IDE來開發下一周的新功能，等到6周後發布IDE時，至少微軟內部人員已經先試用了好幾個禮拜，這是微軟的Dogfooding作法（吃自家狗食）。

相較於過去瀑布式開發，就算取得使用者的真實使用數據，也得等到3年後的改版才能解決問題，潘正磊認為，開發團隊現在要能夠拿到數據，馬上回應，再馬上發布，這就是一個DevOps開發的迴圈，「現在是速度決勝！」。

儘管微軟VS團隊已經能夠做到3周發布一次VS Online新版本，6周發布一次VS IDE軟體新版本，但是，潘正磊仍不滿足，她說，我們只是從一本大百科全書，進展到快速發布，每次發布一本小書，距離能夠一次發布一個章節，甚至是只有更新1頁的顆粒度（Granularity），還有很長一段路。這也是微軟VS團隊下一步敏捷開發要實現的目標。

為了和其他敏捷團隊保持聯繫，團隊PM在每次Sprint啟動的第一天要寄出Sprint計畫郵件給其他團隊或直屬主管，結束時也要發信通知大家，並錄製一段成果示範影片來證明程式碼真的可用。圖片來源／微軟

相關報導請參考：「她，讓.NET走向開源」