微軟公司軟件開(kāi)發(fā)模式簡(jiǎn)介
北京大學(xué)出版社96年底所出的《微軟的秘密》一書(shū)是目前我所見(jiàn)到的對微軟公司軟件產(chǎn)品開(kāi)發(fā)過(guò)程介紹的最專(zhuān)業(yè)、最深入的一本書(shū)。通過(guò)本書(shū)，我們可以看到微軟公司是如何對科學(xué)地對軟件產(chǎn)品開(kāi)發(fā)進(jìn)行有效地管理，我想這些經(jīng)驗對于中國的廣大軟件開(kāi)發(fā)人員，尤其是關(guān)心中國軟件產(chǎn)業(yè)發(fā)展的各位朋友是大有益處的。所以特將此書(shū)中涉及軟件產(chǎn)品開(kāi)發(fā)的部分內容摘錄出來(lái)(第四章“產(chǎn)品定義與開(kāi)發(fā)過(guò)程”)，加上我在微軟中國工作的實(shí)際經(jīng)驗總結出這篇文章，希望與大家共同分享。本文作為摘錄，自然是掛一漏萬(wàn)，所以建議大家若有時(shí)間還是找來(lái)原書(shū)一讀。
在微軟的產(chǎn)品定義與開(kāi)發(fā)過(guò)程中，微軟軟件開(kāi)發(fā)遵循著(zhù)一種可稱(chēng)之為“靠改進(jìn)特性(Feature)與固定資源(Resource)來(lái)激發(fā)創(chuàng )造力”的戰略。該戰略可分為五個(gè)原則：
將大項目分成若干里程碑式(Milestone)的重要階段，各階段之間有緩沖時(shí)間，但不進(jìn)行單獨的產(chǎn)品維護。
運用想象描述和對特性的概要說(shuō)明(Program Specification)指導項目。
根據用戶(hù)行為(User Behavior)和有關(guān)用戶(hù)的資料確定產(chǎn)品特性及其優(yōu)先順序。
建立模塊化的和水平式的設計結構，并使項目結構反映產(chǎn)品結構的特點(diǎn)。
靠個(gè)人負責和固定項目資源實(shí)施控制。
原則一：將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時(shí)間，但不進(jìn)行單獨的產(chǎn)品維護。
項目進(jìn)度安排與里程碑
微軟通常采用“同步-穩定產(chǎn)品開(kāi)發(fā)法”。典型項目的生命周期包括三個(gè)階段：
計劃階段：完成功能的說(shuō)明和進(jìn)度表的最后制定
開(kāi)發(fā)階段：寫(xiě)出完整的的源代碼
穩定化階段：完成產(chǎn)品，使之能夠批量生產(chǎn)(Roll Out)
這三個(gè)大階段以及階段間內在的循環(huán)方法與傳統的“瀑布”(Water Fall)式開(kāi)發(fā)方式很不相同，后者是由需求、詳盡設計、模塊化的代碼設計與測試、集成測試以及系統測試組成的。而微軟的三個(gè)階段更像是風(fēng)險驅動(dòng)的、漸進(jìn)的“螺旋”式的生命周期模型。
計劃階段的產(chǎn)品是想象性描述與說(shuō)明文件，用來(lái)解釋項目將做什么和怎么做。在管理人員擬定進(jìn)度表、開(kāi)發(fā)員寫(xiě)出代碼之前，這些東西都促進(jìn)了人們對設計問(wèn)題的思考與討論。開(kāi)發(fā)階段圍繞三次主要的內部產(chǎn)品發(fā)布來(lái)進(jìn)行；穩定化階段集中于廣泛的內部與外部測試。
在整個(gè)產(chǎn)品生產(chǎn)周期中，微軟都使用了緩沖時(shí)間的概念。緩沖時(shí)間使開(kāi)發(fā)組能夠對付意外的困難和影響到時(shí)間進(jìn)度的變故，它也提供了一種手段，可以緩和及時(shí)發(fā)貨與試圖精確估計發(fā)貨時(shí)間之間的矛盾。
在開(kāi)發(fā)和穩定化階段的所有時(shí)間中，一個(gè)項目通常會(huì )將2/3的時(shí)間用于開(kāi)發(fā)，1/3的時(shí)間用于穩定化。(Office部門(mén)副總裁曾這樣概述通常的進(jìn)度：“一般說(shuō)來(lái)，在總的進(jìn)度表中，用一半的時(shí)間寫(xiě)出產(chǎn)品，留下另一半的時(shí)間調試或應付意外事故。這樣，如果我有一個(gè)兩年的項目，我會(huì )用一年來(lái)完成事先想好的東西……如果事情有點(diǎn)麻煩，我便去掉我認為不太重要的特性?！?。這種里程碑式的工作過(guò)程使微軟的經(jīng)理們可以清楚地了解產(chǎn)品開(kāi)發(fā)過(guò)程進(jìn)行到了哪一步，也使他們在開(kāi)發(fā)階段的后期有能力靈活地刪去一些產(chǎn)品特性以滿(mǎn)足發(fā)貨時(shí)期的要求。
計劃階段
計劃階段是在一個(gè)項目的生命周期中，所有于開(kāi)發(fā)前進(jìn)行的計劃所占用的時(shí)間。計劃階段產(chǎn)生出想象性描述、市場(chǎng)營(yíng)銷(xiāo)計劃、設計目標、一份最初的產(chǎn)品說(shuō)明、為集成其他組開(kāi)發(fā)的構件而規定的接口標準、最初的測試計劃、一個(gè)文檔策劃(印刷品和聯(lián)機幫助形式的)以及一份可用性問(wèn)題清單(Usability List)。計劃階段從想象性描述開(kāi)始。想象性描述來(lái)自產(chǎn)品經(jīng)理以及各產(chǎn)品單位的程序經(jīng)理；它是對規劃產(chǎn)品的市場(chǎng)營(yíng)銷(xiāo)設想，包括了對競爭對手產(chǎn)品的分析以及對未來(lái)版本的規劃。想象性描述也可能討論在前一次版本中發(fā)現面必須解決的問(wèn)題以及應添加的主要功能。所有這些都基于對顧客和市場(chǎng)的分析以及從產(chǎn)品支持服務(wù)組處得到的資料。
說(shuō)明文件從一個(gè)大綱開(kāi)始，然后定義出新的或增加的產(chǎn)品特性，并對其賦以不同的優(yōu)先級。說(shuō)明文件只是產(chǎn)品特性的一個(gè)預備性概覽；從開(kāi)始開(kāi)發(fā)到項目完成它要增加或變化20%-30%。雖然在生命周期的后期說(shuō)明變化一般較小，但越到后期，開(kāi)發(fā)員就越是必須具充分的理由來(lái)作改變。
通常程序經(jīng)理使用VB創(chuàng )建項目原型。他們也開(kāi)展設計可行性研究以了解設計中的取舍情況，盡快做出涉及產(chǎn)品說(shuō)明的決定。對于重要產(chǎn)品的說(shuō)明需由公司高層領(lǐng)導進(jìn)行復審。對于不太重要的產(chǎn)品，則由部分經(jīng)理去完成。
開(kāi)發(fā)階段
開(kāi)發(fā)階段的計劃對三四個(gè)主要的里程碑版本都逐個(gè)分配一組特性，規定出特性的細節和技術(shù)上的相關(guān)性，記錄下單個(gè)開(kāi)發(fā)員的任務(wù)以及對進(jìn)度的估計。在開(kāi)發(fā)階段中，開(kāi)發(fā)員在功能性說(shuō)明的指導下寫(xiě)源代碼，測試員寫(xiě)出測試項目組以檢查產(chǎn)品的特性與工作范圍是否正常，用戶(hù)教育人員(User Education)則編寫(xiě)出文檔草案。
當測試員發(fā)現錯誤時(shí)，開(kāi)發(fā)員并不是留待以后處理，而是馬上改正，并在整個(gè)開(kāi)發(fā)階段內使測試不斷地、自動(dòng)地進(jìn)行。這就改善了產(chǎn)品的穩定性并且使版本發(fā)布日期更易估計。當達到項目中的一定階段點(diǎn)后(40%時(shí))，開(kāi)發(fā)員就試圖“鎖定”產(chǎn)品的主要功能要求或特性，從此只允許小范圍的改動(dòng)。如果在此點(diǎn)之后開(kāi)發(fā)員想作大的改動(dòng)，他們必須與程序經(jīng)理以及開(kāi)發(fā)經(jīng)理進(jìn)行討論協(xié)商，也許還要征求產(chǎn)品部門(mén)經(jīng)理的意見(jiàn)。
一個(gè)項目是圍繞著(zhù)3或4個(gè)主要的內部版本，或“里程碑子項目”來(lái)組織開(kāi)發(fā)階段的。一般用2至4個(gè)月來(lái)開(kāi)發(fā)每一個(gè)主要的里程碑版本。每個(gè)版本都包括其自身的編碼、優(yōu)化、測試以及調試活動(dòng)。項目為意外事故保留總開(kāi)發(fā)1/3的時(shí)間，即“緩沖時(shí)間”(Padding Time)。(蘋(píng)果公司的小組是割裂的、獨立的，各自開(kāi)發(fā)各自的東西。在還有3個(gè)月就要發(fā)貨時(shí)，才會(huì )將所有的東西集成起來(lái)；Borland公司以一種漸近的方式進(jìn)行開(kāi)發(fā)，即把工作分成許多小的部分，并且總是讓開(kāi)發(fā)的東西能夠運轉?？雌饋?lái)似乎這種漸進(jìn)的方法費時(shí)，但實(shí)際上幾乎沒(méi)有用過(guò)很長(cháng)時(shí)間，因為這使你總是能掌握住事情真實(shí)的情況。)
當對最后一個(gè)主要的里程碑版本做了測試與穩定化之后，產(chǎn)品就要進(jìn)行“外觀(guān)固定”(UI Freeze)，即確定產(chǎn)品的主要用戶(hù)界面，如菜單、對話(huà)框以及文件窗口等。此后有關(guān)用戶(hù)界面將不再進(jìn)行大的改動(dòng)，以免引進(jìn)同步修改相應文檔的困難。
穩定化階段
穩定化階段著(zhù)重于對產(chǎn)品的測試與調試。項目在此階段盡量不再增加新的功能，除非是競爭產(chǎn)品或者市場(chǎng)發(fā)生了變化。穩定化階段也包括了緩沖時(shí)間，以應付不可預見(jiàn)的問(wèn)題或者延遲。
下面我將Micosoft開(kāi)發(fā)軟件的模式用以下這張簡(jiǎn)圖加以描述：(這張圖對微軟的測試進(jìn)行了比較詳細的描述，我個(gè)人認為微軟的測試是 Microsoft軟件產(chǎn)品開(kāi)發(fā)中一個(gè)十分重要也是十分有特色的分工。這是通過(guò)在微軟將近一年的觀(guān)察和與國內同類(lèi)企業(yè)的分析，我才得出這樣的結論。大家都很明白，國內的軟件開(kāi)發(fā)商在這方面做得很不夠，尤其不重視軟件的內部測試，在他們的思想中，可能有一個(gè)誤區：認為測試應該完全去由用戶(hù)去負責，其實(shí)不然，在軟件的開(kāi)發(fā)流程中，軟件的測試與開(kāi)發(fā)是一種“矛與盾”的關(guān)系，互為補充，缺一不可。在微軟，可能這種關(guān)系發(fā)揮到了極至：有時(shí)開(kāi)發(fā)部門(mén)與測試部門(mén)互相較著(zhù)勁，開(kāi)發(fā)經(jīng)理和測試經(jīng)理的地位是相同的，有時(shí)甚至測試經(jīng)理的地位甚至凌駕于開(kāi)發(fā)經(jīng)理之上，但他們之間沒(méi)有根本的利益沖突，只有一個(gè)共同的目標：將產(chǎn)品的質(zhì)量提高。)
補充一點(diǎn)：(對微軟的測試流程加以簡(jiǎn)要的描述一下)微軟內部，專(zhuān)門(mén)有一個(gè)小組負責為微軟的工程師們提供日常工作和管理的工具軟件，他們是非盈利機構，其主要任務(wù)是開(kāi)發(fā)微軟內部所需要的工具軟件：
例如：SLM(Source Library Tree)，源代碼管理工具，負責管理軟件開(kāi)發(fā)過(guò)程中各個(gè)程序員的源碼，各個(gè)程序員負責寫(xiě)自己的模塊，每天將完成的代碼Check-in到一個(gè)中央服務(wù)器的SLM樹(shù)中，這個(gè)SLM樹(shù)由預先定義好的腳本在固定的時(shí)間開(kāi)始編譯，通常這個(gè)過(guò)程需要好幾個(gè)小時(shí)，所以微軟內部根據各個(gè)項目組的情況有各自的規定：比如開(kāi)發(fā)員必須在下班前(比如下午6：00)之前將當天修改的代碼Check-in進(jìn)去，這樣SLM才開(kāi)始編譯。
第二天，QA組的各個(gè)測試員從服務(wù)器上下載前一天的一個(gè)Build開(kāi)始測試，將測試的情況及時(shí)的反映到另外一個(gè)工具軟件中：RAID(Raid is a tool for entering，tracking，analyzing，and reporting product defects during development and maintenance.)。這個(gè)工具負責管理產(chǎn)品的BUG情況，每個(gè)BUG包含很多屬性：比如狀態(tài)(活動(dòng)的、解決的、關(guān)閉的)、嚴重級、優(yōu)先級、哪個(gè)區域、哪個(gè)版本出現的、發(fā)現者、要將這個(gè)BUG賦給哪一個(gè)開(kāi)發(fā)員等等一系列屬性。還可以根據這個(gè)工具查詢(xún)哪個(gè)開(kāi)發(fā)員當天的BUG活動(dòng)的、解決的數量，哪個(gè)測試員的BUG質(zhì)量數目等等一些基本的產(chǎn)品質(zhì)量情況，這樣項目經(jīng)理可以很容易的掌握該項目的具體進(jìn)展情況。如果在項目的開(kāi)發(fā)中期，發(fā)現的BUG數目比解決的 BUG數目持續的多(意味著(zhù)該產(chǎn)品的活著(zhù)的BUG越來(lái)越多)，可能意味著(zhù)這個(gè)項目出現了問(wèn)題，決策者可以迅速的作出相應的決策，及時(shí)的糾正產(chǎn)品開(kāi)發(fā)中出現的失誤(微軟曾經(jīng)有很多產(chǎn)品因為這樣的因素被Cancel了)。還有項目經(jīng)理可以根據這個(gè)工具，及時(shí)的掌握、了解每個(gè)測試員和開(kāi)發(fā)員的工作狀態(tài)，這一點(diǎn)很重要。有很多人曾經(jīng)說(shuō)過(guò)：Microsoft憑借著(zhù)SLM和RAID打敗了無(wú)數的競爭對手，通過(guò)我在微軟的經(jīng)歷，我看這話(huà)一點(diǎn)也不假。
這兩個(gè)工具確實(shí)是非常杰出的工具，微軟將它們使用到了十分藝術(shù)的程度上，對微軟的成功起著(zhù)非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進(jìn)行改進(jìn)、升級，使得微軟的工程師們工作起來(lái)更加如虎添翼、虎虎生風(fēng)，這樣的企業(yè)哪有不成功的道理？
在測試過(guò)程中，也不是隨便的對軟件產(chǎn)品毫無(wú)目的的瞎使用、亂使用，微軟也有一套十分先進(jìn)的方法和工具支撐著(zhù)測試的每個(gè)方面：比如ATCM (Access Test Case Management)，一種基于Test Case(測試用例)的測試管理工具就承擔著(zhù)這方面的工作。
微軟也許正是靠著(zhù)“程序員的聰明和測試員的勤奮”構建起軟件帝國的大廈、譜寫(xiě)著(zhù)軟件事業(yè)的輝煌。
項目進(jìn)度表中的緩沖時(shí)間(Padding Time)
微軟使用緩沖計劃，以在最高的效率與較好地對未來(lái)作預計之間求得平衡。這種應付突發(fā)事件的時(shí)間在開(kāi)發(fā)和穩定化過(guò)程中是每一個(gè)主要里程碑的一部分。緩沖時(shí)間主要用于彌補由于對特性(Feature)的不完全理解，或者是技術(shù)困難或是由于疏忽而忘記把任務(wù)寫(xiě)入進(jìn)度，或者是未料到的難題而形成的漏洞。緩沖時(shí)間有助于一個(gè)項目適應意料之外的事件。
原則二：運用想象性描述和對特性的概要說(shuō)明指導項目
為了給出足夠的開(kāi)發(fā)框架以使工作能持續進(jìn)行，并且能容納開(kāi)發(fā)過(guò)程中出現的變化并保持足夠的靈活性，微軟采用想象性描述和概要的說(shuō)明來(lái)指導項目開(kāi)發(fā)，而不是在一開(kāi)始就努力寫(xiě)出一份完整和詳細的說(shuō)明。所謂想象性描述是由程序經(jīng)理和來(lái)自市場(chǎng)營(yíng)銷(xiāo)組的產(chǎn)品計劃人員共同編寫(xiě)的一份非常短的文件，在其中主要是定義產(chǎn)品開(kāi)發(fā)的目標(不涉及產(chǎn)品的具體細節！)。通常對一個(gè)全新的產(chǎn)品，想象性描述一般會(huì )相對較詳細，在其中還含有一份粗略的說(shuō)明文件?？偟膩?lái)說(shuō)，微軟對于想象性描述的要求是：
越短越好，盡量說(shuō)明產(chǎn)品不做什么(而不是產(chǎn)品要做什么！)。
運用想象性描述，程序經(jīng)理開(kāi)始編寫(xiě)功能說(shuō)明文件，該文件解釋產(chǎn)品的特性是什么以及這些特性如何與其他特性及產(chǎn)品發(fā)生關(guān)系。最初它只是一個(gè)概要性的說(shuō)明文件，隨著(zhù)項目的進(jìn)展，程序經(jīng)理會(huì )隨時(shí)向其中添加更多的細節，最終的說(shuō)明文件將變得象用戶(hù)手冊一樣。
完整的說(shuō)明不只起著(zhù)對產(chǎn)品最新功能的描述作用，而且它還是在產(chǎn)品投產(chǎn)與發(fā)貨之前進(jìn)行測試與評估的主要依據。
想象性描述有助于決定刪除哪些特性。
微軟內的各個(gè)開(kāi)發(fā)組采用想象性描述幫助細化產(chǎn)品版本的規定主題，然后以此主題來(lái)決定是否需要增加產(chǎn)品各個(gè)可能的特性。通常不要輕易改變所確定的主題，否則可能造成產(chǎn)品開(kāi)發(fā)上的混亂。
編寫(xiě)說(shuō)明文件
說(shuō)明文件在產(chǎn)品小組的所有成員之間，產(chǎn)品小組之間以及產(chǎn)品小組與管理部門(mén)之間起著(zhù)傳遞產(chǎn)品的設想與要求的作用。在說(shuō)明文件中必須清楚地描述產(chǎn)品特性(描述每個(gè)特性如何工作，外觀(guān)如何以及從用戶(hù)的角度出發(fā)如何與用戶(hù)交互。如果特性有一個(gè)界面，還應包括一張示意圖，以顯示出界面的效果)，并賦于其相應的優(yōu)先級。程序經(jīng)理?yè)私⑵痦椖康拈_(kāi)發(fā)進(jìn)度表。此外在其中還應包括以下各項內容：用一句話(huà)表示的項目開(kāi)發(fā)目的，關(guān)于產(chǎn)品是什么與不是什么的清單，對顧客的定義，對競爭產(chǎn)品的定義，產(chǎn)品對系統的要求(包括操作系統版本、最小內存要求、硬盤(pán)空間、處理器速度以及顯示器分辯率)，對第三方(如打印機驅動(dòng)程序、組件)的任何依賴(lài)性。程序經(jīng)理負責協(xié)調并寫(xiě)下說(shuō)明
程序經(jīng)理(Program Manager)應考慮以下問(wèn)題：
這項特性的要點(diǎn)是什么？
用戶(hù)如何使用該特性？
這項特性有意義嗎？
該產(chǎn)品中或微軟的其他產(chǎn)品中有類(lèi)似的特性嗎？
有哪些問(wèn)題被遺漏了？
組內的交流令人滿(mǎn)意嗎？
最終程序經(jīng)理通過(guò)與組內開(kāi)發(fā)人員的共同討論決定有關(guān)特性的內容，并將其寫(xiě)下來(lái)。
聯(lián)系客服
