使用現代工程實踐，微軟核心服務開發與工程（CSE，前身為Microsoft IT）團隊可以快速有效地響應，以滿足內部客戶和合作夥伴的業務需求。微軟的開發平臺Visual Studio Team Services（Visual Studio 團隊服務，VSTS）提供並內建了支援工程基礎（Engineering Fundamentals）和應用程式生命週期管理的工具，為CSE團隊帶來了採用敏捷方法的機會。通過使用VSTS，CSE致力於持續整合和持續交付的增量更新，並維護以客戶為中心的開發流程。

Microsoft IT曾經使用的是傳統的瀑布式開發流程，通常需要業務部門等待三個月才能釋出新的解決方案或修復bug。此外，Microsoft IT也無法改變關注的焦點，快速響應優先順序高的請求。隨著服務、軟體、PC 和裝置業務的變革步伐加快, 傳統的軟體解決方案發布速度並沒有跟上業務需求，而花費的時間越長就會導致失去越多的市場機會，而微軟已經錯過了許多潛在的銷售機會。

Microsoft IT改進了為微軟內部客戶開發應用程式和服務的方式，通過敏捷開放和現代化的軟體工程，幫助微軟內部業務團隊更快的創造商業價值。為了支援微軟的內部客戶和合作夥伴, CSE更快地響應不斷變化的業務需求，不再花費六個月的時間交付應用程式或更新，而是更快、更高效地傳遞價值。為了提高反應能力, CSE開始了現代軟體工程的旅程，CSE的目標是每天都以持續整合、持續交付的流程釋出新功能。

隨著VSTS服務和現代軟體工程方法的靈活性和速度, 高優先順序的專案可以在專案開始的兩週內就釋出出來。最終, CSE計劃在持續釋出的基礎上，使用 VSTS團隊服務為CSE的解決方案提供每天的增量更新。

微軟的軟體工程文化變革

為了縮短功能和服務開發週期, 並更快地響應內部客戶需求, Microsoft IT/CSE開始了向現代軟體工程的轉型之旅。作為一個組織, Microsoft IT/CSE變得更加敏捷, 採用了 DevOps 的緊密合作和共同負責的文化。Microsoft IT/CSE在改變團隊的心態, 更改組織結構, 並開始合併團隊角色。Microsoft IT/CSE也在學習如何更好地關注客戶體驗，這些變化支援新的敏捷工程實踐, 並對客戶更敏感。

Microsoft IT/CSE的敏捷開發團隊，也稱為衝刺（Sprints）團隊，由工程師、產品經理和業務客戶組成，他們協同工作為微軟內部業務客戶定義和開發解決方案。現代軟體工程需要巨大的團隊合作和緊密的協作，建立支援這種團隊合作所需的組織文化並不是一下子就能完成的，改變人們的思維方式和方法需要時間。在開發團隊和領導層中, 人員的心態必須經歷重大轉變，微軟正在進行這一轉變的過程中。

從瀑布式開發模型到敏捷開發的轉變不僅僅是將一個流程替換為另一個流程。敏捷是一個新的思維方式和持續的批判思維, 因為它要創造新的流程。當客戶需求變化時，開發團隊必須改變所交付的軟體及解決方案，在這種環境下, 結果比過程更重要。微軟的工程師團隊不再花費數週或數月的時間來設計和規劃一個整體解決方案, 然後用甚至更長的時間來開發它；相反, 新的功能請求會在未完成任務（Backlog）中成為高優先順序，並且在兩週的衝刺中完成編碼，新程式碼將定期整合到生產環境中構建。

在這種環境下, 開發團隊成員和管理人員必須要接受模糊性（Ambiguity）和快速改正錯誤，必須迅速適應新的要求和改變目標。每個團隊都必須實現自治並逐步提高，在一個專案中獲得的最佳實踐，將成下一個專案中成為新的最佳實踐的出發點。沒有任何事物是一成不變的, 甚至是目標本身。

另外, 團隊中的每個人都必須對質量承擔同樣的責任。微軟認為，等待某個人來解決某個問題，這很浪費寶貴的時間，第一個有時間的人就應該能夠處理問題。理想情況下, 每個團隊成員都應該具有能處理任何問題的背景和技能。最開始的時候，微軟還沒有達到這個理想的狀態, 但是正在穩步地朝著這個方向前進。

現代軟體工程

為了更快地響應客戶和業務需求, CSE轉向了一個現代化的軟體工程模型。此模型有兩個元件。首先, 通過合併軟體工程的開發和運營兩個角色——DevOps，提高了工程師人員和文化的成熟度，從而提升了效率。這樣, 任何工程師都可以在團隊中執行任何任務。第二，採用了敏捷開發原則、方法和工具來提升服務成熟度，從而進一步縮短週期。

（上圖為微軟現代軟體工程成熟度模型）

工程師人員和文化的成熟度

作為邁向現代工程的第一步，微軟根據業務流程重新調整了開發團隊的組織結構，讓二者匹配起來，從而消除了組織障礙, 以便可以將適當的資源分配給每個專案。然後, 微軟開始將軟體工程 （開發和測試）和服務工程（運營和維護）角色合併到一個敏捷的 DevOps 團隊中。目標是讓每個團隊成員都知道其他角色所面臨的問題, 以便能夠協作解決問題，這增加了團隊的效率和有效性。最終, 任何衝刺 (sprint) 團隊成員都可以在任何工程角色中執行任務。

從傳統到現代軟體工程的發展, 微軟確定了四個層次的人與文化成熟度。通過每一層的向上發展, 運維和開發/測試功能逐漸合併。這四個層次是：

1 級——信任：軟體工程師（開發和測試）和服務工程師（運維）更多地瞭解彼此的角色。當他們開始更好地瞭解彼此, 就培養了更大的耐心和信任。

2 級——共享目標：角色仍然被區分。服務工程師和軟體工程師繼續瞭解彼此的角色, 並開始共享一個常規的工作。他們開始互相介入，並在可能的情況下互相幫助。

3 級——角色共享：角色開始合併。服務工程師和軟體工程師開始使用通用的系統和工具、培養新的技能, 這樣他們就可以開始相互進入對方的角色了。

4 級——完全整合的角色：最後, 服務工程師和軟體工程師之間沒有區別。每個人都是同一個團隊的一員, 有著共同的目標，客戶是重點。Bug不再是軟體工程師的問題，伺服器宕機也不再是運維服務工程師的問題，任何人都可以處理這些問題。這個層面上沒有更多的交接, 只有通用工具、流程和專案，所有團隊成員對流程和專案都有充分的可見性。每一個人都可以無縫地進入任何一個角色並承擔相應的責任。

CSE的工程團隊正在這些層級上進步, 儘管速度各有不同，大多數團隊成員處於2級或3級。向上一個級別發展的一個障礙是團隊成員學習新角色的時間, 同時還要承擔日常的任務。

服務成熟度

為了通過快速交付週期保持高質量的軟體及解決方案，CSE開始採用現代軟體工程成熟度模型的第二個必要方面：服務成熟度。在遵循適當的實踐以確保業務客戶和終端使用者都具有良好的體驗並獲得想要的結果，就會產生服務成熟度。CSE專注於支援服務成熟的八大支柱和相關原則，它們為一系列方法提供了概念框架，這些方法在開發過程中將這些原則付諸實踐。

（上圖為微軟現代軟體工程支柱和原則）

流程和工具

為了縮短髮布週期，微軟採用了敏捷開發流程，建立了一系列支援的基礎環境和工具。

敏捷開發意味著迭代設計，在現代軟體工程的流程中，有一個重要組成部分就是迭代設計。迭代設計過程使用快速原型來驗證和細化設計選擇, 而不是像傳統方法那樣在專案開始前要建立詳細的計劃。

微軟同時設計了一系列的敏捷開發方法，稱之為工程基礎（Engineering Fundamentals）。這些工程基礎是微軟工程師所必須遵守的原則，工程基礎以Epics（大的歷史版本）、Benefits（收益）、接受標準（Acceptance Criteria）的方式，被嵌入到Visual Studio Team Services（VSTS）中，這些工程基礎在工程師的衝刺（Sprints）任務單中不斷被繼承。工程基礎有助於加快軟體的開發和部署，通過定義如下實踐的方式：快速、按需的開發和測試環境資源調配；無人值守的部署；自動化測試；安全、相容的服務等。

微軟建立了一個基礎架構來執行敏捷專案, 包括：

• 遷移到Visual Studio團隊服務（VSTS）開發工具上。將現有工作專案和程式碼，遷移到VSTS上，讓所有新專案都使用此工具。
• 降低開發測試環境的人工參與。過去，CSE使用的是物理伺服器的靜態環境，這需要花費很多時間來維護。今天，CSE採用Azure PaaS解決方案以及基於Azure IaaS的虛擬化來部署環境，這樣就可以根據需要而動態地部署環境。
• 提高軟體版本構建和測試的自動化程度。自動化會減少每個構建和測試執行所需的時間。
• 為持續整合和持續部署建立框架（Pipeline）。VSTS釋出管理提供了一個釋出框架（Pipeline）, 它將讓工程師可以每天釋出面向生產環境就緒的程式碼。

應用工程基礎

每個衝刺團隊都將工程基礎應用於每個專案。現代軟體工程方法是對發展過程的根本性文化變革, 而不是清單上的一組新專案。這鼓勵工程師們不僅要考慮他們所提供的程式碼, 還要思考他們將如何交付, 以及將如何最好地為客戶服務。

工程基礎作為指導性要求, 每個基礎都要在繼承的基礎上有驗收標準。衝刺（Sprint）團隊確保他們提供的服務遵循工程基礎要素。新員工將其作為指導原則, 以學習如何CSE組織的工程方法。而工程基礎也嵌入在VSTS中——工程師們每天都使用這個工具，所以他們很容易找到和使用工程基礎。

持續交付

專注於最小可行性（Minimal Viable Product，MVP）的產品：微軟的工程師採用了MVP思維，他們專注於開發最小可行的程式碼, 以便最大程度的收集使用者反饋。

• 動態和按需環境資源調配：工程師可以在任何時候實現一個包括所有必要元件和依賴服務的環境, 以便在部署程式碼時可以執行指定的功能。
• 持續整合：微軟工程師可以在任何時候為程式碼建立一個無人值守的版本，以便在幾分鐘內生成軟體的可執行版本, 這種構建可部署到任何環境而無需爭奪資源。這種整合環境提供瞭解決方案的生產環境檢視, 可用於演示新功能並驅動後續程式碼迭代和功能開發。
• 持續驗證：工程師可以在任何時候為部署的軟體啟動一個自動化的驗證過程, 以便在沒有人工干預的情況下，在幾分鐘內完成版本釋出的準備。
• 持續的服務部署：工程師可以在任何時候為構建的軟體版本啟動無人值守的部署過程, 該過程在可執行的環境中只需花費幾分鐘即可，而無需爭奪計算資源。

以客戶為中心

在生產環境中進行安全的測試：工程師可以在任何時候開始測試, 從實驗中瞭解或證明軟體服務的健康程度。瞭解使用者如何從服務獲得價值：工程師們堅持不懈地關注利益相關者，包括使用者、客戶和合作夥伴，這可以幫助他們瞭解和傳遞需求並將需求轉換為軟體功能、使用者情景和任務，從而讓客戶滿意。

CSE工程實踐

準備編碼：軟體工程師可以隨時將程式碼簽出到任何開發環境 (本地或遠端), 以便在幾分鐘內編譯、執行和除錯。

準備構建：軟體工程師可以在任何時候獲得具備所有必要元件的開發環境, 以便可以簽出、編譯和執行程式碼。

元件化：軟體工程師使用元件，這讓程式碼庫更易於構建、編寫和部署。通過使用Flighting函式，可以使新功能和程式碼變更獨立於解決方案的其餘部分而被開啟或關閉。

安全和隱私遵從性。所有軟體服務都非常安全, 並遵守安全和隱私標準，微軟工程師將安全基礎設施和工具整合到持續交付流程/任務中。

服務健康、分析和監控：微軟工程師使用遠端測量和資料來形成對使用者體驗、系統執行狀況、服務的業務價值的洞察力，從而支援自動化。

現代軟體工程在行動

（上圖為微軟現代軟體工程在行動）

Visual Studio 團隊服務 (VSTS) 是微軟工程師預設的開發環境。在雲中託管的VSTS為微軟工程師提供了一個全球可用的、具有彈性的共享開發平臺，以建立和開發軟體。微軟在典型的軟體構建中使用四個單獨的開發環境方案，每個環境都代表了開發、測試和釋出過程中的一個重要部分。這些方案是：

• 開發。開發環境因軟體而異, 但這是微軟工程師建立一個軟體的初始環境，當把開發環境託管到 Visual Studio Online線上版時，將受益於許多內建功能：

1. 未完成任務（Backlog）。可以跟蹤功能、使用者情景和工作項的Backlog，它們對應於整個專案的計劃, 並提供整個專案的優先順序檢視。
2. 看板（Kanban boards）。使用“看板”來跟蹤跨所有衝刺專案的需求，並允許監控開發工作流以及團隊的工作狀態。使用“看板”，可以將Backlog轉化為整個專案的視覺化呈現。
3. 連結的程式碼。使用 VSTS, 任何程式碼變更都可以連結到使用者情景、bug 或任務，它提供了一個基於通過程式碼庫的可跟蹤路徑，並可視化了解程式碼庫是如何隨著專案的進展而演變。
4. Git程式碼庫。Git上儲存著微軟的程式碼庫, 它支援程式碼共享和協作，而這將增加程式碼的複用、一致性和透明度。
5. Visual Studio控制的程式碼載入（Gated Check-in）。使用Visual Studio控制的程式碼管理模式，能夠強制性地要求程式碼變更前至少通過兩個程式碼審查員的確認，以及在程式碼變更被載入到伺服器之前要通過一個成功的編譯構建。
6. Visual Studio構建系統。使用VSTS構建系統, 通過使用構建代理來實現自動化地構建整合，從而實現持續整合。
7. Visual Studio釋出管理器。使用Visual Studio釋出管理器來自動化測試和部署過程，以實現持續續部署。

• 整合環境。整合環境對敏捷開發方法來說至關重要，它為開發者提供了一個生產環境（live environment）, 可以將衝刺（sprint）版本推向下一階段。在整合方面, 微軟工程師實現最小可行的產品（MVP）: 一個可靠但可能不完整的軟體版本，用以向客戶演示,並與團隊成員共享功能測試、功能審查或投產前的準備。
• 投產前（Pre-production）環境。投產前的環境，主要用於beta測試和試用版。在這種環境中，可以提供一個映象生產環境的體驗, 但只定向釋出給選定的使用者或使用者組進行最終測試。
• 生產環境。生產環境只是讓軟體解決方案使可為所有使用者使用，從而支援微軟的業務。從投產前環境中獲得一個生產環境是一個很簡單的過程，它進一步實現了衝刺版本釋出和日常站會（standups）的持續交付目標以及客戶至上的思維方式。

實現現代軟體工程的收益

• 將現代軟體工程模式與VSTS結合起來, 已經給CSE帶來了極大的好處。這些好處包括：
• 以更快的釋出週期滿足業務部門使用者需求——可在兩週內提供新功能。
• 問題很快就會被糾正, 而不用讓使用者等待下一個大的軟體版本。
• 不斷地交付應用程式組合的更新和增強功能，從而比以前更快地實現軟體開發工作的商業價值。
• 將發行版分解為較小的“塊”將降低風險, 因為“塊”僅表示兩週的開發努力, 而不是幾個月。

除了更快的釋出週期外, 工程師審查和與使用者互動的方式也帶來了文化上的轉變, 從而提高了客戶滿意度。工程師們現在更好奇軟體是如何執行的, 以及使用者是否對這些功能感到滿意。為了改進軟體並使使用者的生活更輕鬆, 工程師們正在學習如何將使用者問題轉化為工作任務並將其列入優先順序。

現代軟體工程的最佳實踐

邁向現代工程文化需要在多種學科中進行廣泛的努力, 包括思維方式和傳統領導方法的重大轉變。在進行這一轉變的同時, 微軟學到了一些寶貴的經驗教訓。

在團隊內部建立合作關係。傳統管理團隊的方式是衡量每個成員的表現，這往往導致團隊成員相互競爭。 為了讓敏捷開發工作順利, 團隊成員必須在彼此的工作基礎上互相依賴, 而不是競爭。為了幫助建立團隊合作，要以一個團隊為整體來進行評估，衡量每一個團隊是否成功達到團隊目標。

鼓勵團隊自行解決問題。團隊應有權自行解決任何問題，如果需要向上升級, 那麼團隊成員應該在提出問題的同時，盡力也提出解決方案。應該鼓勵團隊成員使用資料來獲得洞察力並做出正確的決策。他們的目標應該是克服障礙, 更快交付價值。

採用分階段方法進行文化變革。任何一個開發組織也不會在一個大的推動下就轉變為現代軟體工程文化。通過分階段的方法，設立一系列可實現的階段性目標，邁向理想的、敏捷的文化更有可能成功。

企業規模敏捷開發的挑戰

微軟成功的開始在內部小型專案中採用敏捷開發的模式，但在走向大型專案的時候卻遇到 了問題。

在較小的專案上, 敏捷為CSE提供了很好的效果, 但是當微軟開始在大型的、企業級的專案上使用敏捷模式時, 遇到了瓶頸——減慢了工作速度,、降低了質量，而問題出在團隊規模上。敏捷模式最適合九名成員的小團隊，當微軟試圖為大型專案增加人員時，增加的人員越多、團隊的效率就越低。有些開發團隊非常龐大，達到150人甚至更多，於是陷入了困境。此外，微軟也無法預測完成一個超過兩週衝刺的大型專案所需的時間和資源，這就產生了預算和資源問題，因此必須找到在企業規模上使用敏捷開發的更好方法。

為了解決這些問題, 微軟研究了將敏捷應用於企業專案的第三方框架, 如針對精益軟體和系統工程的可擴充套件敏捷框架（Scaled Agile Framework for Lean Software and System Engineering, SAFe）, 並將它用於開發微軟自己的方法論基礎。

為了更好地理解微軟是如何實現可擴充套件的敏捷模式, 首先要了解CSE的小型敏捷團隊是如何運作的。使用已經建立的敏捷模型, 小型的跨職能團隊負責構建和交付服務。微軟內部客戶建立所需要的使用者情景, 定義服務必須提供的內容，即業務價值。使用者情景以簡單明瞭的方式編寫，很少帶有細節。這些明確而簡單地定義了開發人員在兩週衝刺期間必須要交付的業務價值，然後敏捷團隊將使用者情景分解為若干可以在一天內完成的任務。使用這個方法, 開發團隊能夠根據實際資訊和客戶的需求快速迭代和解決問題。

CSE的小型敏捷團隊具有如下角色：

• 產品負責人。該角色對應于敏捷模型中的業務所有者，產品負責人代表客戶的利益，幫助確保開發工作滿足客戶需求。
• 專案經理。該角色在將使用者情景轉換為不同任務時，負責協調團隊的工作。在衝刺 (sprint) 期間，Scrum（一種敏捷開發方法論）大師每天帶領15分鐘的站會並跟蹤進度。
• 軟體工程師。該角色負責設計、編碼、構建、測試和釋出軟體。
• 服務工程師。該角色負責協調事件管理；變更請求；傳統釋出方式下的更新、打包和釋出版本管理等；與資料中心和雲核心有關的傳統IT問題；任何必要的服務監控。

當然，隨著微軟向現代軟體工程演進，這些角色也不斷變化融合。

在微軟應對大型敏捷工程的時候，出現的問題包括：隨著每個團隊的變大, 複雜性也隨之變大，加入的人越多, 團隊的交付能力就越慢——接近幾乎閒置的狀態，而每天的站會變得越來越長。同一個團隊的人，最終工作在極端不同的任務上，彼此之間很難協調。

• 對程式碼之間的依賴關係缺乏理解和管理。當在一個團隊中增加了太多的成員時，工作效率變得低下且難以協調；但是當嘗試使用小型團隊時卻遇到了瓶頸，即不同的團隊在負責不同的任務，當並行任務數量過多時，彼此之間無法預期所需要的上下游任務的完成時間，導致有些團隊的空置。
• 在設定期望時遇到困難。整個團隊沒有機會在下一個衝刺前進行計劃，所以也不知道專案會有多大。這意味著不能告訴產品負責人，何時能完成工作。反過來，產品負責人也無法設定客戶的期望。
• 錯過最後期限。對於大型專案, 團隊無法在設定的截止日期前完成, 因為他們對所涉及的工作量不清楚。
• 過度工作的團隊成員。當試圖進行大型專案時，團隊的生產率開始下降，團隊管理人員被迫增加更多的開發者, 並迫使人們加班。這隻會讓事情更糟，由於沒有人知道一個專案需要多少工作，因為試圖在截止日期內完成專案，開發人員常常發現自己被過度的工作負擔所淹沒。
•  質量降低。隨著規模的擴大, 質量開始下降。團隊成員因做太多工作而精疲力竭，他們停止了思考, 只是做了被告知的事情。新功能需求得到優先考慮，所以持續工程和當前的產品問題沒有得到需要的關注。
• 預算困難。當不理解專案工作量的真實範圍時，很難預計到底完成專案需要多少預算。

 

因此，微軟希望保持小型敏捷團隊的效率和有效性，同時讓小型團隊能夠在大型專案上進行合作。在提到第三方框架（如SAFe）基礎上，微軟開發了一個框架, 可以在各個層面上擴充套件敏捷的規模。從上往下框架層面分別為：

• 應用組合（Portfolio）。在微軟框架的頂部，是設計產品套件和協調開發的地方。在這個層面，團隊負責建立和管理Epic和Scenarios（場景）。其中，Epic是一組集成了單個服務的大服務。這可以類比成汽車模型，Scenarios是Epic中的大型元件，例如車身、車架、懸架或電氣系統。Epic和Scenarios都是用通俗易懂的語言描述，任何人都能夠理解。規劃包括年度路線圖。Epic一般需要2到6個季度才能完成，一個Scenario需要超過一個季度的時間才能完成。主要專案經理、總經理或總監根據專案的跨度，來監督這個層面的工作。
• 專案（Program）。在這個層面上，團隊負責管理功能（Feature）的開發。Feature是Scenario的片段，稱之為增量。繼續使用汽車的例子, 如果電氣系統是一個場景, 增量可能包括諸如保險絲盒、點菸介面卡、電線等等。每個小的敏捷開發團隊都有一個在專案團隊中的代表，專案團隊的工作包括整合小型敏捷團隊的可交付成果、功能規劃以及確保工作與客戶需求相一致。Feature規劃按季度完成——每個增量都在一個季度內完成。專案經理負責管理小型敏捷團隊的工作, 並將其與客戶需求進行協調。這裡沒有在小型敏捷團隊中每天舉行的站會, 而是每週或每雙週對小型團隊代表舉行會議。如果一個Feature是一個更大套件的一部分，每個Feature團隊都會向整合Feature的應用組合團隊送去一個代表。
• 團隊/執行（Team/Execution）。微軟框架的基礎層，是小型的敏捷開發團隊，理想地限制在每隊九個成員的規模。這些小型團隊用經典的敏捷方式進行程式碼編寫，並且是基於使用者的場景和任務。業務價值將在兩週的衝刺中交付。

（上圖為微軟可擴充套件的敏捷框架）

下圖顯示了可擴充套件的敏捷過程如何在專案級別上的運作。

（上圖為專案級別中的可擴充套件敏捷過程）

擴充套件敏捷規模時的焦點區域。微軟的框架是在企業專案中使用規模化敏捷方法時的基礎。要使專案在新的框架內成功，就必須不斷地集中精力減少依賴關係、在自治與一致性間平衡、改變文化以及將衝刺和釋出分離開來。

減少依賴。微軟瞭解到, 不斷減少依賴關係很重要, 否則會減慢工作的速度並造成瓶頸。而如何減少依賴關係，則是在個案的基礎上，找出依賴關係並確定它們的影響, 然後減輕甚至消除它們。依賴關係可能發生在團隊、體系結構和流程等方面。

團隊。微軟組織和構建團隊的方式會影響依賴關係。基於這個原因，微軟正在從一個橫向的團隊結構轉向一個縱向的隊伍——從專業化分工的團隊變成一個可以獨立而全面解決自己問題的團隊。例如, 當多個團隊依賴單個數據庫團隊時, 資料庫團隊必須分級並排定工作的優先順序，這會造成瓶頸。為了避免這種情況, 每個團隊必須具備解決問題所需要的所有技能，並自治式地完成工作。

微軟還致力於組織地理位置偏遠的團隊，讓他們能夠相對獨立，並且只在衝刺或增量級別進行定期溝通。例如，微軟CSE的一些團隊在印度，於是就讓這些團隊做自己的工作，這樣他們就不必經常與雷德蒙德的團隊溝通，否則會讓他們慢下來。

架構。微軟試圖在設計產品時，減少依賴關係和瓶頸、避免重複性工作。微軟不希望多個團隊依賴於單個產品或功能，當不能完全消除依賴關係時，儘量減少它們的影響。例如，微軟在銷售和營銷領域的五個團隊使用SAP系統進行支付，儘管他們在一個為期兩週的衝刺週期中工作, 但SAP的更新僅每6個月釋出一次。與SAP的發行版保持同步是一項繁重的工作，而且每個團隊還要分別管理版本同步的工作。為了解決這個問題，微軟組建了一個團隊來構建一個稱為“Pay as a Service”的抽象層，它具有簡單的輸入和輸出體系結構，並使用各個團隊管理版本同步的同樣方法，這樣團隊可以更快地行動，因為不會重複同樣的工作。

流程。流程包括跟蹤和組織資料、變更審批委員會（CAB）會議、每天的跨團隊協調會議和幫助臺等。共享過程提高了團隊之間的一致性, 實現了規模經濟效益。另一方面, 多個流程可能會產生大量的開銷, 因此在必要的時候要統一團隊步調，這需要“足智多謀”。微軟希望確保採取的任何流程都要有明顯的收益，而對團隊的影響要微乎其微。專注於流程還包括關注團隊的持續改進, 不斷減少依賴關係。

在自治性和一致性間保持平衡。從一組服務中組裝解決方案，就像讓每個敏捷團隊在被子的一部分上工作一樣。如果每個人都獨立工作而沒有協調，那麼當他們把所有獨立製作的被子的一部分拼合起來時，會發生什麼呢？可能不像預期或期望的那樣。而且，這麼做很可能導致效率低下，所以需要團隊之間的協調。

另一方面, 微軟的敏捷團隊又希望快速而持續地改進，自治可能是最簡單的方法；但是對於大型專案，每個團隊都是一個更大規模團隊的成員，必須要與其他團隊協作。為了平衡團隊目標和大型專案的需求，要確定團隊需要在哪裡被協調, 以及在哪裡可以自治。

這樣做時要記住，很容易將術語“一致性”轉換為“標準”或“需求”。如果試圖向團隊提供工作的剛性細節, 這反而會阻礙他們。相反, 只對小團隊進行需要的調整, 足以給更大的團隊提供所需的資料和功能即可。微軟的目的不是讓小團隊以某種方式做事, 而是要提高與其他團隊在相關合作領域的效率。在這些約束條件下, 每個團隊都可以自由地找到最適合自己的解決方案。每個人都不必以同樣的方式工作, 但所有團隊都在關鍵領域保持一致，這樣更大的團隊才能發揮作用。

微軟在特定區域統一團隊。例如：所有團隊都有日常站會, 使用相同的流程和基礎設施, 並分享相同的兩週交付節奏；所有團隊都已遷移到 Visual Studio Online線上版；處理同一程式的團隊也共享相同的待完成任務列表；而團隊如何從待完成任務列表中選取和分配任務的順序，是基於更大的目標。微軟還使用一種通用語言來報告團隊進度、速度，並演示團隊價值和影響。這讓微軟團隊對未來有了更大的視野和一定程度的可預測性。

微軟還提醒團隊，儘管大規模使用敏捷會產生更多的依賴關係和降低自治性，但它也會產生規模經濟效應。相應的系統和基礎結構已經建立，團隊不必在它們上面花費時間和資源。

改變文化。在為企業專案而擴充套件敏捷工程的規模時，問題會被放大。做每件事需要更長的時間, 包括在整個組織中改變文化。微軟不得不後退一步, 找出如何彌合領導層、利益相關者和敏捷團隊之間的溝通鴻溝。微軟努力消除在人這一層面的障礙，以增加更多的認同並在所有層面推行一致的願景。清晰的溝通、減輕依賴關係和解決障礙是一個不斷髮展和重複的過程。微軟以與專案中對待backlog的同樣方式，對待這個過程。

微軟發現合理設定期望值很重要。當微軟開始大規模使用敏捷方法時，所有的專案都被標記為“最高優先”。微軟認識到，需要讓合適的人提前參與討論，以便讓每個人都知道將採取什麼行動以及何時採取行動。微軟CSE會溝通交付的優先順序，並討論交付順序。

微軟改變的另一個方面是如何定義將要交付的內容。在傳統的瀑布模型中，相關人員和客戶能清楚地知道在未來很長一段時間才能交付的軟體到底是什麼樣，詳細到顏色、大小和功能等。而在敏捷模型中，需要承諾了產品線和日期, 但為了允許在需要時進行修正，導致對最終產品的確切含義是含糊不清的。例如，可能會說到2017年底將生產出世界領先的虛擬現實眼鏡，然後就沒有更具體的了。

領導力在規模化敏捷工程中的作用也是不同的，需要改變思維方式和學習過程。領導人過去每年都聚在一起建立路線圖和專案, 並將它們交給工程團隊，工程團隊則響應承諾的交貨日期，領導層將推動團隊實現既定目標。隨著敏捷程度的提高, 領導層應該瞭解到團隊具有一定的工作能力，必須為這些團隊提供適當的工作量。領導人還需要事先了解組織如何根據工作量而擴大或縮小的規模。他們知道結果是他們的責任，例如隨著銷售和營銷團隊的領導越來越多地參與Epic和Scenario，他們正在對開發過程擁有更大的自主權。通過開發生命週期, 他們實際上是在進行更大範圍的衝刺。通過這一經驗, 他們正在學習像 Scrum 高手一樣規劃自己的backlog。

將衝刺與釋出分離。除了軟體程式碼，商業價值可能是一個計劃、有關設計的決策、測試環境的框架、Epic和Scenario等。為了交付商業價值, 沒有必要將軟體推向生產環境。在這種擴充套件的敏捷模型中，軟體釋出在衝刺（sprint）之外發生。

這個問題涉及流程和工程上的最佳實踐，這需要改變團隊的心態。通常，瀑布模型下的版本具有交付專案的目標日期。微軟發現從瀑布到敏捷的大型團隊，通常會試圖將瀑布流程變成衝刺，包括通常的瀑布釋出里程碑——alpha版、beta版、預釋出版、生產環境釋出版和清理（Cleanup）版。他們認為提供商業價值同樣需要釋出，如果一個團隊需要六個月的時間來發布服務，那麼首次衝刺將持續六個月。當這樣的團隊被告知要進行為期兩週的衝刺時，他們經常會嘗試將瀑布方法強制推入這個被縮短的衝刺週期，但是卻不會起作用。

相反, 當使用現代軟體工程最佳實踐進行釋出時，會移動到已執行的系統中去。微軟從規劃和體系結構開始, 構建一個功能, 然後執行程式碼；將遠端測試就位, 以便跟蹤系統中發生的情況並自動進行測試。開發人員應該能夠很容易地釋出程式碼，如果程式碼有問題，就會被踢回來。最終目標是讓團隊按下按鈕, 就將功能釋出到生產環境中。

隨著團隊在規模化敏捷模型中的成熟, 他們正在學習將釋出過程與衝刺分開。在衝刺 (sprint) 中發生的事情不一定會在釋出中達到高潮，而是代表定義的業務價值。隨著團隊採用越來越短的衝刺，他們意識到需要在更長的週期進行持續釋出，即使仍需要六個月。隨著時間的推移, 釋出週期可能會變得更短, 但不需要與衝刺 (sprint) 匹配。通過分離衝刺與釋出流程, 可以讓敏捷系統更成熟, 也讓釋出週期更加成熟，互相不需要讓另一方產生負擔。釋出應在後臺進行。

經驗和教訓

在擴充套件敏捷方法時，微軟瞭解到, 優先考慮以下方面很重要：

• 最小化依賴關係。這樣可以防止幾個團隊依賴一個團隊來實現可交付結果時出現的瓶頸，沒有一個團隊擁有可以決定整個專案的任何部分。如果一個可交付結果進入了關鍵路徑並開始減慢專案的速度, 任何其他的團隊都可以著手繼續工作。
• 交付價值。在典型的敏捷模型中, 涉及提供服務的小型團隊，服務將作為價值釋出到生產中。在縱向擴充套件的敏捷模型中，價值的評估方式不同，因為在開發中的程式碼不一定會立即被推入生產環境中。它與其他團隊的在開發中的程式碼一起整合，重點仍然是交付價值。
• 成熟和一致的團隊。最初，微軟的每個敏捷團隊都以相對自主的方式運作，並採用自己的節奏、工具和流程。當微軟試圖協調多個團隊的工作以交付大規模的產品或套件時, 這就產生了問題。今天，微軟的團隊更加一致。隨著時間的推移，微軟將繼續關注完善團隊和方法，以建立一個越來越好的系統。

微軟在做什麼

隨著微軟繼續進行現代軟體工程的旅程，微軟提供的商業價值比在瀑布模型下交付的要高，客戶對結果更滿意。使用微軟模型來改進敏捷擴充套件的領域包括：提供更好的質量程式碼, 降低服務的波動性；設定並滿足期望；團隊成員積極參與這一過程；建立更準確的計劃, 實現準確的預算編制；提供接近100%的計劃增量功能。

在規模化敏捷的前提下，微軟發現那些領導層最瞭解並參與流程的團隊，將獲得最大的好處。小型團隊每天都在敏捷環境中工作，對這一套工作流程通過日常經驗變得越發熟練。然而，專案和應用組合級別的團隊領導，被從日常的敏捷過程移除了。此外，需要更長的時間來完成一個完整的週期而不是兩週的衝刺，一個完整的週期可能需要幾個月的時間。因此，領導層需要更長的時間才能完全理解敏捷方法是如何規模化運作的，甚至在領導者經歷了一個完整的週期之後，微軟期望繼續擴充套件敏捷模型的規模來處理更大的專案，讓領導者學習如何在更高的層次上管理敏捷。

輪換DevOps角色，提高服務質量

為了加強對敏捷方法的採用，Microsoft IT/CSE將“直接負責人”（Directly Responsible Individual ，DRI）新增到了DevOps團隊中，通過關注事件管理、服務可用性和服務健康狀況等，輪換角色可幫助微軟的敏捷團隊在問題影響客戶之前主動發現和修復問題。由於需要解決的服務問題越來越少，團隊成員有更多的時間來交付業務價值。因此，微軟得以更快的速度和更高的效率提供更好的服務。

增加直接負責人（DRI）是許多信奉DevOps文化的高效能敏捷軟體工程團隊的選擇，這個角色也被其它不同的名字所熟知, 比如Google的“警長”（sheriff）或者 Facebook的“特定響應者”（Designated Response Individual）。在敏捷團隊中輪換, DRI負責服務可用性、服務執行狀況和事件管理，DRI以客戶為中心並推動積極的變化, 以改善客戶的服務經驗。

在Microsoft IT/CSE中，也使用了DRI來幫助微軟敏捷團隊更快、更有效地提供更好的服務。DRI積極地著眼於生產環境中的服務, 從而幫助敏捷團隊更加積極主動。這幫助微軟敏捷團隊減少了多達50%的服務請求單和bug數量，也讓團隊其他人有更多時間來提供業務價值。

沒有增加DRI角色之前，微軟工程師團隊每天只能從每個軟體工程師那裡得到四到五小時具有生產力的工作。自從將這一角色新增到團隊中，每個軟體工程師每天可創造生產力成果的時間增加到六小時。該角色還降低了風險，因為解決問題不會影響團隊在衝刺（sprint）上交付的能力。此外，微軟還發現DRI減少了與服務專案互動的次數, 所以成本也在下降。

DRI流程與期望

在微軟的敏捷團隊中，有一個主DRI和一個輔助DRI。主DRI把時間100%分配給這個角色，沒有其它團隊任務。每天，主DRI要檢查事件日誌，對關鍵事件或事件模式作出響應，還記錄缺陷，並根據根本性原因將其分配給個人工程師處理。為了保證可見性，輔助DRI會被主DRI抄送所有的事項。在主DRI不可用或繁忙的情況下，輔助DRI會介入。

所謂輪換，即主DRI和輔助DRI角色會在所有團隊成員中輪替。為了實現無縫轉換，輔助DRI成為下一輪的主DRI。在同一衝刺期間，主和輔助DRI不會與Scrum 大師的角色重疊。輪替的節奏是每兩週一次, 與理想的兩週衝刺節奏一致。這確保了DRI可以參加每隔一週舉行的服務審查和其它服務線的會議。這還確保了DRI在衝刺中有足夠的影響力，並且有機會花時間在首選的工程活動中。輪換從衝刺的第一天開始，持續到下一個衝刺的第一天，衝刺團隊自行跟蹤和管理他們的DRI計劃。

對於出現的問題，DRI執行根本原因分析, 並與負責該功能區域或元件的軟體工程師互動。DRI沒有被期望成為英雄並修復所有問題；然而，如果問題很容易解決，DRI可能會獨立地繼續解決問題，同時也會跟蹤擴展團隊的可見性。DRI需要建立一個VSTS的工作專案，並在可能的情況下將其連結到出現問題的事件中，以便於追蹤。

由於DRI活動需要團隊的一定配合，這佔用了團隊的“頻寬”，因此微軟將主要的DRI時間安排為Visual Studio Team Services (VSTS)中的“休息日”，這使得DRI工作不會對衝刺計劃產生影響。DRI以兩種方式響應出現的問題。在核心工作時間內，DRI會檢查需要解決的關鍵問題或問題模式。而在核心時間之外, 當需要軟體工程來響應事件時，服務工程團隊會與DRI合作。主要DRI的隨叫隨到時間表是輪換的，這樣沒有人需要在每年一個以上的主要假期中被隨叫隨到。

在處理嚴重程度較高的現場生產環境問題時，主DRI應該參與到輔助DRI的工作中去，除非主DRI確信問題可以快速解決。DRI還有權與具有相應知識從而可以幫忙的其他團隊成員聯絡。找他人援助，即使那些人並被有處於隨時被召喚狀態，也是正確的做法。多人在關鍵問題上一起上可以縮短解決問題的時間並減少DRI的壓力，否則DRI只能自己處理問題。這種互助也會幫助團隊成員更加理解DRI，從而得到成長。

當然，微軟希望隨著DRI這一角色越來越成熟，將減少甚至最終消除對團隊支援的需求，這樣將解放敏捷團隊的“頻寬”，讓他們創造更多業務價值和提高質量。今後，主DRI還將負責把軟體部署到生產環境中，DRI將確保部署過程中具有正確的部署文件、自動化和驗證，部署之後還將檢查結果和服務狀態。這種做法還將減少接觸潛在敏感資訊的團隊成員數量，這也是一種符合Sarbanes-Oxley（SOX）法規的模式。

DRI收益

隨著DRI主動調查內部異常和提交問題（Tickets）趨勢，微軟團隊在每次衝刺時都在解決bug。這改善了客戶經驗, 減少了每週的異常和提交問題的趨勢。

而當團隊成員作為DRI參與時, 他們會獲得有關端到端服務的知識。DRI負責全面瞭解服務、客戶體驗以及服務如何實現業務價值。這種更廣泛的關注，使團隊成員更負責地交付高質量的客戶體驗，並推動更豐富的設計。每個DRI都帶來了獨特的視角和不同的值，這種關注的多樣性有助於團隊在許多領域改進服務。例如，一個微軟的DRI發現一個服務與資料儲存不在同一個區域執行。這種模式在預生產中不存在，如果沒有DRI的職能可能就不會被注意到。現在，團隊可以將服務重新部署到與客戶相同的區域，這將減少延遲並改善客戶體驗。

以前, 當客戶遇到軟體缺陷時, 會重試要執行的任務或使用其它已知的變通辦法。DRI則在客戶把問題升級之前，就主動識別阻斷問題並修復缺陷。在某些情況下, 在客戶甚至意識到存在問題之前，DRI就已經記錄了軟體缺陷，這極大地縮短了微軟團隊平均檢測（MTTD）和平均解析（MTTR）兩個指標的時間。

將IT轉變為創新引擎

在企業的數字化轉型過程中，通常期望從自己的IT團隊中孵化出創新能力，通過自己的IT組織來推動數字化轉型。然而，企業的IT組織往往揹負“技術債”。企業內部IT往往行動緩慢、過度流程導向、缺乏靈活性、傾向於規避風險、缺乏創造力，這也經常導致企業會引入外部專家以避免內部IT的掣肘。

微軟認為，與其引入外部專家，不如提高自己內部IT團隊的現代化程度與能力。其好處包括確保更好的解決方案可持續性和可重用性，利用公司內部已經有的專業知識和關係，以及減少供應商支出和總體複雜性。從員工統計的角度來看，隨著數字原生的千禧一代的越來越多，對速度、創意和新技術趨勢的使用驅動力只會越來越大。

內部IT組織的現代化，可以從建立一個孵化中心開始，孵化中心是組織內的一個小組，專注於新的應用、新的想法、最新技術，並利用新的方法進行交付。該小組旨在與內部業務團隊和其他IT團隊合作，開發具有創造力和敏捷性的現代解決方案，他們必須願意違反標準的IT慣例和流程，以超越客戶的期望。

內部創新孵化中心的作用不僅僅是提供具體的解決方案，還向企業內部展示了可以在整個IT組織中採用的新技能組合和工作方式。一旦該小組開始取得成效，就可以作為其它更好、更快、甚至成本更低的交付的例子。其最終目標是轉變為一個創新引擎——一個快節奏、靈活、有創意的數字化解決方案交付引擎，以類似於消費類初創企業的方式滿足客戶需求。

歷史上，曾經的微軟IT也引入了的現代化IT創新小組，旨在幫助滿足數字化轉型的需求。在2014年的時候，該團隊分別位於華盛頓州雷德蒙德和印度海德拉巴，這個團隊旨在創造創新的、具有消費者價值的企業級體驗——讓內部使用者喜愛他們的裝置，同時提供前所未有的靈活性體驗。

微軟現代化IT創新小組的方法論：

• 首先是從一張白紙開始，要讓這個創新小組可以突破任何現有的限制，其目標是消除過去和現在的偏見——不要對今天做出改進，而是重新開始；
• 創新小組要能組織接納那些對新工作方式持開放態度，對創造力、數字激情和快速結果有偏執的人，例如微軟現代化IT創新小組就大量直接從高校中僱用成員，同時研究創業公司和小企業領導的物質——不僅要了解他們做了什麼，還要了解他們沒有做什麼；
• 成功的創新需要減少對團隊的限制，因此要支援原則而不是流程、傾向於有自己的判斷而不是絕對的標準、不斷迭代而不是一開始就追求完美，以及基於文件的直接協作，都是減少內部組織約束並同時培養敏捷性和創造力的方法，而對於那些必要的公司流程則只保留最關鍵的部分（比如安全），同時為這些流程創造“便捷路徑”或“高速路版本”，以便幫助創新小組而不是成為障礙——靈活不僅來自於該創新小組內部，也來自於周邊相關的大環境；
• 該創新小組應該視為價值資產而不是威脅，包括傳統IT團隊在內的所有各方都應該分享成功，這是健康的利益分享和專案的先決條件，甚至可以由創新小組提供創新方案的V1或V2版本後再交由傳統IT團隊繼續開發；
• 培養健康的跨組織合作激勵文化，要確保與這個創新小組合作的其它公司內部組織不會感受威脅，而是更願意看到合作的價值，成功還意味著從失敗和實驗中學到寶貴的經驗教訓；
• 積極傳播“這是什麼、為什麼以及如何實現”，在微軟實踐中，創新小組首先為內部客戶提供敏捷服務，其次是支援R&D團隊交付創新而增值的結果，然後就是積極傳播“這是什麼、為什麼以及如何實現”，同時創新小組也以年為單元輪換不同的開發人員進入該小組，以便在整個微軟工程師團隊中傳播敏捷的文化。

內部IT組織的現代化對任何企業來說都不容易，這就像在開發應用程式時執行迭代迴圈一樣。當然，來自高管的支援也很重要。就微軟而言，直接來自最高層。通過微軟的實踐，有理由相信大多數企業可以很好地將IT轉變為創新引擎。（文/寧川）