微軟公司軟體開發模式簡介(一萬字) (轉)

微軟公司軟體開發模式簡介(一萬字) (轉)[@more@] 

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

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

1. 將大專案分成若干里程碑式（Milestone）的重要階段，各階段之間有緩衝時間，但不進行單獨的產品維護。
2. 運用想象描述和對特性的概要說明（Program Specification）指導專案。
3. 根據行為（User Behavior）和有關使用者的資料確定產品特性及其優先順序。
4. 建立模組化的和水平式的設計結構，並使專案結構反映產品結構的特點。
5. 靠個人負責和固定專案資源實施控制。

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

1. 專案進度安排與里程碑

微軟通常採用“同步－穩定產品開發法”。典型專案的生命週期包括三個階段：

• 計劃階段：完成功能的說明和進度表的最後制定
• 開發階段：寫出完整的的
• 穩定化階段：完成產品，使之能夠批次生產（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越來越多），可能意味著這個專案出現了問題，決策者可以迅速的作出相應的決策，及時的糾正產品開發中出現的失誤（微軟曾經有很多產品因為這樣的因素被Cancel了）。還有專案經理可以根據這個工具，及時的掌握、瞭解每個測試員和開發員的工作狀態，這一點很重要。有很多人曾經說過：Microsoft憑藉著SLM和RAID打敗了無數的競爭對手，透過我在微軟的經歷，我看這話一點也不假。這兩個工具確實是非常傑出的工具，微軟將它們使用到了十分藝術的程度上，對微軟的成功起著非常重要的作用。更難能可貴的是，目前這些工具在功能上還在不斷的進行改進、升級，使得微軟的工程師們工作起來更加如虎添翼、虎虎生風，這樣的企業哪有不成功的道理?
• 在測試過程中，也不是隨便的對軟體產品毫無目的的瞎使用、亂使用，微軟也有一套十分先進的方法和工具支撐著測試的每個方面：比如ATCM(　Access Test Case Management)，一種基於Test Case（測試用例）的測試管理工具就承擔著這方面的工作。

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

ectratio="t" v:ext="edit">

Product Develo Process in Microsoft

上圖中： QA是微軟大的產品部門下設的一個比較專業的測試部門（Quality Assurance Dept）

1. 專案進度表中的緩衝時間（Padding Time）

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

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

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

越短越好，儘量說明"產品不做什麼"(而不是"產品要做什麼"！)。

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

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

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

• 編寫說明檔案

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

程式經理（Program Manager）應考慮以下問題：

• 這項特性的要點是什麼？
• 使用者如何使用該特性？
• 這項特性有意義嗎？
• 該產品中或微軟的其他產品中有類似的特性嗎？
• 有哪些問題被遺漏了？
• 組內的交流令人滿意嗎？

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

1. 構造原型

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

微軟的開發人員通常採用VB構造使用者介面原型，但是對於構造螢幕模型之類的工作，畫筆（Paint brush）也是一個很好用的工具。死板的說明變成有生命的檔案，說明不應過於詳細以至限制了發明創造。在專案開發過程中，說明檔案的早期版本會有相當大的增加與改變。由於說明的變動可能會導致相應開發工作的極大變動，所以微軟通常是將精力首先集中於那些沒有什麼使用者介面的特性上，因為在完成開發前不必去了解使用者對它們有何反應，也就是說這些特性不大可能改變。然後再面對其它特性。但是當產品開發到一定程式後，例如40%之後，程式經理必須嚴格控制對特性的修改（主要是指增加新的特性），否則不光會造成開發延遲，而且會可用的測試時間。

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

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

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

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

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

當說明產品的新版本時，基於行為制定計劃法幫助程式經理和開發員集中他們的精力與創造力。象之類的專案，爭取在每個新版本中加入的主要行為不超過四個。絕大多數特性直接對映入這些行為之中。該做法使專案可以按特性對使用者的價值來進行分級。透過分級，促使程式經理和開發人員都行動起來，使他們的特性支援儘可能多的行為。這種良性競爭對於使用者有益，同時也利於提高生產率。

2. 為顧客行為而非產品特性準備資料

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

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

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

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

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

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

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

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

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

5. 把特性(與)作為開發單位

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

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

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

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

7. 產品的層次結構

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

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

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

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

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

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

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

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

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

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

11. 對細緻的任務的進度估計

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

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

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

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

13. "固定的"出品日(　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）與文件，製作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、檢查、檔案相關性檢查等。