1、精選優質文檔-傾情為你奉上微軟公司軟件開發模式簡介(上)北京大學出版社96年底所出的微軟的秘密一書是目前我所見到的對微軟公司軟件產品開發過程介紹的最專業、最深入的一本書。通過本書，我們可以看到微軟公司是如何對科學地對軟件產品開發進行有效地管理，我想這些經驗對于中國的廣大軟件開發人員，尤其是關心中國軟件產業發展的各位朋友是大有益處的。所以特將此書中涉及軟件產品開發的部分內容摘錄出來（第四章“產品定義與開發過程”），加上我在微軟中國工作的實際經驗總結出這篇文章，希望與大家共同分享。本文作為摘錄，自然是掛一漏萬，所以建議大家若有時間還是找來原書一讀。在微軟的產品定義與開發過程中，微軟軟件開發遵循著一

2、種可稱之為“靠改進特性（Feature）與固定資源（Resource）來激發創造力”的戰略。該戰略可分為五個原則：將大項目分成若干里程碑式（Milestone）的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。 運用想象描述和對特性的概要說明（Program Specification）指導項目。 根據用戶行為（User Behavior）和有關用戶的資料確定產品特性及其優先順序。 建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點。 靠個人負責和固定項目資源實施控制。 原則一：將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。項目進度安排與

3、里程碑 微軟通常采用“同步穩定產品開發法”。典型項目的生命周期包括三個階段：計劃階段：完成功能的說明和進度表的最后制定 開發階段：寫出完整的的源代碼 穩定化階段：完成產品，使之能夠批量生產（Roll Out） 這三個大階段以及階段間內在的循環方法與傳統的“瀑布”（Water Fall）式開發方式很不相同，后者是由需求、詳盡設計、模塊化的代碼設計與測試、集成測試以及系統測試組成的。而微軟的三個階段更像是風險驅動的、漸進的“螺旋”式的生命周期模型。計劃階段的產品是想象性描述與說明文件，用來解釋項目將做什么和怎么做。在管理人員擬定進度表、開發員寫出代碼之前，這些東西都促進了人們對設計問題的思考與討論

4、。開發階段圍繞三次主要的內部產品發布來進行；穩定化階段集中于廣泛的內部與外部測試。在整個產品生產周期中，微軟都使用了緩沖時間的概念。緩沖時間使開發組能夠對付意外的困難和影響到時間進度的變故，它也提供了一種手段，可以緩和及時發貨與試圖精確估計發貨時間之間的矛盾。在開發和穩定化階段的所有時間中，一個項目通常會將2/3的時間用于開發，1/3的時間用于穩定化。（Office部門副總裁曾這樣概述通常的進度：“一般說來，在總的進度表中，用一半的時間寫出產品，留下另一半的時間調試或應付意外事故。這樣，如果我有一個兩年的項目，我會用一年來完成事先想好的東西如果事情有點麻煩，我便去掉我認為不太重要的特性?！保?/p>

5、這種里程碑式的工作過程使微軟的經理們可以清楚地了解產品開發過程進行到了哪一步，也使他們在開發階段的后期有能力靈活地刪去一些產品特性以滿足發貨時期的要求。 計劃階段 計劃階段是在一個項目的生命周期中，所有于開發前進行的計劃所占用的時間。計劃階段產生出想象性描述、市場營銷計劃、設計目標、一份最初的產品說明、為集成其他組開發的構件而規定的接口標準、最初的測試計劃、一個文檔策劃（印刷品和聯機幫助形式的）以及一份可用性問題清單（Usability List）。計劃階段從想象性描述開始。想象性描述來自產品經理以及各產品單位的程序經理；它是對規劃產品的市場營銷設想，包括了對競爭對手產品的分析以及對未來版本的

6、規劃。想象性描述也可能討論在前一次版本中發現面必須解決的問題以及應添加的主要功能。所有這些都基于對顧客和市場的分析以及從產品支持服務組處得到的資料。說明文件從一個大綱開始，然后定義出新的或增加的產品特性，并對其賦以不同的優先級。說明文件只是產品特性的一個預備性概覽；從開始開發到項目完成它要增加或變化20% - 30%。雖然在生命周期的后期說明變化一般較小，但越到后期，開發員就越是必須具充分的理由來作改變。通常程序經理使用VB創建項目原型。他們也開展設計可行性研究以了解設計中的取舍情況，盡快做出涉及產品說明的決定。對于重要產品的說明需由公司高層領導進行復審。對于不太重要的產品，則由部分經理去完成

7、。 開發階段 開發階段的計劃對三四個主要的里程碑版本都逐個分配一組特性，規定出特性的細節和技術上的相關性，記錄下單個開發員的任務以及對進度的估計。在開發階段中，開發員在功能性說明的指導下寫源代碼，測試員寫出測試項目組以檢查產品的特性與工作范圍是否正常，用戶教育人員（User Education）則編寫出文檔草案。當測試員發現錯誤時，開發員并不是留待以后處理，而是馬上改正，并在整個開發階段內使測試不斷地、自動地進行。這就改善了產品的穩定性并且使版本發布日期更易估計。當達到項目中的一定階段點后（40%時），開發員就試圖“鎖定”產品的主要功能要求或特性，從此只允許小范圍的改動。如果在此點之后開發員想

8、作大的改動，他們必須與程序經理以及開發經理進行討論協商，也許還要征求產品部門經理的意見。一個項目是圍繞著3或4個主要的內部版本，或“里程碑子項目”來組織開發階段的。一般用2至4個月來開發每一個主要的里程碑版本。每個版本都包括其自身的編碼、優化、測試以及調試活動。項目為意外事故保留總開發1/3的時間，即“緩沖時間”（Padding Time）。（蘋果公司的小組是割裂的、獨立的，各自開發各自的東西。在還有3個月就要發貨時，才會將所有的東西集成起來；Borland公司以一種漸近的方式進行開發，即把工作分成許多小的部分，并且總是讓開發的東西能夠運轉?？雌饋硭坪踹@種漸進的方法費時，但實際上幾乎沒有用過很

9、長時間，因為這使你總是能掌握住事情真實的情況。）當對最后一個主要的里程碑版本做了測試與穩定化之后，產品就要進行“外觀固定”（UI Freeze），即確定產品的主要用戶界面，如菜單、對話框以及文件窗口等。此后有關用戶界面將不再進行大的改動，以免引進同步修改相應文檔的困難。 穩定化階段 穩定化階段著重于對產品的測試與調試。項目在此階段盡量不再增加新的功能，除非是競爭產品或者市場發生了變化。穩定化階段也包括了緩沖時間，以應付不可預見的問題或者延遲。下面我將Micosoft開發軟件的模式用以下這張簡圖加以描述：（這張圖對微軟的測試進行了比較詳細的描述，我個人認為微軟的測試是Microsoft軟件產品開

10、發中一個十分重要也是十分有特色的分工。這是通過在微軟將近一年的觀察和與國內同類企業的分析，我才得出這樣的結論。大家都很明白，國內的軟件開發商在這方面做得很不夠，尤其不重視軟件的內部測試，在他們的思想中，可能有一個誤區：認為測試應該完全去由用戶去負責，其實不然，在軟件的開發流程中，軟件的測試與開發是一種“矛與盾”的關系，互為補充，缺一不可。在微軟，可能這種關系發揮到了極至：有時開發部門與測試部門互相較著勁，開發經理和測試經理的地位是相同的，有時甚至測試經理的地位甚至凌駕于開發經理之上，但他們之間沒有根本的利益沖突，只有一個共同的目標：將產品的質量提高。）補充一點：（對微軟的測試流程加以簡要的描述

11、一下）微軟內部，專門有一個小組負責為微軟的工程師們提供日常工作和管理的工具軟件，他們是非盈利機構，其主要任務是開發微軟內部所需要的工具軟件：例如：SLM(Source Library Tree),源代碼管理工具，負責管理軟件開發過程中各個程序員的源碼，各個程序員負責寫自己的模塊，每天將完成的代碼Check-in到一個中央服務器的SLM樹中，這個SLM樹由預先定義好的腳本在固定的時間開始編譯，通常這個過程需要好幾個小時，所以微軟內部根據各個項目組的情況有各自的規定：比如開發員必須在下班前（比如下午6：00）之前將當天修改的代碼Check-in進去，這樣SLM才開始編譯。 第二天，QA組的各個測試

12、員從服務器上下載前一天的一個Build開始測試，將測試的情況及時的反映到另外一個工具軟件中：RAID（Raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance.）.這個工具負責管理產品的BUG情況，每個BUG包含很多屬性：比如狀態（活動的、解決的、關閉的）、嚴重級、優先級、哪個區域、哪個版本出現的、發現者、要將這個BUG賦給哪一個開發員等等一系列屬性。還可以根據這個工具查詢哪個開發員當天的BUG活動的、解決的數量，哪個測試員

13、的BUG質量數目等等一些基本的產品質量情況，這樣項目經理可以很容易的掌握該項目的具體進展情況。如果在項目的開發中期，發現的BUG數目比解決的BUG數目持續的多（意味著該產品的活著的BUG越來越多），可能意味著這個項目出現了問題，決策者可以迅速的作出相應的決策，及時的糾正產品開發中出現的失誤（微軟曾經有很多產品因為這樣的因素被Cancel了）。還有項目經理可以根據這個工具，及時的掌握、了解每個測試員和開發員的工作狀態，這一點很重要。有很多人曾經說過：Microsoft憑借著SLM和RAID打敗了無數的競爭對手，通過我在微軟的經歷，我看這話一點也不假。這兩個工具確實是非常杰出的工具，微軟將它們使用

14、到了十分藝術的程度上，對微軟的成功起著非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進行改進、升級，使得微軟的工程師們工作起來更加如虎添翼、虎虎生風，這樣的企業哪有不成功的道理? 在測試過程中，也不是隨便的對軟件產品毫無目的的瞎使用、亂使用，微軟也有一套十分先進的方法和工具支撐著測試的每個方面：比如ATCM(Access Test Case Management)，一種基于Test Case（測試用例）的測試管理工具就承擔著這方面的工作。 微軟也許正是靠著“程序員的聰明和測試員的勤奮”構建起軟件帝國的大廈、譜寫著軟件事業的輝煌。 Product Developing Proce

15、ss in Microsoft 上圖中： QA是微軟大的產品部門下設的一個比較專業的測試部門（Quality Assurance Dept）項目進度表中的緩沖時間（Padding Time） 微軟使用緩沖計劃，以在最高的效率與較好地對未來作預計之間求得平衡。這種應付突發事件的時間在開發和穩定化過程中是每一個主要里程碑的一部分。緩沖時間主要用于彌補由于對特性（Feature）的不完全理解，或者是技術困難或是由于疏忽而忘記把任務寫入進度，或者是未料到的難題而形成的漏洞。緩沖時間有助于一個項目適應意料之外的事件。 原則二：運用想象性描述和對特性的概要說明指導項目為了給出足夠的開發框架以使工作能持續進

16、行，并且能容納開發過程中出現的變化并保持足夠的靈活性，微軟采用想象性描述和概要的說明來指導項目開發，而不是在一開始就努力寫出一份完整和詳細的說明。所謂想象性描述是由程序經理和來自市場營銷組的產品計劃人員共同編寫的一份非常短的文件，在其中主要是定義產品開發的目標（不涉及產品的具體細節！）。通常對一個全新的產品，想象性描述一般會相對較詳細，在其中還含有一份粗略的說明文件?？偟膩碚f，微軟對于想象性描述的要求是：越短越好，盡量說明"產品不做什么"(而不是"產品要做什么"！)。 運用想象性描述，程序經理開始編寫功能說明文件，該文件解釋產品的特性是什么以及這些特性如

17、何與其他特性及產品發生關系。最初它只是一個概要性的說明文件，隨著項目的進展，程序經理會隨時向其中添加更多的細節，最終的說明文件將變得象用戶手冊一樣。完整的說明不只起著對產品最新功能的描述作用，而且它還是在產品投產與發貨之前進行測試與評估的主要依據。 想象性描述有助于決定刪除哪些特性。 微軟內的各個開發組采用想象性描述幫助細化產品版本的規定主題，然后以此主題來決定是否需要增加產品各個可能的特性。通常不要輕易改變所確定的主題，否則可能造成產品開發上的混亂。編寫說明文件 說明文件在產品小組的所有成員之間，產品小組之間以及產品小組與管理部門之間起著傳遞產品的設想與要求的作用。在說明文件中必須清楚地描述

18、產品特性（描述每個特性如何工作，外觀如何以及從用戶的角度出發如何與用戶交互。如果特性有一個界面，還應包括一張示意圖，以顯示出界面的效果），并賦于其相應的優先級。程序經理據此建立起項目的開發進度表。此外在其中還應包括以下各項內容：用一句話表示的項目開發目的，關于產品是什么與不是什么的清單，對顧客的定義，對競爭產品的定義，產品對系統的要求（包括操作系統版本、最小內存要求、硬盤空間、處理器速度以及顯示器分辯率），對第三方（如打印機驅動程序、組件）的任何依賴性。程序經理負責協調并"寫下"說明程序經理（Program Manager）應考慮以下問題：這項特性的要點是什么？ 用戶如何使

19、用該特性？ 這項特性有意義嗎？ 該產品中或微軟的其他產品中有類似的特性嗎？ 有哪些問題被遺漏了？ 組內的交流令人滿意嗎？ 最終程序經理通過與組內開發人員的共同討論決定有關特性的內容，并將其寫下來。構造原型 構造原型是程序經理具體說明一件新產品或一個新版本的最好方法，這從許多方面來說都使開發前測試成為可能，尤其在可用性方面，并且有助于對與用戶交互情況作出好的理解，它也能使產品說明更緊湊。微軟的開發人員通常采用VB構造用戶界面原型，但是對于構造計算機屏幕模型之類的工作，畫筆（Paint brush）也是一個很好用的工具。死板的說明變成有生命的文件，說明不應過于詳細以至限制了發明創造。在項目開發過程

20、中，說明文件的早期版本會有相當大的增加與改變。由于說明的變動可能會導致相應開發工作的極大變動，所以微軟通常是將精力首先集中于那些沒有什么用戶界面的特性上，因為在完成開發前不必去了解用戶對它們有何反應，也就是說這些特性不大可能改變。然后再面對其它特性。但是當產品開發到一定程序后，例如40%之后，程序經理必須嚴格控制對特性的修改（主要是指增加新的特性），否則不光會造成開發延遲，而且會壓縮可用的測微軟公司軟件開發模式簡介(下)原則三：根據用戶行為和有關用戶的資料確定產品特牲及其優先順序對于一個開發項目而言，如何確定最終產品中應包含什么特性通常是比較困難的一件事。為此微軟采用了一個稱之為“基于行為制定

21、計劃”的方式來進行特性選擇與優先級安排?；谛袨橹贫ㄓ媱澐◤膶τ脩粜袨椋T如寫信或做預算，做系統研究開始。然后，根據某一特性在支持重要的或者是經常的用戶行為上的程序對其進行評價。這樣做的優點是對特性取舍更具理性：討論對顧客想要做什么加以更好的安排，對某個給定特性是否方便了特定任務的更集中的辯論，可讀性更強的說明，以及在市場營銷、用戶教育和產品開發中更好地同步。特性選擇和優先級安排中的基于行為制定計劃 基于行為制定計劃法中的關鍵點在于按用戶行為、產品特性以及行為和特性之間的內部聯系來分析產品。程序經理和產品計劃者把產品試圖支持的用戶任務或方案分成大約20個“行為”，然后他們努力把行為（以及任何子

22、行為）映射入微軟的現行特性和競爭對手產品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場部分中去。當說明產品的新版本時，基于行為制定計劃法幫助程序經理和開發員集中他們的精力與創造力。象Excel之類的項目，爭取在每個新版本中加入的主要行為不超過四個。絕大多數特性直接映射入這些行為之中。該做法使項目可以按特性對用戶的價值來進行分級。通過分級，促使程序經理和開發人員都行動起來，使他們的特性支持盡可能多的行為。這種良性競爭對于用戶有益，同時也利于提高生產率。為顧客行為而非產品特性準備資料 基于行為制定計劃進度，項目在計劃階段首先集中于行為，其次才是特性。程序經理和市場營銷人員并不去思考和排除

23、他們喜愛的特性，再圍繞它們搞出想象性描述的草案。他們真正做的是列出一份顧客都做些什么的清單，然后把想象性描述集中于支持那些行為的特性上。以行為為中心對產品進行全面考慮 由于基于行為制定計劃法是從整個產品的觀點著眼，因此有助于在不同職能上工作的項目成員理解產品做什么，以及其他產品的相應特性如何可能支持那些需要或不需要其他應用軟件產品的行為。做市場營銷研究以支持基于行為制定計劃法 為支持基于行為制定計劃法，從市場營銷組來的產品經理與程序經理、開發人員一起開展一些聯合的研究，如指導對用戶的研究工作。然而，一般來說是產品經理做大多數的研究，并可使其更明確地影響微軟產品的演進。原則四：建立模塊化的和水平

24、式的設計結構，并使項目結構反映產品結構的特點微軟產品設計中的一個關鍵概念是產品的基礎結構（Infrastructure），尤其是生命周期短的應用軟件，應隨項目的進展變得更加單一（而不是錯綜復雜）。當開發組構造產品的第一版時，他們更多地使用分級式結構，好為產品設計規定出一個最初的架構。隨著時間推移，他們向單一的結構邁進，以使項目能集中于特性開發。微軟越來越強調不同產品間的特性共享。共享有助于使不同產品的“性能與感覺”（Look and Feel）都統一協調起來；它也方便了需要不只一個應用軟件的用戶，減少了代碼的重復書寫，縮小了單獨一個應用軟件的規模。微軟用特性小組組織產品開發，這種方法使得每個人

25、都容易明白小組是如何與整個產品相關聯的。項目從規定概要說明開始。概要說明的形式是一份已確定了優先級安排的內容清單，涉及產品下一版本將要開發的相對獨立的特性，以便由分開的特性小組加以開發。程序經理和開發員把項目分成特性子集，再將之分配給每個特性小組，讓他們在3到4個主要的內部項目里程碑中進行生產。這種產品組織與開發方法使微軟能靠簡單地增加開發員和創建一個大的小組來漸進地增加產品的功能。把特性(與函數)作為開發單位 微軟軟件產品的特性是用戶最終可見的相對獨立的功能單位，就如建筑材料一般，對應用軟件產品更是如此。系統軟件產品，如NT或者95的特性，對最終用戶通常不直接可見。微軟和其他公司有時簡單地稱

26、這些不直接可見的特性為“函數”。程序經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到最后完成的過程。他們必須與開發員合作，后者負責估計進度表與完善每個特性。開發員還要在一臺聯網開發計算機上存儲一到幾個文件，用以保存特性的程序源代碼。大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。產品結構是決定其長期結構完整性的基石 產品結構是產品內部的基干，它規定了重要的結構構件以及這些構件如何組裝到一起。產品結構及用于組裝結構的構件，提供了實現產品特性（即做詳細設計與編碼）的支柱。產品的結構對最終用戶而言，通常并非直接可見。只有結構要實現的特性是可見的。產品結構也是決定產品長期

27、結構完整性的基石。產品功能的任何改變都不應造成潛在的產品結構散架。產品的層次結構 對于產品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產品特性進行靈活的增加、刪除與改進。此外良好的層次結構有助于產品在不同平臺上的移植。（例如Excel總共定義了五層，其中只有最底層的操作系統層是與平臺相關的，其它各層均是通過調用其下層所提供的API接口加以實現的，所以其移植極其方便。而在Windows 95中通過“虛擬機”的概念實現了對16位、32位以及DOS程序的支持。）小的結構文檔：源代碼是唯一文件 除了API文檔，微軟不對其產品結構生成相應的文檔，雖然有時高級開發員可能會寫下高層結構

28、。對復雜的特性，許多開發員在某些點記錄并復查特定于他們所負責的結構細節，但此工作是可選的，并不強制執行。除了源代碼文件與特性說明，為數不多的組為新程序員準務了描繪某層結構的文檔（主要的數據結構，如何工作等等）。但是這些文件并不時常更新，經理們也不要求項目組生成此類內部文檔。在有關的說明文件中，并不涉及實現問題。開發員應該知道如何去實現，或者能夠去學會。記錄的關于結構的文檔如此之少是因為“一個開發員的工作是編寫我們要賣的代碼，而不是花時間寫高水平的設計文件”，“設計文件不應與源代碼分離”。分割代碼與“保持事情的簡單”。特性小組和作為"內容專家"的小組領導 特性小組一般由一個領

29、導和3至8名開發人員組成，工作于相關的特性領域。小組的規模常常視小組領導的經驗和能力而定。特性小組領導向項目開發領導匯報并負責項目的全部開發工作；而項目開發領導則擁有對產品的更為全局性的觀點，從而最有可能發現不互相關聯的問題。在特性小組中的每個人均是此領域的“專家”，他們了解如何使用產品、了解競爭對手的產品、了解未來將向何處去。通常為便于交流，提高軟件的組織結構（軟件傾向于映射出構造它的組織的結構），應保持特性小組的小規模。原則五：靠個人負責和固定項目資源實旋控制對于軟件項目而言，精確估計產品的開發與交付進度是很困難的。對此微軟采取的方法是將進度安排和工作管理的責任推到最底層，即單個的開發人員

30、和測試人員那兒去。這保證了每個人除了作為小組的一部分外，還負有個人的責任。單獨的開發人員設立他們自已的進度表，程序經理把單獨的進度表匯總起來，再加上緩沖時間，以制定出一個全面的項目進度表。頂層的總經理也固定人員與時間等基本資源，以確保項目集中并限制其努力與創造程序。關鍵的目標，尤其對應用軟件，是指明產品的目標出品日并爭取盡可能長久地堅持它。程序經理和開發員從出品日回溯，規定中間的項目里程碑的日期。這個“固定的出品日法“的中心在開發員身上。以避免因為項目沒有固定的結束點，導致在最終無用的設計、再設計和測試的循環中消耗一年或更多的時間。開發人員做出他們自已的進度估計 “日期設定方法"。但

31、是開發人員一般會做出較樂觀的估計，因此開發經理還需對他們所提供的日期進行調整并加上緩沖時間以避免因因信息不完全而出現的問題。微軟這種制定進度的方法的優點在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正需要的時間。對細致的任務的進度估計 微軟的第二個進度安排方法是：對要完成的任務做非常詳盡的考慮，在此基礎上請開發人員給出他們對“實現”的估計，以此力圖“促使”更加現實主義并避免過度低估。通常微軟把任務細化到4小時（半天）到3天之間。對于準確進度的安排，微軟的經理是這樣認識的：“任何任務只要超過一星期，那人們就一定沒有充分地

32、全盤考慮它。任何任務某人估計只用少于半天就可完成，則他對它考慮得太多了。他應該用更多的時間去編程，更少的時間來考慮”。對于類似類于Windows NT之類的操作系統而言，進度安排更加困難，對其一般以幾天或者半周為工作單位進行進度估計。安排開發人員與小組進度時的心理學 當項目變大時，微軟把員工分成小組。然后經理把進度的責任和所有權盡可能地分發下去，直到小組和個人；這使二者都產生了一種擁用工作的感覺。它還在小組中，個人中，尤其是小組領導中造成強烈的跟上其它同事預計進度的壓力，因為經理可能再平衡進度，從落后的小組或個人手中拿走工作。這樣，同事間的壓力使經理不需要太多的努力就可以對個人或單個小組的進程

33、實施嚴格控制。"固定的"出品日(RTM: Release To Manufacture) 為了把創造力約束在時間限制之中，微軟現在在新產品或者產品新版本開始前爭取固定出品日，至少是有出品日的內部目標。這給人們施加砍去特性和集中在一個項目上的壓力，逼迫他們去苦苦思考應將哪個新特性加入產品中。雖然最終產品的交付目標可能是由高級執行人員設定，但是開發人員與小組仍然設定他們自已的進度表。微軟一般根據預先的時間進度的大致估計出一個RTM日期，然后向前回溯相應的各個Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC

34、（Code Complete）等等各個Milestone的相應日期。制定出十分詳盡的產品研究開發時間進度表，產品開發組的各個成員以這個進度表為目標統一協調工作。微軟十分強調軟件開發過程中的Teamwork Spirits，這種理念貫穿在微軟各個產品開發的各個階段。這也是微軟得以成功的一個十分重要的原因。 小結：同步穩定開發法 計劃階段 定義產品的想象性描述、說明與進度 想象性描述 產品和程序管理部門運用廣泛的顧客意見來確定和優化產品的特性。 說明文件 基于想象性描述，程序管理部門與開發組定義特性的功能，結構問題，以及各部分間的相關性。 制訂進度表與構造特性小組其于說明文件，程序管理部門協調進度

35、表，安排出特性小組，每個小組包括大約1名程序經理，3 - 8個開發員，3 - 8個測試員(以1:1比例與開發員平行工作。) 開發階段 用3 - 4個順序的子項目，每個產生一個里程碑式的產品發送，來完成特性的開發。程序經理協調開發過程。開發員設計、編碼、調試。測試員與開發員配對，不斷進行測試。子項目1 前1/3的特性：最重要的特性與共享的構件。 子項目2中間1/3的特性。 子項目3最后1/3的特性：最不重要的特性。 穩定化階段 全面的內外部測試，最后的產品穩定化以及發貨。程序經理協調OEM與ISV，監督從顧客得到的信息反饋。開發員進行最后的調試與代碼穩定化。測試員發現并清除錯誤。 內部測試 公司

36、內部對整個產品做詳盡的測試。 外部測試 公司外在的""測試點，象OEM，ISV以及最終用戶處對整個產品做詳盡的測試。 發貨準備 為批量生產準備發布最后的“金盤”（Golden Disk）與文檔，制作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、病毒檢查、文件相關性檢查等 成功軟件開發者的9種編程習慣李政和·yesky 好的原程序做出好的軟件有些人會想：只要程序運行結果好，就不管原程序編得怎樣。但絕對不是這樣的。軟件不是一次性就作完的，有必要做修改，擴展等管理。所以原程序要盡量作成易看懂，管理方便。這樣做，第一是為了軟件開發者方便，其次還會影響到軟

37、件的性能。管理不方便的程序不會作出好的軟件。希望通過這篇文章能學到好的編程習慣。要理解這文章的內容，你至少要懂得1個開發工具語言。這里舉例說明的都是C語言，但你對C語言沒有了解也不要擔心。這里說明的是原理而不是特定的語言。1. 語句要結束得徹底-(冒號；)程序員經常有的失誤之一是忘記在語句結束后加一個冒號。這樣的問題點不易發現，時而讓程序員不知所措。編程時要時時注意每個語句是否以冒號結束，雖然不是所有語言都以冒號結束。下面有忘記點冒號的例子。int main(void)/* 沒有冒號，導致問題*/ printf("Hello World!n") return(0);很多的人

38、犯這樣的錯誤。不到幾條的程序是不難發現這樣的問題，但1000條以上的程序里呢？查找那忘記寫冒號了的語句不會是很容易的事。記住，結束一條語句，一定要寫冒號，如同一般文章結束后點句號一樣。 還有一種關于冒號的失誤是不該寫冒號的時候寫冒號。有經驗的程序員看到下面例子會覺得好笑，但筆者確實看到了很多這樣的失誤。/* main() 后面不該寫冒號 */ int main(int argc, char *argv); printf("Hello World"); return(0); 函數或Method后面是不該寫冒號的。 2. 要適合使用空格和tab鍵C語言是不分辨空格的，因此程序也可以不需要空格一直寫下去，但這樣的程序會是誰都看不懂的"很有難度"的程序，請看以下例子：if(x=0) a=b=c=d=MAX; x+;這樣寫，也許會節省空間，但不僅別人，編程的本人也會很難看懂。程序要寫得容易看懂！if(x = 0) a = b = c = d = MAX; x+; 這樣寫，看起來不很清楚嗎？程序要有確切的空格才容易看得懂。3. 統一使用大括號和切斷方式每個程序員使用大括號()和改行的方式都有自己的習慣，這樣，把程序移交給別人繼續做的時候，會出現混亂。比如象以下例子：int m