原則一：將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時(shí)間，但不進(jìn)行單獨的產(chǎ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)的“螺旋”式的生命周期模型。
在開(kāi)發(fā)和穩定化階段的所有時(shí)間中，一個(gè)項目通常會(huì )將2/3的時(shí)間用于開(kāi)發(fā)，1/3的時(shí)間用于穩定化。這種里程碑式的工作過(guò)程使微軟經(jīng)理們可以清楚地了解產(chǎn)品開(kāi)發(fā)過(guò)程進(jìn)行到了哪一步，也使他們在開(kāi)發(fā)階段的后期有能力靈活地刪去一些產(chǎn)品特性以滿(mǎn)足進(jìn)度要求。
計劃階段
這里我總結了一下，主要是做以下事情
1.把你準備做什么樣一個(gè)產(chǎn)品搞清楚，這個(gè)產(chǎn)品有什么特性
2.這個(gè)產(chǎn)品有沒(méi)有市場(chǎng)，用戶(hù)為何需要這個(gè)產(chǎn)品，已經(jīng)該產(chǎn)品的走勢
3.這個(gè)產(chǎn)品大概是個(gè)什么樣子，是否有個(gè)大概的原型展示方便高層決策
4.設計的功能，目標，優(yōu)先級，大概的進(jìn)度。
所以微軟指的這個(gè)計劃階段包括了很多可行性研究和產(chǎn)品規劃的內容在里面，更多的是一個(gè)產(chǎn)品規劃的內容。
開(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ě)出文檔草案。(參考微軟的MSF模型)
當測試員發(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)。(這里有兩點(diǎn)，一個(gè)是提倡及早的發(fā)現缺陷和持續的集成，一個(gè)是后期嚴格的對需求變更進(jì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）。
(應該所1/3時(shí)間是足夠多的，一般研發(fā)項目很難預備這么足夠的Buffer)
當對最后一個(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)題或者延遲。在軟件的開(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ì)量提高。
在微軟內部有專(zhuān)門(mén)的SLM源代碼管理工具，負責管理源代碼和自動(dòng)構建。開(kāi)發(fā)人員每天在下班前將自己的代碼CheckIn,SLM由預先定義好的腳本進(jìn)行自動(dòng)編譯。第二天測試人員再下載前一天的Build進(jìn)行測試。將測試的情況及時(shí)的反映到另外一個(gè)工具軟件中,可以根據這個(gè)工具查詢(xún)哪個(gè)開(kāi)發(fā)員當天的BUG活動(dòng)的、解決的數量，哪個(gè)測試員的BUG質(zhì)量數目等等一些基本的產(chǎn)品質(zhì)量情況，這樣項目經(jīng)理可以很容易的掌握該項目的具體進(jìn)展情況。還有項目經(jīng)理可以根據這個(gè)工具，及時(shí)的掌握、了解每個(gè)測試員和開(kāi)發(fā)員的工作狀態(tài)，這一點(diǎn)也很重要。(微軟的源代碼管理和每日構造和持續集成機制是很值得推廣的地方)
微軟也許正是靠著(zhù)“程序員的聰明和測試員的勤奮”構建起軟件帝國的大廈、譜寫(xiě)著(zhù)軟件事業(yè)的輝煌。
原則二：運用想象性描述和對特性的概要說(shuō)明指導項目
編寫(xiě)想象性描述和概要說(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)。
構造原型
構造原型是程序經(jīng)理具體說(shuō)明一件新產(chǎn)品或一個(gè)新版本的最好方法，這從許多方面來(lái)說(shuō)都使開(kāi)發(fā)前測試成為可能，尤其在可用性方面，并且有助于對與用戶(hù)交互情況作出好的理解，它也能使產(chǎn)品說(shuō)明更緊湊。
微軟的開(kāi)發(fā)人員通常采用VB構造用戶(hù)界面原型，但是對于構造計算機屏幕模型之類(lèi)的工作，畫(huà)筆（Paintbrush）也是一個(gè)很好用的工具。死板的說(shuō)明變成有生命的文件，說(shuō)明不應過(guò)于詳細以至限制了發(fā)明創(chuàng )造。在項目開(kāi)發(fā)過(guò)程中，說(shuō)明文件的早期版本會(huì )有相當大的增加與改變。由于說(shuō)明的變動(dòng)可能會(huì )導致相應開(kāi)發(fā)工作的極大變動(dòng)，所以微軟通常是將精力首先集中于那些沒(méi)有什么用戶(hù)界面的特性上，因為在完成開(kāi)發(fā)前不必去了解用戶(hù)對它們有何反應，也就是說(shuō)這些特性不大可能改變。然后再面對其它特性。但是當產(chǎn)品開(kāi)發(fā)到一定程序后，例如40%之后，程序經(jīng)理必須嚴格控制對特性的修改（主要是指增加新的特性），否則不光會(huì )造成開(kāi)發(fā)延遲，而且會(huì )壓縮可用的測試時(shí)間。
(做一個(gè)新產(chǎn)品的時(shí)候，剛開(kāi)始是根本無(wú)法想清楚很多細節特征的。確實(shí)可能只有一個(gè)框架性的概念。所以微軟應該也是很強調迭代開(kāi)發(fā)和逐步細化，強調通過(guò)原型進(jìn)一步細化設計.所有這也是原型為何在挖掘用戶(hù)深處需求的時(shí)候有重要作用的原因，用戶(hù)剛開(kāi)始可能也不清楚要哪些細節性的功能，當用戶(hù)看到原型后才能夠提出深層次的一些需求來(lái))
原則三：根據用戶(hù)行為和有關(guān)用戶(hù)的資料確定產(chǎn)品特牲及其優(yōu)先順序
對于一個(gè)開(kāi)發(fā)項目而言，如何確定最終產(chǎn)品中應包含什么特性通常是比較困難的一件事。為此微軟采用了一個(gè)稱(chēng)之為“基于行為制定計劃”的方式來(lái)進(jìn)行特性選擇與優(yōu)先級安排。
基于行為制定計劃法從對用戶(hù)行為，諸如寫(xiě)信或做預算，做系統研究開(kāi)始。然后，根據某一特性在支持重要的或者是經(jīng)常的用戶(hù)行為上的程序對其進(jìn)行評價(jià)。這樣做的優(yōu)點(diǎn)是對特性取舍更具理性：討論對顧客想要做什么加以更好的安排，對某個(gè)給定特性是否方便了特定任務(wù)的更集中的辯論，可讀性更強的說(shuō)明，以及在市場(chǎng)營(yíng)銷(xiāo)、用戶(hù)教育和產(chǎn)品開(kāi)發(fā)中更好地同步。
特性選擇和優(yōu)先級安排中的基于行為制定計劃
基于行為制定計劃法中的關(guān)鍵點(diǎn)在于按用戶(hù)行為、產(chǎn)品特性以及行為和特性之間的內部聯(lián)系來(lái)分析產(chǎn)品。程序經(jīng)理和產(chǎn)品計劃者把產(chǎn)品試圖支持的用戶(hù)任務(wù)或方案分成大約20個(gè)“行為”，然后他們努力把行為（以及任何子行為）映射入微軟的現行特性和競爭對手產(chǎn)品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場(chǎng)部分中去。
當說(shuō)明產(chǎn)品的新版本時(shí)，基于行為制定計劃法幫助程序經(jīng)理和開(kāi)發(fā)員集中他們的精力與創(chuàng )造力。象Excel之類(lèi)的項目，爭取在每個(gè)新版本中加入的主要行為不超過(guò)四個(gè)。絕大多數特性直接映射入這些行為之中。該做法使項目可以按特性對用戶(hù)的價(jià)值來(lái)進(jìn)行分級。通過(guò)分級，促使程序經(jīng)理和開(kāi)發(fā)人員都行動(dòng)起來(lái)，使他們的特性支持盡可能多的行為。這種良性競爭對于用戶(hù)有益，同時(shí)也利于提高生產(chǎn)率。
(這個(gè)原則充分的體現了微軟產(chǎn)品完全由用戶(hù)驅動(dòng)，軟件創(chuàng )造客戶(hù)價(jià)值)
由于基于行為制定計劃法是從整個(gè)產(chǎn)品的觀(guān)點(diǎn)著(zhù)眼，因此有助于在不同職能上工作的項目成員理解產(chǎn)品做什么，以及其他產(chǎn)品的相應特性如何可能支持那些需要或不需要其他應用軟件產(chǎn)品的行為。
原則四：建立模塊化的和水平式的設計結構，并使項目結構反映產(chǎn)品結構的特點(diǎn)
微軟產(chǎn)品設計中的一個(gè)關(guān)鍵概念是產(chǎn)品的基礎結構（Infrastructure），尤其是生命周期短的應用軟件，應隨項目的進(jìn)展變得更加單一（而不是錯綜復雜）。當開(kāi)發(fā)組構造產(chǎn)品的第一版時(shí)，他們更多地使用分級式結構，好為產(chǎn)品設計規定出一個(gè)最初的架構。隨著(zhù)時(shí)間推移，他們向單一的結構邁進(jìn)，以使項目能集中于特性開(kāi)發(fā)。微軟越來(lái)越強調不同產(chǎn)品間的特性共享。共享有助于使不同產(chǎn)品的“性能與感覺(jué)”（Look and Feel）都統一協(xié)調起來(lái)；它也方便了需要不止一個(gè)應用軟件的用戶(hù)，減少了代碼的重復書(shū)寫(xiě)，縮小了單獨一個(gè)應用軟件的規模。
微軟用特性小組組織產(chǎn)品開(kāi)發(fā)，這種方法使得每個(gè)人都容易明白小組是如何與整個(gè)產(chǎn)品相關(guān)聯(lián)的。項目從規定概要說(shuō)明開(kāi)始。概要說(shuō)明的形式是一份已確定了優(yōu)先級安排的內容清單，涉及產(chǎn)品下一版本將要開(kāi)發(fā)的相對獨立的特性，以便由分開(kāi)的特性小組加以開(kāi)發(fā)。
程序經(jīng)理和開(kāi)發(fā)員把項目分成特性子集，再將之分配給每個(gè)特性小組，讓他們在3到4個(gè)主要的內部項目里程碑中進(jìn)行生產(chǎn)。這種產(chǎn)品組織與開(kāi)發(fā)方法使微軟能靠簡(jiǎn)單地增加開(kāi)發(fā)員和創(chuàng )建一個(gè)大的小組來(lái)漸進(jìn)地增加產(chǎn)品的功能。
把特性(與函數)作為開(kāi)發(fā)單位
微軟軟件產(chǎn)品的特性是用戶(hù)最終可見(jiàn)的相對獨立的功能單位，就如建筑材料一般，對應用軟件產(chǎn)品更是如此。系統軟件產(chǎn)品，如NT或者95的特性，對最終用戶(hù)通常不直接可見(jiàn)。微軟和其他公司有時(shí)簡(jiǎn)單地稱(chēng)這些不直接可見(jiàn)的特性為“函數”。
程序經(jīng)理承擔開(kāi)發(fā)一組特性或函數，實(shí)現從說(shuō)明經(jīng)測試、文檔化直到最后完成的過(guò)程。他們必須與開(kāi)發(fā)員合作，后者負責估計進(jìn)度表與完善每個(gè)特性。開(kāi)發(fā)員還要在一臺聯(lián)網(wǎng)開(kāi)發(fā)計算機上存儲一到幾個(gè)文件，用以保存特性的程序源代碼。大多數特性的開(kāi)發(fā)與改進(jìn)只要一名開(kāi)發(fā)員，而有的大型特性則要一個(gè)小的小組。
(感覺(jué)有點(diǎn)類(lèi)似于特征驅動(dòng)的開(kāi)發(fā)，要做好每日構建功能點(diǎn)的拆分一定要足夠細)
產(chǎn)品結構是決定其長(cháng)期結構完整性的基石
產(chǎn)品結構是產(chǎn)品內部的基干，它規定了重要的結構構件以及這些構件如何組裝到一起。產(chǎn)品結構及用于組裝結構的構件，提供了實(shí)現產(chǎn)品特性（即做詳細設計與編碼）的支柱。產(chǎn)品的結構對最終用戶(hù)而言，通常并非直接可見(jiàn)。只有結構要實(shí)現的特性是可見(jiàn)的。產(chǎn)品結構也是決定產(chǎn)品長(cháng)期結構完整性的基石。產(chǎn)品功能的任何改變都不應造成潛在的產(chǎn)品結構散架。
產(chǎn)品的層次結構
對于產(chǎn)品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產(chǎn)品特性進(jìn)行靈活的增加、刪除與改進(jìn)。此外良好的層次結構有助于產(chǎn)品在不同平臺上的移植。（例如Excel總共定義了五層，其中只有最底層的操作系統層是與平臺相關(guān)的，其它各層均是通過(guò)調用其下層所提供的API接口加以實(shí)現的，所以其移植極其方便。而在Windows95中通過(guò)“虛擬機”的概念實(shí)現了對16位、32位以及DOS程序的支持。）
小的結構文檔：源代碼是唯一文件
除了API文檔，微軟不對其產(chǎn)品結構生成相應的文檔，雖然有時(shí)高級開(kāi)發(fā)員可能會(huì )寫(xiě)下高層結構。對復雜的特性，許多開(kāi)發(fā)員在某些點(diǎn)記錄并復查特定于他們所負責的結構細節，但此工作是可選的，并不強制執行。除了源代碼文件與特性說(shuō)明，為數不多的組為新程序員準務(wù)了描繪某層結構的文檔（主要的數據結構，如何工作等等）。但是這些文件并不時(shí)常更新，經(jīng)理們也不要求項目組生成此類(lèi)內部文檔。在有關(guān)的說(shuō)明文件中，并不涉及實(shí)現問(wèn)題。開(kāi)發(fā)員應該知道如何去實(shí)現，或者能夠去學(xué)會(huì )。記錄的關(guān)于結構的文檔如此之少是因為“一個(gè)開(kāi)發(fā)員的工作是編寫(xiě)我們要賣(mài)的代碼，而不是花時(shí)間寫(xiě)高水平的設計文件”，“設計文件不應與源代碼分離”。分割代碼與“保持事情的簡(jiǎn)單”。(源代碼就是設計)
特性小組和作為"內容專(zhuān)家"的小組領(lǐng)導
特性小組一般由一個(gè)領(lǐng)導和3至8名開(kāi)發(fā)人員組成，工作于相關(guān)的特性領(lǐng)域。小組的規模常常視小組領(lǐng)導的經(jīng)驗和能力而定。特性小組領(lǐng)導向項目開(kāi)發(fā)領(lǐng)導匯報并負責項目的全部開(kāi)發(fā)工作；而項目開(kāi)發(fā)領(lǐng)導則擁有對產(chǎn)品的更為全局性的觀(guān)點(diǎn)，從而最有可能發(fā)現不互相關(guān)聯(lián)的問(wèn)題。在特性小組中的每個(gè)人均是此領(lǐng)域的“專(zhuān)家”，他們了解如何使用產(chǎn)品、了解競爭對手的產(chǎn)品、了解未來(lái)將向何處去。通常為便于交流，提高軟件的組織結構（軟件傾向于映射出構造它的組織的結構），應保持特性小組的小規模。(不在于小組的人數，而在于小組成員的整體技能不能差別太大)
原則五：靠個(gè)人負責和固定項目資源實(shí)旋控制
對于軟件項目而言，精確估計產(chǎn)品的開(kāi)發(fā)與交付進(jìn)度是很困難的。對此微軟采取的方法是將進(jìn)度安排和工作管理的責任推到最底層，即單個(gè)的開(kāi)發(fā)人員和測試人員那兒去。這保證了每個(gè)人除了作為小組的一部分外，還負有個(gè)人的責任。單獨的開(kāi)發(fā)人員設立他們自已的進(jìn)度表，程序經(jīng)理把單獨的進(jìn)度表匯總起來(lái)，再加上緩沖時(shí)間，以制定出一個(gè)全面的項目進(jìn)度表。頂層的總經(jīng)理也固定人員與時(shí)間等基本資源，以確保項目集中并限制其努力與創(chuàng )造程序。
關(guān)鍵的目標，尤其對應用軟件，是指明產(chǎn)品的目標出品日并爭取盡可能長(cháng)久地堅持它。程序經(jīng)理和開(kāi)發(fā)員從出品日回溯，規定中間的項目里程碑的日期。這個(gè)“固定的出品日法“的中心在開(kāi)發(fā)員身上。以避免因為項目沒(méi)有固定的結束點(diǎn)，導致在最終無(wú)用的設計、再設計和測試的循環(huán)中消耗一年或更多的時(shí)間。
開(kāi)發(fā)人員做出他們自已的進(jìn)度估計
“日期設定方法"。但是開(kāi)發(fā)人員一般會(huì )做出較樂(lè )觀(guān)的估計，因此開(kāi)發(fā)經(jīng)理還需對他們所提供的日期進(jìn)行調整并加上緩沖時(shí)間以避免因因信息不完全而出現的問(wèn)題。微軟這種制定進(jìn)度的方法的優(yōu)點(diǎn)在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經(jīng)理定的；進(jìn)度總是富有進(jìn)取性，因為開(kāi)發(fā)人員不可避免地會(huì )低估他們真正需要的時(shí)間。
對細致的任務(wù)的進(jìn)度估計
微軟的第二個(gè)進(jìn)度安排方法是：對要完成的任務(wù)做非常詳盡的考慮，在此基礎上請開(kāi)發(fā)人員給出他們對“實(shí)現”的估計，以此力圖“促使”更加現實(shí)主義并避免過(guò)度低估。
通常微軟把任務(wù)細化到4小時(shí)（半天）到3天之間。對于準確進(jìn)度的安排，微軟的經(jīng)理是這樣認識的：“任何任務(wù)只要超過(guò)一星期，那人們就一定沒(méi)有充分地全盤(pán)考慮它。任何任務(wù)某人估計只用少于半天就可完成，則他對它考慮得太多了。他應該用更多的時(shí)間去編程，更少的時(shí)間來(lái)考慮”。對于類(lèi)似類(lèi)于Windows NT之類(lèi)的操作系統而言，進(jìn)度安排更加困難，對其一般以幾天或者半周為工作單位進(jìn)行進(jìn)度估計。
安排開(kāi)發(fā)人員與小組進(jìn)度時(shí)的心理學(xué)
當項目變大時(shí)，微軟把員工分成小組。然后經(jīng)理把進(jìn)度的責任和所有權盡可能地分發(fā)下去，直到小組和個(gè)人；這使二者都產(chǎn)生了一種擁用工作的感覺(jué)。它還在小組中，個(gè)人中，尤其是小組領(lǐng)導中造成強烈的跟上其它同事預計進(jìn)度的壓力，因為經(jīng)理可能再平衡進(jìn)度，從落后的小組或個(gè)人手中拿走工作。這樣，同事間的壓力使經(jīng)理不需要太多的努力就可以對個(gè)人或單個(gè)小組的進(jìn)程實(shí)施嚴格控制。(厲害)
"固定的"出品日(RTM: Release To Manufacture)
為了把創(chuàng )造力約束在時(shí)間限制之中，微軟現在在新產(chǎn)品或者產(chǎn)品新版本開(kāi)始前爭取固定出品日，至少是有出品日的內部目標。這給人們施加砍去特性和集中在一個(gè)項目上的壓力，逼迫他們去苦苦思考應將哪個(gè)新特性加入產(chǎn)品中。雖然最終產(chǎn)品的交付目標可能是由高級執行人員設定，但是開(kāi)發(fā)人員與小組仍然設定他們自已的進(jìn)度表。
微軟一般根據預先的時(shí)間進(jìn)度的大致估計出一個(gè)RTM日期，然后向前回溯相應的各個(gè)Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（CodeComplete）等等各個(gè)Milestone的相應日期。制定出十分詳盡的產(chǎn)品研究開(kāi)發(fā)時(shí)間進(jìn)度表，產(chǎn)品開(kāi)發(fā)組的各個(gè)成員以這個(gè)進(jìn)度表為目標統一協(xié)調工作。
微軟十分強調軟件開(kāi)發(fā)過(guò)程中的Teamwork Spirits，這種理念貫穿在微軟各個(gè)產(chǎn)品開(kāi)發(fā)的各個(gè)階段。這也是微軟得以成功的一個(gè)十分重要的原因。
