關注交付的業務價值
客戶需要的是一把梯子，系統分析員了解到的是一張凳子，開發人員做出來的是一張桌子，測試人員以為是一張椅子。看上去可笑，但這樣的情況卻經常發生在我們的身邊。關注交付的業務價值，意思我們工作中的每一份工作產品，都應該是需求驅動做出來的，這樣才能保證我們終做出的軟件是客戶所需要的東西。這個原理有以下幾層意思：
小組成員要對客戶的需求有一致的充分的理解;
要讓客戶積極參與到項目過程中去，隨時了解小組的理解和客戶的需要是否一致;
需求驅動地完成所有工作，保證后的軟件產品符合客戶的需要。
保持靈巧，預測變化
軟件是智力型創造性活動，保持靈活、適應變化是軟件開發的高境界了，筆者認為這條原理是難把握的一條了。
這個原理主要體現在以下方面：
軟件開發過程
微軟采用的不是RUP，也不是XP，而是類似于螺旋形的階段式分版本發布。微軟會把軟件分成若干的版本發布，除了平時我們見到的Beta版、Release版，其實在Beta版之前還會有若干的內部版本。
每個版本都包含相對完整的功能，都能實現部分業務價值。每一個版本是一個開發周期，每個周期包含遠景、計劃、開發、穩定、部署五個階段。這樣的一種開發模型，能很好地適應需求變化，發現設計、編碼缺陷，優化設計，更容易控制軟件質量，便于隨時做出商業決策。
設計方案
執著于優雅設計的人士，可能很喜歡做出完美無缺的設計，關注于業務的人士，可能更關注于盡快要拿出軟件。我們追求的是適度設計，而不是過度設計，如何做出一個簡單的而又適應變化的設計，是對軟件設計高手們的一大考驗。
質量投資
“質量第一”是很多軟件公司的口號，而且僅僅是口號而已，你們的項目有這樣的一些問題嗎？
代碼沒有經過簡單的冒煙測試，甚至不進行是否通過編譯的測試，直接提交。
為了趕時間不寫設計或者寫了不能指導編碼的設計文檔。
開發進度推遲，測試時間被壓縮，為了保證軟件發布的時間，在不充分測試情況下交付軟件，更甚者不測試軟件，直接讓客戶測試。
開發過程中發現的問題，只要能不解決的不解決，進度優先！
測試中發現的易用性方面的缺陷，因不會嚴重影響使用，一律不解決！
質量投資要求我們有零缺陷的意識，零缺陷意識要貫穿在全部的工作中，包括：
零缺陷文檔
計劃、需求、設計等開發過程中產生的文檔，要用一次寫好的決心來編寫，所有文檔都應該發揮它的價值，而不是為了寫文檔而寫文檔。要讓相關的小組成員對該文檔發表意見，重視他們的意見并修改文檔。
零缺陷代碼
要用一次把代碼寫好，不讓測試發現缺陷的態度來寫好代碼，寫出垃圾代碼是不負責任的行為。
零缺陷發布
用質量投資的態度對待所有缺陷，包括自己代碼產生的缺陷，對用戶負責，不滿足質量要求的軟件堅決不發布。
全體小組成員都應該同步達到零缺陷里程碑，本著一步一個腳印、不斷追求高質量的態度來完成全部工作。
學習所有的經驗
象Windows這樣的一些偉大的軟件，都是經過很多人通過很長的時間做出來的，工作量之大、難度之大不亞于一些偉大的建筑工程。軟件工程與建筑工程大的優勢是，如果軟件做得不好，可以推倒重來，但建筑工程不能這樣做了。
我拿軟件工程與建筑工程比較，目的是想強調做軟件是很強調學習的，很強調不斷改進的（當然建筑工程也重視學習）。我們應該慶幸，我們這些做軟件的要比做建筑工程的要幸福的多了，我們不太可能犯一些不可以彌補的錯誤。
我們要讓大家從自己或者別人的失敗和成功中學習，要幫助小組成員再次獲得成功，捕捉和共享技術的或者非技術的佳實踐，并想辦法讓學習制度化。
學習制度化的辦法很多，如項目總結、例會等，但要注意的是學習應該是隨時進行的，抱著學習一切可以學習的態度來工作。
微軟的項目團隊結構
談了微軟MSF的八大基本原理，我們來看看，微軟的團隊是怎樣組成的？
很多軟件公司的開發團隊，大部分是由一名項目經理，若干項目成員組成，項目成員包括需求分析、架構設計、編碼、測試等角色。
而微軟的團隊非常特別是沒有項目經理的，由6類角色組成，分別是產品經理(Product Management)、程序經理(Program Management)、開發(Development)、測試(Test)、發布管理(Release Management)、用戶體驗(User Experience)。
各類角色負責的職責如表1所示。
