微軟公司軟體開發模式簡介–收集

作 者: hyenachenyao (BlueHyena) --摘自北京大學出版社出版的《微軟的秘密》一書

北
京大學出版社96年底所出的《微軟的秘密》一書是目前我所見到的對微軟公司軟體產品開發過程介紹的最專業、最深入的一本書。通過本書，我們可以看到微軟公
司是如何對科學地對軟體產品開發進行有效地管理，我想這些經驗對於中國的廣大軟體開發人員，尤其是關心中國軟體產業發展的各位朋友是大有益處的。所以特將
此書中涉及軟體產品開發的部分內容摘錄出來(第四章"產品定義與開發過程")，與大家共同分享。本文作為摘錄，自然是掛一漏萬，所以建議大家若有時間還是
找來原書一讀。

在產品定義與開發過程中，微軟遵循著一種可稱之為"靠改進特性與固定資源來激發創造力"的戰略。該戰略可分為五個原則：

一、 將大項目分成若干裡程碑式的重要階段，各階段之間有緩衝時間，但不進行單獨的產品維護。

二、運用想象描述和對特性的概要說明指導項目。

三、根據使用者行為和有關使用者的資料確定產品特性及其優先順序。

四、建立模組化的和水平式的設計結構，並使項目結構反蚋產品結構的特點。

五、靠個人負責和固定項目資源實施控制。

原則一：將大項目分成若干裡程碑式的重要階段，各階段之間有緩衝時間，但不進行單獨的產品維護。

項目進度安排與裡程碑

微
軟通常採用"同步－穩定產品開發法"。典型項目的生命週期包括三個階段：計劃階段完成功能的說明和進度表的最後制定，開發階段寫出完整的的原始碼，穩定化
階段完成產品，使之能夠批量生產。這三個大階段以及階段間內在的迴圈方法與傳統的"瀑布"式開發方式很不相同，後者是由需求、詳盡設計、模組化的代碼設計
與測試、整合測試以及系統測試組成的。而微軟的三個階段更像是風險驅動的、漸進的"螺旋"式的生命週期模型。

計劃階段的產品是想象性描述
與說明檔案，用來解釋項目將做什麼和息麼做。在管理員擬定進度表、開發員寫出代碼之前，這些東西都促進了人們對設計問題的思考與。
討論開發階段圍繞三次主要的內部產品發布來進行；稱定化階段集中於廣泛的內部與正式發行前小眾測試。在整個產品生產周期中，微軟都使用了緩衝時間的概念。緩衝時間使
開發組能夠對付意外的困難和影響到時間進度的變故，它也提供了一種手段，可以緩和及時發貨與試圖精確估計發貨時間之間的矛盾。

在開發和穩
定化階段的所有時間中，一個項目通常會將2/3的時間用於開發，1/3的時間用於穩定化。(Office部門副總裁曾這樣概述通常的進度："一般說來，在
總的進度表中，用一半的時間寫出產品，留下另一半的時間調試或應付意外事故。這樣，如果我有一個兩年的項目，我會用一年來完成事先想好的東西……如果事情
有點麻煩，我便去掉我認為不太重要的特性。")這種裡程碑式的工作過程使微軟的經理們可以清楚地瞭解產品開發過程進行到了哪一步，也使他們在開發階段的後
期有能力靈活地刪去一些產品特性以滿足發貨時期的要求。

計劃階段

計劃階段是在一個項目的生命週期中，所有於開發前進行的
計劃所佔用的時間。計劃階段產生出想象性描述、市場營銷計劃、設計目標、一份最初的產品說明、為整合其他組開發的構件而規定的介面標準、最初的測試計劃、
一個文檔策劃(印刷品和線上說明形式的)以及一份可用性問題清單。計劃階段從想象性描述開始。想象性描述來自產品經理以及各產品單位的程式經理；它是對產
品作業的市場營銷設想，包括了對競爭者產品的分析以及對示來版本的規劃。想象性描述也可能討論在前一次版本中發現面必須解決的問題以及應添加的生要功
能。所有這些都基於對顧客和市場的分析以及從產品支援服務組處得到的資料。

說明檔案從一個大綱開始，然後定義出新的或增加的產品特性，並
對其賦以不同的優先順序。說明檔案只是產品特性的一個預備性概覽；從開始開發到項目完成它要增加或變化20% -
30%。雖然在生命週期的後期說明變化一般較小，但越到後期，開發員就越是必須具充分的理由來作改變。

通常程式經理使用VB建立項目原型。他們也開展設計可行性研究以瞭解設計中的取捨情況，儘快做出涉及產品說明的決定。

對於重要產品的說明需由公司高層領導進行複審。對於不太生要的產品，則由部分經理去完成。

開發階段

開
發階段的計劃對三四個主要的裡程碑版本都個咖分配一組特性，規定出特性的 細節
和技術上的相關性，記錄下單個開發員的任務以及對進度的估計。在開發階段中 ，開
發員在功能性說明的指導下寫原始碼，測試員寫出測試專案組以栓查產品的特性 與工 作範圍是否正常，使用者教育人員則編寫出文檔草案。

當測
試員發現錯誤時，開發員並不是留待以後處理，而是馬上改正，並在整個開 發階
段內使測試不斷地、自動地進行。這就改善了產品的穩定性並且使版本發布日期 更易
估計。當達到項目中的一定階段點後(40%時)，開發員就試圖"鎖定"產品的主要功 能
要求或特性，從此只允許小的改動。如果在此點之後開發員想作大的改動，他們 必須 與程式經理以及開發經理，問題也許還要徵求產品部門經理的意見。

一
個項目是圍繞著3或4個主要的組建，或"裡程碑子項目"來組織開發階段的 。
一般用2至4個月來開發每一個主要的裡程碑版本。每個版本都包括其自身的編碼 、
最佳化、測試以及調試活動。項目為意外事故保留總開發1/3的時間，即"緩衝時間 "。
(蘋果公司的小組是割裂的，獨立的，各自開發各自的東西。在還有3個月就要發 貨時，
才會將所有的東西整合起來；Boland公司以一種漸近的方式進行開發，即把工作 分成
許多小的部分，並且總是讓開發的東西能夠運轉。看起來似乎這種漸進的方法費 時較
長，但實際上幾護沒有用過很長時間，因為這使你總是能掌握住事情真實的情況 。)

當對最後一個主要的裡程碑版本做了測試與穩定化之後，產品就要進行"外觀固定 "， 即確定產品的主要使用者介面，如菜單、對話方塊以及檔案視窗等。此後有關使用者界 面將 不再進行大的改動，以免引進同步修改相應文檔的困難。

穩定化階段

穩定化階段著重於對產品的測試與調試。項目在此階段盡量不再增加新的功能， 除非 是競爭產品或者市場發生了變化。穩定化階段也包括了緩衝時間，以應付不可預 見的 問題或者延遲。

項目進度表中的緩衝時間

微
軟使用緩衝計劃，以在最高的效率與較好地對未來作預計之間求得平衡。這種 應付
突發事件的時間在開發和穩定化過程中是每一個主要裡程碑的一部分。緩衝時間 主要
用於彌補由於對特性的不完全理解，或者是技術困難或是由於疏忽而忘記把任務 寫入
進度，或者是未料到的難題而形成的漏洞。緩衝時間有助於一個項目適應意料之 外的 事件。

原則二：運用想象性描述和對特性的概要說明指導項目

為
了給出足夠的開發架構以使工作能持續進行，並且能容納開發過程中出現的變 化並
保持足夠的靈活性，微軟採用想象性描述和概要的說明來指導項目開發，而不是 在一
開始就努力寫出一份完整和詳細的說明。所謂想象性描述是由程式經理和來自市 場營
銷組的產品計劃人員共同編寫的一份非常短的檔案，在其中主要是定義產品開發 的目
標(不涉及產品的具體細節！)。通常對一個全新的產品，想象性描述一般會相對 較詳
細，在其中還含有一份粗略的說明檔案。總的來說，微軟對於想象性描述的要求 是： 越短越好，盡量說明"產品不做什麼"(而不是"產品要做什麼"！)。

運
用想象性描述，程式經理開始編寫功能說明檔案，該檔案解釋產品的特性是什 麼以
及這些特性如何與其他特性及產品發生關係。最初它只是一個概要性的說明檔案 ，隨
著項目的進展，程式經理會隨時向其中添加更多的細節，最終的說明檔案將變得 象用
戶手冊一樣。完整的說明不只起著對產品最新功能的描述作用，而且它還是在產 品投 產與發貨之前進行測試與評估的主要依據。

想象性描述有助於決定刪除哪些特性

微軟內的各個開發組採用想象性描述協助細化產品版本的規定主題，然後以此主 題來 決定是否需要增加產品各個可能的特性。通常不要輕易改變所確定的主題，否則 可能 造成產品開發上的混亂。

編寫說明檔案

說
明檔案在產品小組的所有成員之間，產品小組之間以及產品小組與管理部門之 間起
著傳遞產品的設想與要求的作用。在說明檔案中必須清楚地描述產品特性(描述每 個特
性如何工作，外觀如何以及從使用者的角度出發如何與使用者互動。如果特性有一個 介面，
還應包括一張，以顯示出介面的效果)並賦於其相應的優先順序。程式經理據 此建
立起項目的開發起度表。此外在其中還應包括以下各項內容：用一句話表示的項 目開
發目的，關於產品是什麼與不是什麼的清單，對顧客的定義，對競爭產品的定義 ，產
品對系統的要求(包括作業系統版本、最小記憶體要求、硬碟空間、處理器速度以及 顯示 器分辯率)，對第三方(如印表機驅動程式、組件)的任何依賴性。

程式經理負責協調並"寫下"說明

程式經理應考慮以下問題：

＊這項特性的要點是什麼

＊使用者如何使用該特性

＊這項特性有意義嗎

＊該產品中或微軟的其他產品中有類似的特性嗎

＊有哪些問題補遺漏了

＊組內的交流令人滿意嗎

最終程式經理通過與組內開發人員的共同討論決定有關特性的內容，並將其 寫下來。

構造原型

構造原型是程式經理具體說明一件新產品或一個新版本的最好方法，這從許多方 面來 說都使開發前測試成為可能，尤其在可用性方面，並且有助於對與使用者互動情況 作出 好的理解，它也能使產品說明更緊湊。

微軟的開發人員通常採用VB構造使用者介面原型，但是對於構造電腦螢幕模型之類的工作，畫筆(Paintbrush)也是一個很好用的工具。

死板的說明變成有生命的檔案

說
明不應過於詳細以至限制了發明創造。在項目開發過程中，說明檔案的早期版 本會
有相當大的增加與改變。由於說明的變動可能會導致相應開發工作的極大變動， 所以
微軟通常是將精力首先集中於那些沒有什麼使用者介面的特性上，因為在完成開發 前不
必去瞭解使用者對它們有何反應，也就是說這些特性不大可能改變。然後再面對其 它特 性。

但是當產品開發到一定程式後，例如40%之後，程式經理必須嚴格控制對特性的修 改(主 要是指增加新的特性)，否則不光會造成開發延遲，而且會壓縮可用的測試時間。

原則三：根據使用者行為和有關使用者的資料確定產品牲及其優先順序

對於一個開發項目而言，如何確定最終產品中應包含什麼特性通常是比較困難的 一件 事。為此微軟採用了一個稱之為"基於行為制定計劃"的方式來進行特性選擇 與優 先 級安排。

基
於行為制定計劃法從對使用者行為，諸如寫信或做預算，做系統研究開始。然後 ，根
據某一特性在支援重要的或者是經常的使用者行為上的程式對其進行評價。這樣做 的優
點是對特性取捨的更理性的討論，對顧客想要做什麼的更好的安排，對某個給定 特性
是否方便了特定任務的更集中的辯論，可讀性更強的說明，以及在市場營銷、用 戶教 育和產品開發中更好地同步。

特性選擇和優先順序安排中的基於行為制定計劃

基
於行為制定計劃法中的關鍵點在於按使用者行為、產品特性以及行為和特性之間 的內
部聯絡來分析產品。程式經理和產品計劃者把產品試圖支援的使用者任務或方案分 成大
約20個"行為"，然後他們努力把行為(以及任何子行為)映射入微軟的現行特性和 競
爭對手產品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場部分 中去。

當說明產品的新版本時，基於行為制定計劃法協助程式經理和開發員集中他們的 精力 與創造力。向Excel之類的項目爭取在每個新版本中加入的主要行為不超過四個。 絕 大多數制性直接映射入這些行為之中。該做法使項目可以按特性對使用者的價值來 進行 分級。

通過分級，促使程式經理和開發人員都行動起來，使他們的特性支援儘可能多的 行為。 這種良性競爭對於使用者有益，同時也利於提高生產率。

為顧客行為而非產品特性懼資料

基於和為制定計划進，項目在計劃階段首先集中於和為，其次才是特性。程式經 理和 市場行銷人員並不去思考和排除他們喜愛的特性，再圍繞它們搞出想象性描述的 草案。 他們真正做的是列出一份顧客都做些什麼的清單，然後把想象性描述集中於支援 那些 行為的特性上。

以行為為中心對產品進行全面考慮

由於基於行為制定計劃法是從整個產品的觀點著眼，因此有助於在不同職能上工 作的 項目成員理解產品做什麼，以及其他產品的相應特性如何可能支援那些需要或不 需要 其他應用軟體產品的行為。

做市場營銷研究以支援基於行為制定計劃法

為支援基於行為制定計劃法，從市場營銷組來的產品經理與程式經理、開發人員 一起 開展一些聯合的研究，如指導對使用者的研究工作。然而，一般來說是產品經理做 大多 數的研究，並可使其更明確地影響微軟產品的演化。

原則四：建立模組化的和水平式的設計結構，並使項目結構反映產品結構的特點

微
軟產品設計中的一個關鍵概念是產品的基礎結構，尤其是生命週期短的應用軟 件，
應隨項目的進展變得更加單一(而不是錯綜複雜)。當開發組構造產品的第一版時 ，他
們更多地使用分級式結構，好為產品設計規定出一個最初的架構。隨著時間推移 ，他
們向單一的結構邁進，以使項目能集中於特性開發。項目需要逐漸的嗇和刪除我 ，鬃
著時間改變和發展我，以及增加產品間特性表現和運作的一致性。微軟越來越強 調不
同產品間的特性共用。共用有助於使不同產品的"效能與感覺"都統一協條起來； 它
也方便了需要不只一個應用軟體的使用者，減少了代碼的重複書寫，縮小了單獨一 個應 用軟體的規模。

微軟用特性小組組織產品開發，這種方法使得每個人都容易明白小組是如何與整 個產 品相關聯的。項目從規定概要說明開始。概要說明的形式是一份已確定了優先順序 安排 的內容清單，涉及產品下一版本將要開發的相對獨立的特性，以便由分開的特性 小組 加以開發。

程式經理和開發員把項目分成特性子集，再將之分配給每個特性小組，讓他們在 3到 4個主要的內部項目裡程碑中進行生產。這種產品組織與開發法使微軟能靠簡單地 增 加開發員和建立一個大的小組來漸進地增加產品的功能。

把特性(與函數)作為開發單位

微軟體產品的特性是使用者最終可見的相對獨立的功能單位，就如建築材料一般， 對應 用軟體產品更是如此。系統軟體產品，如NT或者95的特性，對終端使用者通常不直 接 可見。微軟和其他公司有時簡單地稱這些不直接可見的特性為"函數"。

程式經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到最後完成的 過程。 他們必須開開發員合作，後者負責估計進度表與完善每個特性。開發員還要在一 台聯 網開發電腦上儲存一到幾個檔案，用以儲存特性的程式原始碼。

大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。

產品結構是決定其長期結構完整性的基石

產
品結構是產品內部的基幹，它規定了重要的結構構件以及這些構件如何組裝到 一起。
產品結構及用於組裝結構的構件，提供了實現產品特性(即做詳細設計與編碼)的 支柱。
產品的結構對終端使用者而言，通常並非直接可見。只有結構要實現的特性是可見 的。
產品結構也是決定產品長期結構完整性的基石。產品功能的任何改變都不應造成 潛在 的產品結構散 架。

產品的階層

對
於產品，也可以採用階層的方法加以分析。通常定義良好的階層有助 於對
產品特性進行靈活的增加、刪除與改進。此外良好的階層有助於產品在不同 平台
上的移植。(例如Excel總共定義了五層，其中只有最底層的作業系統層是與平台 相關
的，其它各層均是通過調用其下層所提供的API介面加以實現的，所以其移植極其 方 便。而在Windows
95中通過"虛擬機器"的概念實現了對16位、32位以及DOS程式 的支援。)

小的結構文檔：原始碼是唯一檔案

除了
API文檔，微軟不對其產品結構產生相應的文檔，雖然有時進階開發員可能會 寫
下高層結構。對複雜的特性，許多開發員在某些點記錄並複查特定於他們所負責 的結
構細節，但此工作是可選的，並不強制執行。除了原始碼檔案與特性說明，為數 不多
的組為新程式員准務了描繪某層結構的文檔(主要的資料結構，如何工作等等)。 但是
這些檔案並不時常更新，經理們也不要求項目組產生此類內部文檔。在有關的說 明文
件中，並不涉及實現問題。開發員應該知道如何去實現，或者能夠去學會。記錄 的關
於結構的文檔如此之少是因為"一個開發員的工作是編寫我們要賣的代碼，而不是 花 時間寫高水平的設計檔案"，"設計檔案不應與原始碼分離"。

分割代碼與"保持事情的簡單"

特性小組和作為"內容專家"的小組領導

特
性小組一般由一個領導和3至8名開發人員組成，工作於相關的特性領域。小組 的
規模常常視小組領導的經驗和能力而定。特性小組領導向項目開發領導彙報並負 責薦
目的全部開發工作；而項目開發領導則擁有對產品的更為全域性的觀點，從而最 有可
能發現部部互相關聯的問題。在特性小組中的每個人均是此領域的"專家"，他們 瞭解
如何使用產品、瞭解競爭者的產品、瞭解未來將向何處去。通常為便於交流， 提高 軟體的組織圖(軟體傾向於映射出構造
它的組織的結構)，應保持特性小組的小 規 模。

原則五：靠個人負責和固定項目資源實旋控制

對
於軟體項目而言，精確估計產品的開發與交付進度是很困難的。對此微軟採取 的方
法是將進度安排和工作管理的責任推到最底層，即單個的開發人員和測試人員那 兒去。
這保證了每個人除了作為小組的一部分外，還負有個人的責任。單獨的開發人員 設立
他們自已的進度表，程式經理把單獨的進度表匯總起來，再加上緩衝時間，以制 定出
一個全面的項目進度表。頂層的總經理也固定人員與時間等基本資源，以確保項 目集 中並限制其努力與創造程式。

關鍵的目標，尤其對應用軟
件，是指明產品的目標出品日並爭取儘可能長久地堅 持它。 程式經理和開發員從出品日回溯，規定中間的項目裡程碑的日期。這個"固定的出 品
日"法的中心在開發員身上。以避免因為項目沒有固定的結束點，導致在最終無用 的 設計、再設計和測試的迴圈中消耗一年或更多的時間。

開發人員做出他們自已的進度估計

比
爾犯譴那康魑⑷砣每⒃焙托∽檣瓚ㄋ親砸訓哪勘輳骸八姓廡┤掌詼際切 ∽槎ǖ
娜掌凇Ｃ揮釁淥速彩醞忌瓚ㄕ飧鋈掌凇Ｎ頤竊詿笤?0年前就拋棄了那種自目而 下的
日期設定方法"。但是開發人員一般會做出較樂觀的估計，因此開發經理還需對他 們所
提供的日期進行調整並加上緩衝時間以避免因因資訊不完全而出現的問題。微軟 這種
制定進度的方法的優點在於：它從人們那兒得到更多的合作，因為日期是自已定 的，
不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正 需要 的進間。

對細緻的任務的進度估計

微軟的第二個進度排方法是，對要完成之任務做非常詳盡的考慮，在此基礎上請 開發 人員給出他們對"實現"的估計，以此力圖"促使"更加現實主義並避免過度低估。

通
常微軟把任務細化到4小時(半天)到3天之間。對於準確進度的安排，微軟的經 理
是這樣認識的："任何任務只要超過一星期，那人們就一定沒有充分地全盤考慮它 。任
何任務某人估計只用少於半天就可完成，則他對它考慮得太多了。他應該用列多 的時 間去編程，更少的時間來考慮。"對於類似類於Windows
NT之類的作業系統而言， 進 度安排更加困難，對其一般以幾天或者半周為工作單位進行進度估計。

安排開發人員與小組進度時的心理學

當
項目變大時，微軟把員工分成小組。然後經理把進度的責任和所有權儘可能地 分發
下去，直到小組和個人；這使二者都產生了一種擁用工作的感覺。它還在小組中 ，個
人中，尤其是小組領導中造成強烈的跟上其它同事預計進度的壓力，因為經理可 能再
平衡進度，從落後的小組或個人手中拿走工作。這樣，同事間的壓力使經理不需 要太 多的努力就可以對個人或單個小組的進程實施嚴格控制。

"固定的"出品日

為
了把創造力約束在時間限制之中，微軟現在在新產品或者產品新版本開始前爭 取固
定出品日，至少是有出品日的內部目標。這給人們施加砍去特性和集中在一個項 目上
的壓力，逼迫他們去苦苦思考應將那個新特性加入產品中。雖然最終產品的交付 目標
可能是由進階執行人員設定，但是開發人員與小組仍然設定他們自已的進度表。

附錄：同步－穩定開發法

計劃階段

定義產品的想象性描述、說明與進度

＊想象性描述 產品和程式管理部門運用廣泛的顧客意見來確定和最佳化產品的 特性。

＊ 說明檔案 基於想象性描述，程式管理部門與開發組定義特性的功能寮殃，結 構問題， 以及各部分間的相關性。

＊ 制訂進度表與構造特性小組　其於說明檔案，程式管理部門協調進度表，安排 出特 性小組，每個小組包括大約1名程式經理，3 - 8個開發員，3 - 8個測試員(以1: 1比例 與開發員平行工作。)

開發階段

用3 - 4個順序的子項目，每個產生一個裡程碑式的產品發送，來完成特性的 開發。

程式經理協調開發過程。

開發員設計、編碼、調試。測試員與開發員配對，不斷進行測試。　

＊子項目Ⅰ 前1/3的特性：最重要的特性與共用的構件。

＊子項目Ⅱ 中間1/3的特性。

＊子項目Ⅲ 最後1/3的特性：最不重要的特性。

穩定化階段

全面的內正式發行前小眾測試，最後的產品穩定化以及發貨。

程式經理協調OEM與ISV，監督從顧客得到的資訊反饋。開發員進行最後的調試與

代碼穩定化。測試員發現並清除錯誤。

＊自我裝載 公司內部對整個產品做詳盡的測試。

＊ 正式發行前小眾測試 公司外在的"β"測試點，象OEM，ISV以及終端使用者處對整個產品做

詳盡的測試。

＊發貨準備 為批量生產準備發布最後的"金盤"與文檔。

來源:．網易虛擬社區 http://club.netease.com．[FROM: 210.72.251.139]