北京大學(xué)出版社96年底所出的《微軟的秘密》一書是目前我所見到的對微軟公司軟件產(chǎn)品開發(fā)過程介紹的專業(yè)、深入的一本書。通過本書，我們可以看到微軟公司是如何對科學(xué)地對軟件產(chǎn)品開發(fā)進(jìn)行有效地管理，我想這些經(jīng)驗對于中國的廣大軟件開發(fā)人員，尤其是關(guān)心中國軟件產(chǎn)業(yè)發(fā)展的各位朋友是大有益處的。所以特將此書中涉及軟件產(chǎn)品開發(fā)的部分內(nèi)容摘錄出來（第四章“產(chǎn)品定義與開發(fā)過程”），加上我在微軟中國工作的實際經(jīng)驗總結(jié)出這篇文章，希望與大家共同分享。本文作為摘錄，自然是掛一漏萬，所以建議大家若有時間還是找來原書一讀。

　　在微軟的產(chǎn)品定義與開發(fā)過程中，微軟軟件開發(fā)遵循著一種可稱之為“靠改進(jìn)特性（Feature）與固定資源（Resource）來激發(fā)創(chuàng)造力”的戰(zhàn)略。該戰(zhàn)略可分為五個原則：

　　將大項目分成若干里程碑式（Milestone）的重要階段，各階段之間有緩沖時間，但不進(jìn)行單獨的產(chǎn)品維護。 
　　運用想象描述和對特性的概要說明（Program Specification）指導(dǎo)項目。 
　　根據(jù)用戶行為（User Behavior）和有關(guān)用戶的資料確定產(chǎn)品特性及其優(yōu)先順序。 
　　建立模塊化的和水平式的設(shè)計結(jié)構(gòu)，并使項目結(jié)構(gòu)反映產(chǎn)品結(jié)構(gòu)的特點。 
　　靠個人負(fù)責(zé)和固定項目資源實施控制。 
原則一：將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時間，但不進(jìn)行單獨的產(chǎn)品維護。

項目進(jìn)度安排與里程碑 
微軟通常采用“同步－穩(wěn)定產(chǎn)品開發(fā)法”。典型項目的生命周期包括三個階段：

計劃階段：完成功能的說明和進(jìn)度表的后制定 
開發(fā)階段：寫出完整的的源代碼 
穩(wěn)定化階段：完成產(chǎn)品，使之能夠批量生產(chǎn)（Roll Out） 
這三個大階段以及階段間內(nèi)在的循環(huán)方法與傳統(tǒng)的“瀑布”（Water Fall）式開發(fā)方式很不相同，后者是由需求、詳盡設(shè)計、模塊化的代碼設(shè)計與測試、集成測試以及系統(tǒng)測試組成的。而微軟的三個階段更像是風(fēng)險驅(qū)動的、漸進(jìn)的“螺旋”式的生命周期模型。

　　計劃階段的產(chǎn)品是想象性描述與說明文件，用來解釋項目將做什么和怎么做。在管理人員擬定進(jìn)度表、開發(fā)員寫出代碼之前，這些東西都促進(jìn)了人們對設(shè)計問題的思考與討論。開發(fā)階段圍繞三次主要的內(nèi)部產(chǎn)品發(fā)布來進(jìn)行；穩(wěn)定化階段集中于廣泛的內(nèi)部與外部測試。在整個產(chǎn)品生產(chǎn)周期中，微軟都使用了緩沖時間的概念。緩沖時間使開發(fā)組能夠?qū)Ω兑馔獾睦щy和影響到時間進(jìn)度的變故，它也提供了一種手段，可以緩和及時發(fā)貨與試圖精確估計發(fā)貨時間之間的矛盾。

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

計劃階段 
　　計劃階段是在一個項目的生命周期中，所有于開發(fā)前進(jìn)行的計劃所占用的時間。計劃階段產(chǎn)生出想象性描述、市場營銷計劃、設(shè)計目標(biāo)、一份初的產(chǎn)品說明、為集成其他組開發(fā)的構(gòu)件而規(guī)定的接口標(biāo)準(zhǔn)、初的測試計劃、一個文檔策劃（印刷品和聯(lián)機幫助形式的）以及一份可用性問題清單（Usability List）。計劃階段從想象性描述開始。想象性描述來自產(chǎn)品經(jīng)理以及各產(chǎn)品單位的程序經(jīng)理；它是對規(guī)劃產(chǎn)品的市場營銷設(shè)想，包括了對競爭對手產(chǎn)品的分析以及對未來版本的規(guī)劃。想象性描述也可能討論在前一次版本中發(fā)現(xiàn)面必須解決的問題以及應(yīng)添加的主要功能。所有這些都基于對顧客和市場的分析以及從產(chǎn)品支持服務(wù)組處得到的資料。

　　說明文件從一個大綱開始，然后定義出新的或增加的產(chǎn)品特性，并對其賦以不同的優(yōu)先級。說明文件只是產(chǎn)品特性的一個預(yù)備性概覽；從開始開發(fā)到項目完成它要增加或變化20% - 30%。雖然在生命周期的后期說明變化一般較小，但越到后期，開發(fā)員越是必須具充分的理由來作改變。

　　通常程序經(jīng)理使用VB創(chuàng)建項目原型。他們也開展設(shè)計可行性研究以了解設(shè)計中的取舍情況，盡快做出涉及產(chǎn)品說明的決定。對于重要產(chǎn)品的說明需由公司高層領(lǐng)導(dǎo)進(jìn)行復(fù)審。對于不太重要的產(chǎn)品，則由部分經(jīng)理去完成。

開發(fā)階段 
　　開發(fā)階段的計劃對三四個主要的里程碑版本都逐個分配一組特性，規(guī)定出特性的細(xì)節(jié)和技術(shù)上的相關(guān)性，記錄下單個開發(fā)員的任務(wù)以及對進(jìn)度的估計。在開發(fā)階段中，開發(fā)員在功能性說明的指導(dǎo)下寫源代碼，測試員寫出測試項目組以檢查產(chǎn)品的特性與工作范圍是否正常，用戶教育人員（User Education）則編寫出文檔草案。

　　當(dāng)測試員發(fā)現(xiàn)錯誤時，開發(fā)員并不是留待以后處理，而是馬上改正，并在整個開發(fā)階段內(nèi)使測試不斷地、自動地進(jìn)行。這改善了產(chǎn)品的穩(wěn)定性并且使版本發(fā)布日期更易估計。當(dāng)達(dá)到項目中的一定階段點后（40%時），開發(fā)員試圖“鎖定”產(chǎn)品的主要功能要求或特性，從此只允許小范圍的改動。如果在此點之后開發(fā)員想作大的改動，他們必須與程序經(jīng)理以及開發(fā)經(jīng)理進(jìn)行討論協(xié)商，也許還要征求產(chǎn)品部門經(jīng)理的意見。

　　一個項目是圍繞著3或4個主要的內(nèi)部版本，或“里程碑子項目”來組織開發(fā)階段的。一般用2至4個月來開發(fā)每一個主要的里程碑版本。每個版本都包括其自身的編碼、優(yōu)化、測試以及調(diào)試活動。項目為意外事故保留總開發(fā)1/3的時間，即“緩沖時間”（Padding Time）。（蘋果公司的小組是割裂的、獨立的，各自開發(fā)各自的東西。在還有3個月要發(fā)貨時，才會將所有的東西集成起來；Borland公司以一種漸近的方式進(jìn)行開發(fā)，即把工作分成許多小的部分，并且總是讓開發(fā)的東西能夠運轉(zhuǎn)。看起來似乎這種漸進(jìn)的方法費時，但實際上幾乎沒有用過很長時間，因為這使你總是能掌握住事情真實的情況。）

　　當(dāng)對后一個主要的里程碑版本做了測試與穩(wěn)定化之后，產(chǎn)品要進(jìn)行“外觀固定”（UI Freeze），即確定產(chǎn)品的主要用戶界面，如菜單、對話框以及文件窗口等。此后有關(guān)用戶界面將不再進(jìn)行大的改動，以免引進(jìn)同步修改相應(yīng)文檔的困難。

穩(wěn)定化階段 
　　穩(wěn)定化階段著重于對產(chǎn)品的測試與調(diào)試。項目在此階段盡量不再增加新的功能，除非是競爭產(chǎn)品或者市場發(fā)生了變化。穩(wěn)定化階段也包括了緩沖時間，以應(yīng)付不可預(yù)見的問題或者延遲。

　　下面我將Micosoft開發(fā)軟件的模式用以下這張簡圖加以描述：（這張圖對微軟的測試進(jìn)行了比較詳細(xì)的描述，我個人認(rèn)為微軟的測試是Microsoft軟件產(chǎn)品開發(fā)中一個十分重要也是十分有特色的分工。這是通過在微軟將近一年的觀察和與國內(nèi)同類企業(yè)的分析，我才得出這樣的結(jié)論。大家都很明白，國內(nèi)的軟件開發(fā)商在這方面做得很不夠，尤其不重視軟件的內(nèi)部測試，在他們的思想中，可能有一個誤區(qū)：認(rèn)為測試應(yīng)該完全去由用戶去負(fù)責(zé)，其實不然，在軟件的開發(fā)流程中，軟件的測試與開發(fā)是一種“矛與盾”的關(guān)系，互為補充，缺一不可。在微軟，可能這種關(guān)系發(fā)揮到了極至：有時開發(fā)部門與測試部門互相較著勁，開發(fā)經(jīng)理和測試經(jīng)理的地位是相同的，有時甚至測試經(jīng)理的地位甚至凌駕于開發(fā)經(jīng)理之上，但他們之間沒有根本的利益沖突，只有一個共同的目標(biāo)：將產(chǎn)品的質(zhì)量提高。）

　　補充一點：（對微軟的測試流程加以簡要的描述一下）微軟內(nèi)部，專門有一個小組負(fù)責(zé)為微軟的工程師們提供日常工作和管理的工具軟件，他們是非盈利機構(gòu)，其主要任務(wù)是開發(fā)微軟內(nèi)部所需要的工具軟件：例如：

　　SLM(Source Library Tree)，源代碼管理工具，負(fù)責(zé)管理軟件開發(fā)過程中各個程序員的源碼，各個程序員負(fù)責(zé)寫自己的模塊，每天將完成的代碼Check-in到一個中央服務(wù)器的SLM樹中，這個SLM樹由預(yù)先定義好的腳本在固定的時間開始編譯，通常這個過程需要好幾個小時，所以微軟內(nèi)部根據(jù)各個項目組的情況有各自的規(guī)定：比如開發(fā)員必須在下班前（比如下午6：00）之前將當(dāng)天修改的代碼Check-in進(jìn)去，這樣SLM才開始編譯。 
　　第二天，QA組的各個測試員從服務(wù)器上下載前的一個Build開始測試，將測試的情況及時的反映到另外一個工具軟件中：RAID（Raid is a tool for entering， tracking， analyzing， and reporting product defects during development and maintenance.）.這個工具負(fù)責(zé)管理產(chǎn)品的BUG情況，每個BUG包含很多屬性：比如狀態(tài)（活動的、解決的、關(guān)閉的）、嚴(yán)重級、優(yōu)先級、哪個區(qū)域、哪個版本出現(xiàn)的、發(fā)現(xiàn)者、要將這個BUG賦給哪一個開發(fā)員等等一系列屬性。還可以根據(jù)這個工具查詢哪個開發(fā)員當(dāng)天的BUG活動的、解決的數(shù)量，哪個測試員的BUG質(zhì)量數(shù)目等等一些基本的產(chǎn)品質(zhì)量情況，這樣項目經(jīng)理可以很容易的掌握該項目的具體進(jìn)展情況。如果在項目的開發(fā)中期，發(fā)現(xiàn)的BUG數(shù)目比解決的BUG數(shù)目持續(xù)的多（意味著該產(chǎn)品的活著的BUG越來越多），可能意味著這個項目出現(xiàn)了問題，決策者可以迅速的作出相應(yīng)的決策，及時的糾正產(chǎn)品開發(fā)中出現(xiàn)的失誤（微軟曾經(jīng)有很多產(chǎn)品因為這樣的因素被Cancel了）。還有項目經(jīng)理可以根據(jù)這個工具，及時的掌握、了解每個測試員和開發(fā)員的工作狀態(tài)，這一點很重要。有很多人曾經(jīng)說過：Microsoft憑借著SLM和RAID打敗了無數(shù)的競爭對手，通過我在微軟的經(jīng)歷，我看這話一點也不假。這兩個工具確實是非常杰出的工具，微軟將它們使用到了十分藝術(shù)的程度上，對微軟的成功起著非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進(jìn)行改進(jìn)、升級，使得微軟的工程師們工作起來更加如虎添翼、虎虎生風(fēng)，這樣的企業(yè)哪有不成功的道理? 
　　在測試過程中，也不是隨便的對軟件產(chǎn)品毫無目的的瞎使用、亂使用，微軟也有一套十分先進(jìn)的方法和工具支撐著測試的每個方面：比如ATCM(　Access Test Case Management)，一種基于Test Case（測試用例）的測試管理工具承擔(dān)著這方面的工作。 
　　微軟也許正是靠著“程序員的聰明和測試員的勤奮”構(gòu)建起軟件帝國的大廈、譜寫著軟件事業(yè)的輝煌。

Product Developing Process in Microsoft

　　QA是微軟大的產(chǎn)品部門下設(shè)的一個比較專業(yè)的測試部門（Quality Assurance Dept）

項目進(jìn)度表中的緩沖時間（Padding Time） 
　　微軟使用緩沖計劃，以在高的效率與較好地對未來作預(yù)計之間求得平衡。這種應(yīng)付突發(fā)事件的時間在開發(fā)和穩(wěn)定化過程中是每一個主要里程碑的一部分。緩沖時間主要用于彌補由于對特性（Feature）的不完全理解，或者是技術(shù)困難或是由于疏忽而忘記把任務(wù)寫入進(jìn)度，或者是未料到的難題而形成的漏洞。緩沖時間有助于一個項目適應(yīng)意料之外的事件。

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

　　為了給出足夠的開發(fā)框架以使工作能持續(xù)進(jìn)行，并且能容納開發(fā)過程中出現(xiàn)的變化并保持足夠的靈活性，微軟采用想象性描述和概要的說明來指導(dǎo)項目開發(fā)，而不是在一開始努力寫出一份完整和詳細(xì)的說明。所謂想象性描述是由程序經(jīng)理和來自市場營銷組的產(chǎn)品計劃人員共同編寫的一份非常短的文件，在其中主要是定義產(chǎn)品開發(fā)的目標(biāo)（不涉及產(chǎn)品的具體細(xì)節(jié)！）。通常對一個全新的產(chǎn)品，想象性描述一般會相對較詳細(xì)，在其中還含有一份粗略的說明文件�？偟膩碚f，微軟對于想象性描述的要求是：