微軟公司軟件開發模式簡介在產品定義與開發過程中，微軟件遵循著一種可稱之為靠改進特性與固定資源來激發創造力的戰略。該戰略可分為五個原則：一、 將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。二、運用想象描述和對特性的概要說明指導項目。三、根據用戶行為和有關用戶的資料確定產品特性及其優先順序。四、建立模塊化的和水平式的設計結構，并使項目結構反蚋產品結構的特點。五、靠個人負責和固定項目資源實施控制。原則一：將大項目分成若干里程碑式的重要階段，各階段之間有緩沖時間，但不進行單獨的產品維護。項目進度安排與里程碑微軟通常采用同步穩定產品開發法。典型項目的生命周期包括三個階段：計劃階段完成功能的說明和進度表的最后制定，開發階段寫出完整的的源代碼，穩定化階段完成產品，使之能夠批量生產。這三個大階段以及階段間內在的循環方法與傳統的瀑布式開發方式很不相同，后者是由需求、詳盡設計、模塊化的代碼設計與測試、集成測試以及系統測試組成的。而微軟的三個階段更像是風險驅動的、漸進的螺旋式的生命周期模型。計劃階段的產品是想象性描述與說明文件，用來解釋項目將做什么和息么做。在管理人員擬定進度表、開發員寫出代碼之前，這些東西都促進了人們對設計問題的思考與。討論開發階段圍繞三次主要的內部產品發布來進行；稱定化階段集中于廣泛的內部與外部測試。在整個產品生產周期中，微軟都使用了緩沖時間的概念。緩沖時間使開發組能夠對付意外的困難和影響到時間進度的變故，它也提供了一種手段，可以緩和及時發貨與試圖精確估計發貨時間之間的矛盾。在開發和穩定化階段的所有時間中，一個項目通常會將2/3的時間用于開發，1/3的時間用于穩定化。(Office部門副總裁曾這樣概述通常的進度：一般說來，在總的進度表中，用一半的時間寫出產品，留下另一半的時間調試或應付意外事故。這樣，如果我有一個兩年的項目，我會用一年來完成事先想好的東西如果事情有點麻煩，我便去掉我認為不太重要的特性。)這種里程碑式的工作過程使微軟的經理們可以清楚地了解產品開發過程進行到了哪一步，也使他們在開發階段的后期有能力靈活地刪去一些產品特性以滿足發貨時期的要求。計劃階段計劃階段是在一個項目的生命周期中，所有于開發前進行的計劃所占用的時間。計劃階段產生出想象性描述、市場營銷計劃、設計目標、一份最初的產品說明、為集成其他組開發的構件而規定的接口標準、最初的測試計劃、一個文檔策劃(印刷品和聯機幫助形式的)以及一份可用性問題清單。計劃階段從想象性描述開始。想象性描述來自產品經理以及各產品單位的程序經理；它是對產品作業的市場營銷設想，包括了對況爭對手產品的分析以及對示來版本的規劃。想象性描述也可能討論在前一次版本中發現面必須解決的問題以及應添加的生要功能。所有這些都基于對顧客和市場的分析以及從產品支持服務組處得到的資料。說明文件從一個大綱開始，然后定義出新的或增加的產品特性，并對其賦以不同的優先級。說明文件只是產品特性的一個預備性概覽；從開始開發到項目完成它要增加或變化20% - 30%。雖然在生命周期的后期說明變化一般較小，但越到后期，開發員就越是必須具充分的理由來作改變。通常程序經理使用VB創建項目原型。他們也開展設計可行性研究以了解設計中的取舍情況，盡快做出涉及產品說明的決定。對于重要產品的說明需由公司高層領導進行復審。對于不太生要的產品，則由部分經理去完成。開發階段開發階段的計劃對三四個主要的里程碑版本都個咖分配一組特性，規定出特性的細節和技術上的相關性，記錄下單個開發員的任務以及對進度的估計。在開發階段中，開發員在功能性說明的指導下寫源代碼，測試員寫出測試項目組以栓查產品的特性與工作范圍是否正常，用戶教育人員則編寫出文檔草案。當測試員發現錯誤時，開發員并不是留待以后處理，而是馬上改正，并在整個開發階段內使測試不斷地、自動地進行。這就改善了產品的穩定性并且使版本發布日期更易估計。當達到項目中的一定階段點后(40%時)，開發員就試圖鎖定產品的主要功能要求或特性，從此只允許小的改動。如果在此點之后開發員想作大的改動，他們必須與程序經理以及開發經理，問題也許還要征求產品部門經理的意見。一個項目是圍繞著3或4個主要的內部版本，或里程碑子項目來組織開發階段的。一般用2至4個月來開發每一個主要的里程碑版本。每個版本都包括其自身的編碼、優化、測試以及調試活動。項目為意外事故保留總開發1/3的時間，即緩沖時間。(蘋果公司的小組是割裂的，獨立的，各自開發各自的東西。在還有3個月就要發貨時，才會將所有的東西集成起來；Boland公司以一種漸近的方式進行開發，即把工作分成許多小的部分，并且總是讓開發的東西能夠運轉。看起來似乎這種漸進的方法費時較長，但實際上幾護沒有用過很長時間，因為這使你總是能掌握住事情真實的情況。)當對最后一個主要的里程碑版本做了測試與穩定化之后，產品就要進行外觀固定，即確定產品的主要用戶界面，如菜單、對話框以及文件窗口等。此后有關用戶界面將不再進行大的改動，以免引進同步修改相應文檔的困難。穩定化階段穩定化階段著重于對產品的測試與調試。項目在此階段盡量不再增加新的功能，除非是競爭產品或者市場發生了變化。穩定化階段也包括了緩沖時間，以應付不可預見的問題或者延遲。項目進度表中的緩沖時間微軟使用緩沖計劃，以在最高的效率與較好地對未來作預計之間求得平衡。這種應付突發事件的時間在開發和穩定化過程中是每一個主要里程碑的一部分。緩沖時間主要用于彌補由于對特性的不完全理解，或者是技術困難或是由于疏忽而忘記把任務寫入進度，或者是未料到的難題而形成的漏洞。緩沖時間有助于一個項目適應意料之外的事件。原則二：運用想象性描述和對特性的概要說明指導項目為了給出足夠的開發框架以使工作能持續進行，并且能容納開發過程中出現的變化并保持足夠的靈活性，微軟采用想象性描述和概要的說明來指導項目開發，而不是在一開始就努力寫出一份完整和詳細的說明。所謂想象性描述是由程序經理和來自市場營銷組的產品計劃人員共同編寫的一份非常短的文件，在其中主要是定義產品開發的目標(不涉及產品的具體細節！)。通常對一個全新的產品，想象性描述一般會相對較詳細，在其中還含有一份粗略的說明文件。總的來說，微軟對于想象性描述的要求是：越短越好，盡量說明產品不做什么(而不是產品要做什么！)。運用想象性描述，程序經理開始編寫功能說明文件，該文件解釋產品的特性是什么以及這些特性如何與其他特性及產品發生關系。最初它只是一個概要性的說明文件，隨著項目的進展，程序經理會隨時向其中添加更多的細節，最終的說明文件將變得象用戶手冊一樣。完整的說明不只起著對產品最新功能的描述作用，而且它還是在產品投產與發貨之前進行測試與評估的主要依據。想象性描述有助于決定刪除哪些特性微軟內的各個開發組采用想象性描述幫助細化產品版本的規定主題，然后以此主題來決定是否需要增加產品各個可能的特性。通常不要輕易改變所確定的主題，否則可能造成產品開發上的混亂。編寫說明文件說明文件在產品小組的所有成員之間，產品小組之間以及產品小組與管理部門之間起著傳遞產品的設想與要求的作用。在說明文件中必須清楚地描述產品特性(描述每個特性如何工作，外觀如何以及從用戶的角度出發如何與用戶交互。如果特性有一個界面，還應包括一張示意圖，以顯示出界面的效果)并賦于其相應的優先級。程序經理據此建立起項目的開發起度表。此外在其中還應包括以下各項內容：用一句話表示的項目開發目的，關于產品是什么與不是什么的清單，對顧客的定義，對競爭產品的定義，產品對系統的要求(包括操作系統版本、最小內存要求、硬盤空間、處理器速度以及顯示器分辯率)，對第三方(如打印機驅動程序、組件)的任何依賴性。程序經理負責協調并寫下說明程序經理應考慮以下問題：這項特性的要點是什么用戶如何使用該特性這項特性有意義嗎該產品中或微軟的其他產品中有類似的特性嗎有哪些問題補遺漏了組內的交流令人滿意嗎最終程序經理通過與組內開發人員的共同討論決定有關特性的內容，并將其寫下來。構造原型構造原型是程序經理具體說明一件新產品或一個新版本的最好方法，這從許多方面來說都使開發前測試成為可能，尤其在可用性方面，并且有助于對與用戶交互情況作出好的理解，它也能使產品說明更緊湊。微軟的開發人員通常采用VB構造用戶界面原型，但是對于構造計算機屏幕模型之類的工作，畫筆(Paintbrush)也是一個很好用的工具。死板的說明變成有生命的文件說明不應過于詳細以至限制了發明創造。在項目開發過程中，說明文件的早期版本會有相當大的增加與改變。由于說明的變動可能會導致相應開發工作的極大變動，所以微軟通常是將精力首先集中于那些沒有什么用戶界面的特性上，因為在完成開發前不必去了解用戶對它們有何反應，也就是說這些特性不大可能改變。然后再面對其它特性。但是當產品開發到一定程序后，例如40%之后，程序經理必須嚴格控制對特性的修改(主要是指增加新的特性)，否則不光會造成開發延遲，而且會壓縮可用的測試時間。原則三：根據用戶行為和有關用戶的資料確定產品牲及其優先順序對于一個開發項目而言，如何確定最終產品中應包含什么特性通常是比較困難的一件事。為此微軟采用了一個稱之為基于行為制定計劃的方式來進行特性選擇 與優先級安排。基于行為制定計劃法從對用戶行為，諸如寫信或做預算，做系統研究開始。然后，根據某一特性在支持重要的或者是經常的用戶行為上的程序對其進行評價。這樣做的優點是對特性取舍的更理性的討論，對顧客想要做什么的更好的安排，對某個給定特性是否方便了特定任務的更集中的辯論，可讀性更強的說明，以及在市場營銷、用戶教育和產品開發中更好地同步。特性選擇和優先級安排中的基于行為制定計劃基于行為制定計劃法中的關鍵點在于按用戶行為、產品特性以及行為和特性之間的內部聯系來分析產品。程序經理和產品計劃者把產品試圖支持的用戶任務或方案分成大約20個行為，然后他們努力把行為(以及任何子行為)映射入微軟的現行特性和競爭對手產品的特性中去。他們也把行為映射到不同的顧客形象或不同的市場部分中去。當說明產品的新版本時，基于行為制定計劃法幫助程序經理和開發員集中他們的精力與創造力。向Excel之類的項目爭取在每個新版本中加入的主要行為不超過四個。絕大多數制性直接映射入這些行為之中。該做法使項目可以按特性對用戶的價值來進行分級。通過分級，促使程序經理和開發人員都行動起來，使他們的特性支持盡可能多的行為。這種良性競爭對于用戶有益，同時也利于提高生產率。為顧客行為而非產品特性懼資料基于和為制定計劃進，項目在計劃階段首先集中于和為，其次才是特性。程序經理和市場營銷人員并不去思考和排除他們喜愛的特性，再圍繞它們搞出想象性描述的草案。他們真正做的是列出一份顧客都做些什么的清單，然后把想象性描述集中于支持那些行為的特性上。以行為為中心對產品進行全面考慮由于基于行為制定計劃法是從整個產品的觀點著眼，因此有助于在不同職能上工作的項目成員理解產品做什么，以及其他產品的相應特性如何可能支持那些需要或不需要其他應用軟件產品的行為。做市場營銷研究以支持基于行為制定計劃法為支持基于行為制定計劃法，從市場營銷組來的產品經理與程序經理、開發人員一起開展一些聯合的研究，如指導對用戶的研究工作。然而，一般來說是產品經理做大多數的研究，并可使其更明確地影響微軟產品的演進。原則四：建立模塊化的和水平式的設計結構，并使項目結構反映產品結構的特點微軟產品設計中的一個關鍵概念是產品的基礎結構，尤其是生命周期短的應用軟件，應隨項目的進展變得更加單一(而不是錯綜復雜)。當開發組構造產品的第一版時，他們更多地使用分級式結構，好為產品設計規定出一個最初的架構。隨著時間推移，他們向單一的結構邁進，以使項目能集中于特性開發。項目需要逐漸的嗇和刪除我，鬃著時間改變和發展我，以及增加產品間特性表現和運作的一致性。微軟越來越強調不同產品間的特性共享。共享有助于使不同產品的性能與感覺都統一協條起來；它也方便了需要不只一個應用軟件的用戶，減少了代碼的重復書寫，縮小了單獨一個應用軟件的規模。微軟用特性小組組織產品開發，這種方法使得每個人都容易明白小組是如何與整個產品相關聯的。項目從規定概要說明開始。概要說明的形式是一份已確定了優先級安排的內容清單，涉及產品下一版本將要開發的相對獨立的特性，以便由分開的特性小組加以開發。程序經理和開發員把項目分成特性子集，再將之分配給每個特性小組，讓他們在3到4個主要的內部項目里程碑中進行生產。這種產品組織與開發法使微軟能靠簡單地增加開發員和創建一個大的小組來漸進地增加產品的功能。把特性(與函數)作為開發單位微軟件產品的特性是用戶最終可見的相對獨立的功能單位，就如建筑材料一般，對應用軟件產品更是如此。系統軟件產品，如NT或者95的特性，對最終用戶通常不直接可見。微軟和其他公司有時簡單地稱這些不直接可見的特性為函數。程序經理承擔開發一組特性或函數，實現從說明經測試、文檔化直到最后完成的過程。他們必須開開發員合作，后者負責估計進度表與完善每個特性。開發員還要在一臺聯網開發計算機上存儲一到幾個文件，用以保存特性的程序源代碼。大多數特性的開發與改進只要一名開發員，而有的大型特性則要一個小的小組。產品結構是決定其長期結構完整性的基石產品結構是產品內部的基干，它規定了重要的結構構件以及這些構件如何組裝到一起。產品結構及用于組裝結構的構件，提供了實現產品特性(即做詳細設計與編碼)的支柱。產品的結構對最終用戶而言，通常并非直接可見。只有結構要實現的特性是可見的。產品結構也是決定產品長期結構完整性的基石。產品功能的任何改變都不應造成潛在的產品結構散架。產品的層次結構對于產品，也可以采用層次結構的方法加以分析。通常定義良好的層次結構有助于對產品特性進行靈活的增加、刪除與改進。此外良好的層次結構有助于產品在不同平臺上的移植。(例如Excel總共定義了五層，其中只有最底層的操作系統層是與平臺相關的，其它各層均是通過調用其下層所提供的API接口加以實現的，所以其移植極其方便。而在Windows 95中通過虛擬機的概念實現了對16位、32位以及DOS程序的支持。)小的結構文檔：源代碼是唯一文件除了API文檔，微軟不對其產品結構生成相應的文檔，雖然有時高級開發員可能會寫下高層結構。對復雜的特性，許多開發員在某些點記錄并復查特定于他們所負責的結構細節，但此工作是可選的，并不強制執行。除了源代碼文件與特性說明，為數不多的組為新程序員準務了描繪某層結構的文檔(主要的數據結構，如何工作等等)。但是這些文件并不時常更新，經理們也不要求項目組生成此類內部文檔。在有關的說明文件中，并不涉及實現問題。開發員應該知道如何去實現，或者能夠去學會。記錄的關于結構的文檔如此之少是因為一個開發員的工作是編寫我們要賣的代碼，而不是花時間寫高水平的設計文件，設計文件不應與源代碼分離。分割代碼與保持事情的簡單特性小組和作為內容專家的小組領導特性小組一般由一個領導和3至8名開發人員組成，工作于相關的特性領域。小組的規模常常視小組領導的經驗和能力而定。特性小組領導向項目開發領導匯報并負責薦目的全部開發工作；而項目開發領導則擁有對產品的更為全局性的觀點，從而最有可能發現部部互相關聯的問題。在特性小組中的每個人均是此領域的專家，他們了解如何使用產品、了解競爭對手的產品、了解未來將向何處去。通常為便于交流，提高軟件的組織結構(軟件傾向于映射出構造 它的組織的結構)，應保持特性小組的小規模。原則五：靠個人負責和固定項目資源實旋控制對于軟件項目而言，精確估計產品的開發與交付進度是很困難的。對此微軟采取的方法是將進度安排和工作管理的責任推到最底層，即單個的開發人員和測試人員那兒去。這保證了每個人除了作為小組的一部分外，還負有個人的責任。單獨的開發人員設立他們自已的進度表，程序經理把單獨的進度表匯總起來，再加上緩沖時間，以制定出一個全面的項目進度表。頂層的總經理也固定人員與時間等基本資源，以確保項目集中并限制其努力與創造程序。關鍵的目標，尤其對應用軟件，是指明產品的目標出品日并爭取盡可能長久地堅持它。程序經理和開發員從出品日回溯，規定中間的項目里程碑的日期。這個固定的出品日法的中心在開發員身上。以避免因為項目沒有固定的結束點，導致在最終無用的設計、再設計和測試的循環中消耗一年或更多的時間。開發人員做出他們自已的進度估計比爾犯譴那康魑砣每焙托檣瓚親砸訓哪勘輳骸八姓廡掌詼際切槎娜掌凇揮釁淥速彩醞忌瓚飧鋈掌凇頤竊詿笤?0年前就拋棄了那種自目而下的日期設定方法。但是開發人員一般會做出較樂觀的估計，因此開發經理還需對他們所提供的日期進行調整并加上緩沖時間以避免因因信息不完全而出現的問題。微軟這種制定進度的方法的優點在于：它從人們那兒得到更多的合作，因為日期是自已定的，不是經理定的；進度總是富有進取性，因為開發人員不可避免地會低估他們真正需要的進間。對細致的任務的進度估計微軟的第二個進度排方法是，對要完成之任務做非常詳盡的考慮，在此基礎上請開發人員給出他們對實現的估計，以此力圖促使更加現實主義并避免過度低估。通常微軟把任務細化到4小時(半天)到3天之間。對于準確進度的安排，微軟的經理是這樣認識的：任何任務只要超過一星期，那人們就一定沒有充分地全盤考慮它。任何任務某人估計只用少于半天就可完成，則他對它考慮得太多了。他應該用列多的時間去編程，更少的時間來考慮。對于類似類于Windows NT之類的操作系統而言，進度安排更加困難，對其一般以幾天或者半周為工作單位進行進度估計。安排開發人員與小組進度時的心理學當項目變大時，微軟把員工分成小組。然后經理把進度的責任和所有權盡可能