微軟軟體研發策略轉變之路 從瀑布式走向敏捷開發

　　長久以來，身為“軟體開發商”的微軟的名聲並不太好，倒不是人們對微軟的軟體產品不滿意，而是其更新週期太過漫長，比如Office、Windows、SQL Server和Exchange等主打產品的更新週期都長達3年左右，這其中的主要原因就是微軟在軟體專案的開發中採用了瀑布式開發模式。但隨著使用者對軟體的需求越來越苛刻，瀑布式開發模式已經難以滿足新型軟體的開發要求，而微軟也不得不改變自己的軟體研發策略。

　　國外科技媒體Arstechnica日前發文對微軟軟體研發策略的轉變之路進行了分析。

　　以下是文章的主要內容：

　　在大部分人的印象裡，微軟的新版本軟體好像很少按照既定時間釋出（Windows 95、Windows 2000和Windows Vista均延期釋出），而微軟本身也很少就軟體延期釋出正式的官方宣告，所以此時關於微軟的各種傳聞、假設和猜測似乎已經成了慣例。儘管如此，微軟仍然取得了巨大的成功，因為許多競爭對手的情況也大同小異，大家針對付費軟體的更新速度都比較慢，所以微軟也就顯得沒有那麼突兀了。

　　瀑布式開發模式

　　客觀地講，延期釋出在大型軟體專案的開發中非常普遍，畢竟這其中充滿了各種未知的複雜因素，而目前尚未出現一套行之有效的方法來對此進行管理，所以許多軟體專案最終都很難在既定的時間和預算內完成開發。針對這種情況，許多計算機領域的科學家和工程師嘗試了多種正規化的方法來改善軟體開發的流程，這其中就包括微軟和大部分軟體企業普遍使用的瀑布式開發模式。

　　瀑布式開發模式將軟體開發的過程分為系統計劃、需求分析、系統設計、系統編碼、系統測試、系統執行和維護6個階段，每一階段工作的完成是下一階段工作開始的前提，每一階段都要進行嚴格的評審，保證各階段的工作做得足夠好時才允許進入下一階段。

　　瀑布式開發模式在上世紀70年代被正式命名之後就備受爭議，儘管有不少公司在軟體開發中使用該模型，但它一直未能獲得業界的廣泛認可，相反，還有許多業內人士該模型是造成軟體開發延期或失敗的主要原因。

　　儘管如此，瀑布式開發模式在如今的製造業和建築業領域中應用仍然非常廣泛，因為這兩個行業中的專案進度大多是不可逆的，所以使用這套略顯刻板的模型反而能夠避免一些不必要的成本支出。

　　相比之下，軟體專案在後期進行修改的成本要比一棟樓簡單許多，同時軟體開發過程中的不確定因素也要更多一些，所以許多軟體專案往往會在某一階段的開發完成之後再對需求做出修改，這顯然與瀑布式開發模式的理念是相悖的。

　　瀑布式開發模式在微軟的應用

　　雖然微軟在軟體開發中並沒有使用純粹意義上的瀑布式開發模式（部分開發過程有所反覆），但總體上來說還是沿用了瀑布式開發流程，其中的一個代表作的就是Visual Studio。

　　相對於Windows和Office等軟體3年的更新週期來說，Visual Studio的版本更新速度要稍快一些，為兩年左右。這兩年通常會被分成若干個階段，其中軟件的規劃和設計工作要佔到4到6個月，之後是6到8周的程式碼編寫和為期4個月的測試階段，接下來如果出現較大的需求變更，就需要6到8周的時間來進行第二輪的程式碼編寫和4個月的第二輪測試，如果無需大的調整，則進入到4個月的穩定期直到產品最終釋出。

　　從中不難看出，即便在需求發生變更的情況下，軟體程式碼的編寫時間也不過只有4個月，而軟體測試階段所需的時間卻是程式碼編寫的兩倍左右，多少有些本末倒置。

　　其實微軟的組織結構也符合瀑布式開發模式的要求，其在軟體開發專案中主要有三個角色，分別是負責功能說明和設計的專案經理、負責程式碼編寫的開發人員以及負責功能實現的質保人員，這三個角色在管理架構上屬於平級，三方相互合作和制約來完成一個軟體專案的開發。

　　上述的這種開發流程和架構看似很是嚴謹，但操作起來卻不甚理想。舉例來說，當某個使用者安裝了Visual Studio的Beta版本並進行了1個月的測試之後發現並提交了其中的一個Bug，而此時對於開發人員來說，是應該對這個Bug進行修復的，但由於此時軟體的開發已經進入尾聲，所以如果這個Bug比較嚴重的話，可能就只能到下一個版本的開發階段再對其進行修復，這顯然會影響該軟體的最終質量。

　　敏捷開發模式

　　網路的逐漸興起開始對軟體交付模式產生巨大影響，使用者是在體驗某款軟體時無需再將其安裝到本地計算機上，只需訪問某個網站就能夠體驗到具體的外觀和功能，這對於軟體測試來說無疑是非常方便的。也正是在這個時候，“敏捷開發”模式開始出現在軟體開發領域之中。

　　“敏捷開發”一詞最早出現在上世紀的90年代，並在2001年被正式定名，當時一組開發人員公佈了所謂的“敏捷開發宣言”：“個體和互動勝過過程和工具、可以工作的軟體勝過面面俱到的文件、客戶合作勝過合同談判、響應變化勝過遵循計劃、雖然右邊的項也具有價值，但我們認為左邊的項具有更大的價值。”

　　簡單的說，敏捷開發是一種以使用者需求進化為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

　　很顯然，敏捷開發與瀑布式開發有著質的區別，前者採用了“迭代式”的開發模式，事先並不先入為主地確定使用者的需求，而是先做一些原型試驗品來讓那些關鍵使用者去體驗，然後再根據使用者的反饋意見不斷做修改和調整。在整個研發流程中，產品的最初設想和最終設計往往是不相同的。

　　敏捷開發模式在微軟的應用

　　微軟的Visual Studio團隊是公司內部首個採用敏捷開發模式的研發團隊，儘管最初微軟內部仍然以使用瀑布式開發模式，但由於Visual Studio的第三方開發者強烈要求使用敏捷開發模式，所以微軟的研發部門不得不做出改變，這也為敏捷開發模式在Visual Studio中的應用鋪平了道路。

　　Visual Studio 2010是首個因敏捷開發模式而受益的Visual Studio版本，該軟體釋出於2010年4月，當時同樣耗費了兩年的時間完成開發，但隨後研發團隊就發現軟體中的許多模板對於敏捷開發者來說太過籠統，幾乎沒有太大的實際意義。針對這種情況，微軟的研發部門推出了鼎鼎大名的Team Foundation Server（TFS），這個功能強大的伺服器平臺能為微軟的產品提供原始碼管理、資料收集、定義工作流程和管理專案進度等，而微軟的軟體研發策略也就從此開始發生巨大變化，以往兩到三年的產品更新週期逐漸變得更短，軟體開發的流程也變得更加靈活高效，而敏捷開發模式也開始在微軟內部流行開來

　　儘管敏捷開發模式已被證明是非常高效的軟體開發模式，但在微軟這種規模龐大的公司中推行起來還是頗為困難的，微軟擁有大量的軟體開發者，其中僅研發部門的員工就在3000人以上，同時還有數百個研發團隊，所以要想讓大家從早已習以為常的瀑布式開發模式轉換為敏捷開發模式，其難度不亞於“壯士斷腕”。

　　然而，微軟的管理層已經意識到敏捷開發模式對於公司未來發展的重要性，於是開始積極地制定各種措施來推動這一模式在各個研發團隊進行普及，其中包括知識培訓、改變研發團隊組織結構、建立新的層級彙報機制等等，這都在一定程度上盤活了微軟內部的研發資源，明顯提升了產品的研發進度。以Visual Studio為例，目前的版本更新速度已經縮短至一個季度左右，這在瀑布式開發模式下是難以想象的。

　　“保守”的微軟Office

　　Office應該算是微軟最為傳統的應用軟體了，由於該軟體擁有非常廣泛的使用者群，所以微軟在Office的開發策略上相對比較保守，而Office使用者也大多不喜歡比較頻繁的版本更新，因為這樣可能會打亂他們既有的工作流程。

　　但是，微軟另闢蹊徑地鼓勵使用者轉向Office 365訂閱服務，該服務為使用者提供定期的版本更新以及新的功能。同時，微軟的iPad版Office團隊在進行產品研發時也採用了敏捷開發模式，通過定期產品迭代來為使用者帶來更棒的使用體驗。

　　就目前情況而言，微軟是否會將敏捷開發模式應用到桌面版Office的研發中還不確定，但至少微軟已經主動進行了若干嘗試，雖然公司並未改變Office為期3年的產品更新週期，但微軟也承認如今的使用者期待獲得更多的功能，所以未來微軟會通過其他方式來滿足使用者的需求。由此不難看出，一旦微軟發現敏捷開發模式能夠為使用者帶來更棒的使用體驗的話，那麼完全有可能在未來數年內拋棄瀑布式開發模式。

　　結語

　　對於微軟的使用者來說，敏捷開發模式為Visual Studio的開發而帶來的改進是顯而易見的，每隔數月該產品就能進行一些版本更新（網路版的更新速度更快），這無疑將會吸引更多的開發者積極加入到Visual Studio的陣營中來，從而實現良性迴圈。

　　而微軟也在內部大力推動敏捷開發模式的進展，畢竟這種模式明顯提升了軟體專案研發的速度和質量，同時該模式所帶來的優質體驗也讓使用者變得更加忠誠，所以我們有理由相信敏捷開發模式未來將會在微軟逐漸普及，並推動這家軟體巨頭打造出更為優秀的應用軟體。

　　譯者：璞玉