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

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

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

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

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

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

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

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

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

"固定的"出品日(　RTM: Release To Manufacture) 
　　為了把創(chuàng)造力約束在時間限制之中，微軟現(xiàn)在在新產(chǎn)品或者產(chǎn)品新版本開始前爭取固定出品日，至少是有出品日的內(nèi)部目標。這給人們施加砍去特性和集中在一個項目上的壓力，逼迫他們?nèi)タ嗫嗨伎紤獙⒛膫�新特性加入產(chǎn)品中。雖然終產(chǎn)品的交付目標可能是由高級執(zhí)行人員設定，但是開發(fā)人員與小組仍然設定他們自已的進度表。

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

小結：同步－穩(wěn)定開發(fā)法

計劃階段 
定義產(chǎn)品的想象性描述、說明與進度

想象性描述 產(chǎn)品和程序管理部門運用廣泛的顧客意見來確定和優(yōu)化產(chǎn)品的特性。 
說明文件 基于想象性描述，程序管理部門與開發(fā)組定義特性的功能，結構問題，以及各部分間的相關性。 
制訂進度表與構造特性小組　其于說明文件，程序管理部門協(xié)調(diào)進度表，安排出特性小組，每個小組包括大約1名程序經(jīng)理，3 - 8個開發(fā)員，3 - 8個測試員(以1:1比例與開發(fā)員平行工作。) 
開發(fā)階段 
用3 - 4個順序的子項目，每個產(chǎn)生一個里程碑式的產(chǎn)品發(fā)送，來完成特性的開發(fā)。程序經(jīng)理協(xié)調(diào)開發(fā)過程。開發(fā)員設計、編碼、調(diào)試。測試員與開發(fā)員配對，不斷進行測試。

子項目1 前1/3的特性：重要的特性與共享的構件。 
子項目2中間1/3的特性。 
子項目3后1/3的特性：不重要的特性。 
　

穩(wěn)定化階段 
全面的內(nèi)外部測試，后的產(chǎn)品穩(wěn)定化以及發(fā)貨。程序經(jīng)理協(xié)調(diào)OEM與ISV，監(jiān)督從顧客得到的信息反饋。開發(fā)員進行后的調(diào)試與代碼穩(wěn)定化。測試員發(fā)現(xiàn)并清除錯誤。

內(nèi)部測試 公司內(nèi)部對整個產(chǎn)品做詳盡的測試。 
外部測試 公司外在的"β"測試點，象OEM，ISV以及終用戶處對整個產(chǎn)品做詳盡的測試。 
發(fā)貨準備 為批量生產(chǎn)準備發(fā)布后的“金盤”（Golden Disk）與文檔，制作之前，還需要進行各種嚴格的檢查：如政治敏感性術語檢查、病毒檢查、文件相關性檢查等。