這屆 Windows 不行，是因為微軟不賣「軟體」改賣「服務」？

最近Windows 版本質量的問題，即 Windows 10 2018 10 月更新的諸多 Bug 再次引發了有關提供「Windows 即服務」的意義的討論。在發布 Windows 10 的時候，微軟宣布了一件大事：稱這是「Windows 的最後一個版本」。從今往後，Windows 將持續提供一系列添加新功能的發布，而不再延續每 3 年左右發布一次大版本的做法。

錯亂的 Windows 10 是因為微軟的開發流程出現問題

此前，外媒Arstechnica 發布了一篇名為《Microsoft』s problem isn』t how often it updates Windows—it』s how it develops it》（CSDN 進行了編譯《微軟「作死」Windows》）的文章，在這篇文章中，作者 Peter Bright 在文章中嘗試探討 Windows 出現的重大問題的原因。他在文章中提出的觀點是，問題不在於 Windows 更新的速度，而在於他們開發這些更新時採用的流程。他的討論中有很多的推測和天真的想法（關於軟體開發的想法），但是我認為他的基本診斷是正確的。

我想說通過一些 Bug 來嘗試診斷一個龐大而複雜的過程本身就是有問題的。這不禁讓我們想起去年當蘋果的發布質量上出現了備受矚目的 Bug（2017 年 WWDC 上，新機 iPhone X 的 Face ID 人臉識別失敗）時，輿論界的驚濤駭浪層出不窮。這就像說全球變暖是個問題，並用死亡谷的溫度作為證據。沒錯，我們是有全球變暖的問題，但是你需要更好的證據，更好地理解整體模型和系統，才能真正做出令人信服的論證。

今年夏天我發表了一篇文章（https://hackernoon.com/taking-office-agile-455f243e0978），其中描述了微軟的 Office 經歷了同樣的轉變，即從幾年一次的大型發布，轉變成了按月定期發布所有平台新版本的做法。這涉及到業務模型、組織結構、工程角色、工程基礎架構和流程的變化，以及產品和代碼本身的重大變化。這個過程持續了十年之久，而且仍在進行。這可能是我在微軟時做過的最艱難的事情。

當你在大公司從事一些艱難的工作時，有時很難看出你的努力導致了什麼樣的改變。對於這種轉變，我恰好有機會觀察到另一家正在經歷相同轉變的組織的改變過程，因此可以做一些很有意思的比較。這就像是一個「平行時空」，通常這類的比對是不可能做到的。

在 Office 中，由於我們不能簡單地縮減現有的流程，所以我們在一開始就採用了這個流程。我們需要從單個工程師開始到領導層進行轉變，這種自下而上的流程有很大的不同，而且需要公司內部結構的重大改變，以及單個工程師日常工作方式的變化。

我們總結出了「5C」方針（即持續規劃、持續集成、持續穩定、持續部署和持續洞察），並進行傳達。這些元素是一個循環計劃，首先將功能分解為更小的組件以方便安全地集成，同時保持完全穩定，快速部署（每天或更快地部署到數千台桌面、設備或服務中），生成遙測和洞察，然後再反饋到計划過程中。

對於採用敏捷開發流程的人來說，這些元素一點都不陌生，我們只是在前所未有的規模度和複雜度上嘗試了這一點。

微軟的「Windows 即服務」戰略是對的？

與此同時，Windows 也採用了「Windows 即服務」的戰略。他們也在對組織和流程進行根本性的改變（實際上因為在建立另一種驗證流程之前就解散了大部分測試組織而導致他們聲名狼藉）。然而，從根本上說，他們採取的方法看起來更像是壓縮和縮短現有流程而不是徹底進行轉變。

最大的區別在於 Windows 將繼續允許將帶有缺陷的部分和不完整功能納入構建中，然後再通過一個單獨的過程和周期來穩定它們。

我的觀點是，在任何大型流程中只有少數幾個關鍵點具有強大的支撐作用，可以產生正確的反饋信號。如果你做對了，這些支撐點可以為公司的各個團隊和工程師以及領導提供明確的信號。而在我們的實際情況中，它推動了我們的這種持續部署穩定和可用的構建模型。這點要求為個人團隊和大量工程工具的構建提供了許多創造性的策略，而且易於溝通，也相對容易衡量。這本質上是一種信仰飛躍（相信我們經過了嚴格的審查和討論），可以為整個組織帶來令人難以置信的創造力。

如果你不強制執行這一點，那麼很容易導致個人工程師和團隊中出現「公地悲劇」，而且他們還不知道他們的不穩定性和不完整性將導致其他團隊的成本和開銷上升。實際上，即使在之前的大型發布工程戰略中，我們也常常為這些成本付出沉重代價，而且沒有強制實施重大戰略變革的商業模式。轉向多平台、服務和訂閱業務是激勵人心的變革。

Windows 團隊已經就他們的與眾不同提出了很多論點，但我認為他們將持續面臨這些問題，直到他們實現持續穩定（並開發交付所需的工具和基礎設施）。這需要從每個工程師開始。如果工程師不理解這是日常工作職責的一部分，那麼你就失去了支撐點。那麼替代方案的推進就會演變成施加痛苦的過程，這會破壞工程師的精神狀態，而不是啟發他們的創造力。

原文：https://hackernoon.com/windows-as-a-service-f666206233f5

作者：Terry Crowley

譯者：彎月，責編：屠敏

微信改版了，

想快速看到CSDN的熱乎文章，

趕快把CSDN公眾號設為星標吧，

打開公眾號，點擊「設為星標」就可以啦！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！