微軟的秘密：微軟公司軟件開發模式簡介

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

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

將大項目分成若干里程碑式(Milestone)的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。

運用想象描述和對特性的概要說明(Program Specification)指導項目。

根據用戶行為(User Behavior)和有關用戶的資料確定產品特性及其優先順序。

建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點。

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

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

項目進度安排與里程碑

微軟通常采用“同步-穩定產品開發法”。典型項目的生命周期包括三個階段：

1、計劃階段：完成功能的說明和進度表的最后制定

2、開發階段：寫出完整的的源代碼

3、穩定化階段：完成產品，使之能夠批量生產(Roll Out)

這三個大階段以及階段間內在的循環方法與傳統的“瀑布”(Water Fall)式開發方式很不相同，后者是由需求、詳盡設計、模塊化的代碼設計與測試、集成測試以及系統測試組成的。而微軟的三個階段更像是風險驅動的、漸進的“螺旋”式的生命周期模型。

計劃階段的產品是想象性描述與說明文件，用來解釋項目將做什么和怎么做。在管理人員擬定進度表、開發員寫出代碼之前，這些東西都促進了人們對設計問題的思考與討論。開發階段圍繞三次主要的內部產品發布來進行；穩定化階段集中于廣泛的內部與外部測試。

在整個產品生產周期中，微軟都使用了緩沖時間的概念。緩沖時間使開發組能夠對付意外的困難和影響到時間進度的變故，它也提供了一種手段，可以緩和及時發貨與試圖精確估計發貨時間之間的矛盾。

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

計劃階段

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

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

通常程序經理使用VB創建項目原型。他們也開展設計可行性研究以了解設計中的取舍情況，盡快做出涉及產品說明的決定。對于重要產品的說明需由公司高層領導進行復審。對于不太重要的產品，則由部分經理去完成。

開發階段

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

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

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

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

穩定化階段

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

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

補充一點：(對微軟的測試流程加以簡要的描述一下)微軟內部，專門有一個小組負責為微軟的工程師們提供日常工作和管理的工具軟件，他們是非盈利機構，其主要任務是開發微軟內部所需要的工具軟件：

例如：SLM(Source Library Tree)，源代碼管理工具，負責管理軟件開發過程中各個程序員的源碼，各個程序員負責寫自己的模塊，每天將完成的代碼Check-in到一個中央服務器的SLM樹中，這個SLM樹由預先定義好的腳本在固定的時間開始編譯，通常這個過程需要好幾個小時，所以微軟內部根據各個項目組的情況有各自的規定：比如開發員必須在下班前(比如下午6：00)之前將當天修改的代碼Check-in進去，這樣SLM才開始編譯。

第二天，QA組的各個測試員從服務器上下載前一天的一個Build開始測試，將測試的情況及時的反映到另外一個工具軟件中：RAID(Raid is a tool for entering，tracking，analyzing，and reporting product defects during development and maintenance.)。這個工具負責管理產品的BUG情況，每個BUG包含很多屬性：比如狀態(活動的、解決的、關閉的)、嚴重級、優先級、哪個區域、哪個版本出現的、發現者、要將這個BUG賦給哪一個開發員等等一系列屬性。還可以根據這個工具查詢哪個開發員當天的BUG活動的、解決的數量，哪個測試員的BUG質量數目等等一些基本的產品質量情況，這樣項目經理可以很容易的掌握該項目的具體進展情況。如果在項目的開發中期，發現的BUG數目比解決的 BUG數目持續的多(意味著該產品的活著的BUG越來越多)，可能意味著這個項目出現了問題，決策者可以迅速的作出相應的決策，及時的糾正產品開發中出現的失誤(微軟曾經有很多產品因為這樣的因素被Cancel了)。還有項目經理可以根據這個工具，及時的掌握、了解每個測試員和開發員的工作狀態，這一點很重要。有很多人曾經說過：Microsoft憑借著SLM和RAID打敗了無數的競爭對手，通過我在微軟的經歷，我看這話一點也不假。

這兩個工具確實是非常杰出的工具，微軟將它們使用到了十分藝術的程度上，對微軟的成功起著非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進行改進、升級，使得微軟的工程師們工作起來更加如虎添翼、虎虎生風，這樣的企業哪有不成功的道理？

在測試過程中，也不是隨便的對軟件產品毫無目的的瞎使用、亂使用，微軟也有一套十分先進的方法和工具支撐著測試的每個方面：比如ATCM (Aclearcase/" target="_blank" >ccess Test Case Management)，一種基于Test Case(測試用例)的測試管理工具就承擔著這方面的工作。

微軟也許正是靠著“程序員的聰明和測試員的勤奮”構建起軟件帝國的大廈、譜寫著軟件事業的輝煌。

項目進度表中的緩沖時間(Padding Time)

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

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

將大項目分成若干里程碑式(Milestone)的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。

運用想象描述和對特性的概要說明(Program Specification)指導項目。

根據用戶行為(User Behavior)和有關用戶的資料確定產品特性及其優先順序。

建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點。

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

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

項目進度安排與里程碑

微軟通常采用“同步-穩定產品開發法”。典型項目的生命周期包括三個階段：

1、計劃階段：完成功能的說明和進度表的最后制定

2、開發階段：寫出完整的的源代碼

3、穩定化階段：完成產品，使之能夠批量生產(Roll Out)

這三個大階段以及階段間內在的循環方法與傳統的“瀑布”(Water Fall)式開發方式很不相同，后者是由需求、詳盡設計、模塊化的代碼設計與測試、集成測試以及系統測試組成的。而微軟的三個階段更像是風險驅動的、漸進的“螺旋”式的生命周期模型。

計劃階段的產品是想象性描述與說明文件，用來解釋項目將做什么和怎么做。在管理人員擬定進度表、開發員寫出代碼之前，這些東西都促進了人們對設計問題的思考與討論。開發階段圍繞三次主要的內部產品發布來進行；穩定化階段集中于廣泛的內部與外部測試。

在整個產品生產周期中，微軟都使用了緩沖時間的概念。緩沖時間使開發組能夠對付意外的困難和影響到時間進度的變故，它也提供了一種手段，可以緩和及時發貨與試圖精確估計發貨時間之間的矛盾。

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

計劃階段

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

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

通常程序經理使用VB創建項目原型。他們也開展設計可行性研究以了解設計中的取舍情況，盡快做出涉及產品說明的決定。對于重要產品的說明需由公司高層領導進行復審。對于不太重要的產品，則由部分經理去完成。

開發階段

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

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

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

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

穩定化階段

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

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

補充一點：(對微軟的測試流程加以簡要的描述一下)微軟內部，專門有一個小組負責為微軟的工程師們提供日常工作和管理的工具軟件，他們是非盈利機構，其主要任務是開發微軟內部所需要的工具軟件：

例如：SLM(Source Library Tree)，源代碼管理工具，負責管理軟件開發過程中各個程序員的源碼，各個程序員負責寫自己的模塊，每天將完成的代碼Check-in到一個中央服務器的SLM樹中，這個SLM樹由預先定義好的腳本在固定的時間開始編譯，通常這個過程需要好幾個小時，所以微軟內部根據各個項目組的情況有各自的規定：比如開發員必須在下班前(比如下午6：00)之前將當天修改的代碼Check-in進去，這樣SLM才開始編譯。

第二天，QA組的各個測試員從服務器上下載前一天的一個Build開始測試，將測試的情況及時的反映到另外一個工具軟件中：RAID(Raid is a tool for entering，tracking，analyzing，and reporting product defects during development and maintenance.)。這個工具負責管理產品的BUG情況，每個BUG包含很多屬性：比如狀態(活動的、解決的、關閉的)、嚴重級、優先級、哪個區域、哪個版本出現的、發現者、要將這個BUG賦給哪一個開發員等等一系列屬性。還可以根據這個工具查詢哪個開發員當天的BUG活動的、解決的數量，哪個測試員的BUG質量數目等等一些基本的產品質量情況，這樣項目經理可以很容易的掌握該項目的具體進展情況。如果在項目的開發中期，發現的BUG數目比解決的 BUG數目持續的多(意味著該產品的活著的BUG越來越多)，可能意味著這個項目出現了問題，決策者可以迅速的作出相應的決策，及時的糾正產品開發中出現的失誤(微軟曾經有很多產品因為這樣的因素被Cancel了)。還有項目經理可以根據這個工具，及時的掌握、了解每個測試員和開發員的工作狀態，這一點很重要。有很多人曾經說過：Microsoft憑借著SLM和RAID打敗了無數的競爭對手，通過我在微軟的經歷，我看這話一點也不假。

這兩個工具確實是非常杰出的工具，微軟將它們使用到了十分藝術的程度上，對微軟的成功起著非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進行改進、升級，使得微軟的工程師們工作起來更加如虎添翼、虎虎生風，這樣的企業哪有不成功的道理？

在測試過程中，也不是隨便的對軟件產品毫無目的的瞎使用、亂使用，微軟也有一套十分先進的方法和工具支撐著測試的每個方面：比如ATCM (Access Test Case Management)，一種基于Test Case(測試用例)的測試管理工具就承擔著這方面的工作。

微軟也許正是靠著“程序員的聰明和測試員的勤奮”構建起軟件帝國的大廈、譜寫著軟件事業的輝煌。

項目進度表中的緩沖時間(Padding Time)

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

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

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

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

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

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

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

程序經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到最后完成的過程。他們必須與開發員合作，后者負責估計進度表與完善每個特性。開發員還要在一臺聯網開發計算機上存儲一到幾個文件，用以保存特性的程序源代碼。大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。

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

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

產品的層次結構

對于產品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產品特性進行靈活的增加、刪除與改進。此外良好的層次結構有助于產品在不同平臺上的移植。(例如Excel總共定義了五層，其中只有最底層的操作系統層是與平臺相關的，其它各層均是通過調用其下層所提供的API接口加以實現的，所以其移植極其方便。而在Windows 95中通過“虛擬機”的概念實現了對16位、32位以及DOS程序的支持。)

小的結構文檔：源代碼是唯一文件

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

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

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

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

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

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

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

“日期設定方法。但是開發人員一般會做出較樂觀的估計，因此開發經理還需對他們所提供的日期進行調整并加上緩沖時間以避免因因信息不完全而出現的問題。微軟這種制定進度的方法的優點在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正需要的時間。

對細致的任務的進度估計

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

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

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

固定的出品日(RTM：Release To Manufacture)

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

微軟一般根據預先的時間進度的大致估計出一個RTM日期，然后向前回溯相應的各個Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC(Code Complete)等等各個Milestone的相應日期。制定出十分詳盡的產品研究開發時間進度表，產品開發組的各個成員以這個進度表為目標統一協調工作。微軟十分強調軟件開發過程中的Teamwork Spirits，這種理念貫穿在微軟各個產品開發的各個階段。這也是微軟得以成功的一個十分重要的原因。

小結：同步-穩定開發法

計劃階段

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

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

說明文件

基于想象性描述，程序管理部門與開發組定義特性的功能，結構問題，以及各部分間的相關性。

制訂進度表與構造特性小組

其于說明文件，程序管理部門協調進度表，安排出特性小組，每個小組包括大約1名程序經理，3-8個開發員，3-8個測試員(以1:1比例與開發員平行工作。)

開發階段

用3-4個順序的子項目，每個產生一個里程碑式的產品發送，來完成特性的開發。程序經理協調開發過程。開發員設計、編碼、調試。測試員與開發員配對，不斷進行測試。

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

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

子項目3最后1/3的特性：最不重要的特性。

穩定化階段

全面的內外部測試，最后的產品穩定化以及發貨。程序經理協調OEM與ISV，監督從顧客得到的信息反饋。開發員進行最后的調試與代碼穩定化。測試員發現并清除錯誤。

內部測試

公司內部對整個產品做詳盡的測試。

外部測試

公司外在的β測試點，象OEM，ISV以及最終用戶處對整個產品做詳盡的測試。

發貨準備

為批量生產準備發布最后的“金盤”(Golden Disk)與文檔，制作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、病毒檢查、文件相關性檢查等。

原文轉自：http://www.kjueaiud.com