五、關注交付的業務價值
客戶需要的是一把梯子，系統分析員了解到的是一張凳子，開發人員做出來的是一張桌子，測試人員以為是一張椅子�？瓷先タ尚�，但這樣的情況卻經常發生在我們的身邊。
關注交付的業務價值，意思就我們工作中的每一份工作產品，都應該是需求驅動做出來的，這樣才能保證我們最終做出的軟件就是客戶所需要的東西。這個原理有以下幾層意思：
l 小組成員要對客戶的需求有一致的充分的理解。
l 要讓客戶積極參與到項目過程中去，隨時了解小組的理解和客戶的需要是否一致。
l 需求驅動地完成所有工作，保證最后的軟件產品符合客戶的需要。
六、保持靈巧，預測變化
軟件是智力型創造性活動，保持靈活、適應變化是軟件開發的最高境界了！我感覺這條原理是最難把握的一條了。
這個原理主要體現在以下方面：
l 軟件開發過程
微軟采用的不是RUP，也不是XP，而是類似于螺旋形的階段式分版本發布。微軟會把軟件分成若干的版本發布，除了平時我們見到的Beta版、Release版，其實在Beta版之前還會有若干的內部版本。每個版本都包含相對完整的功能，都能實現部分業務價值。每一個版本就是一個開發周期，每個周期包含遠景、計劃、開發、穩定、部署五個階段。這樣的一種開發模型，能很好地適應需求變化，發現設計、編碼缺陷，優化設計，更容易控制軟件質量，便于隨時做出商業決策。
圖一：微軟的開發模型
l 設計方案
執著于優雅設計的人士，可能很喜歡做出完美無缺的設計，關注于業務的人士，可能更關注于盡快要拿出軟件。我們追求的是適度設計，而不是過度設計，如何做出一個簡單的而又適應變化的設計，是對軟件設計高手們的一大考驗了。
七、質量投資
“質量第一”是很多軟件公司的口號，而且僅僅是口號而已，你們的項目有這樣的一些問題嗎？
代碼沒有經過簡單的冒煙測試，甚至不進行是否通過編譯的測試，就直接提交。
為了趕時間不寫設計或者寫了不能指導編碼的設計文檔。
開發進度推遲，測試時間被壓縮，為了保證軟件發布的時間，在不充分測試情況下交付軟件，更甚者不測試軟件，直接讓客戶測試。
開發過程中發現的問題，只要能不解決的就不解決，進度優先！
測試中發現的易用性方面的缺陷，因不會嚴重影響使用，一律不解決！
質量投資要求我們有零缺陷的意識，零缺陷意識要貫穿在全部的工作中，包括：
l 零缺陷文檔
計劃、需求、設計等開發過程中產生的文檔，要用一次寫好的決心來編寫，所有文檔都應該發揮它的價值，而不是為了寫文檔而寫文檔。要讓相關的小組成員對該文檔發表意見，重視他們的意見并修改文檔。
l 零缺陷代碼
要用一次把代碼寫好，不讓測試發現缺陷的態度來寫好代碼，寫出垃圾代碼是不負責任的行為！
l 零缺陷發布
用質量投資的態度對待所有缺陷，包括自己代碼產生的缺陷，對用戶負責，不滿足質量要求的軟件堅決不發布。
全體小組成員都應該同步達到零缺陷里程碑，本著一步一個腳印、不斷追求高質量的態度來完成全部工作。
八、學習所有的經驗
象Windows這樣的一些偉大的軟件，都是經過很多人通過很長的時間做出來的，工作量之大、難度之大不亞于一些偉大的建筑工程。軟件工程與建筑工程最大的優勢就是，如果軟件做得不好，可以推倒重來，但建筑工程就不能這樣做了。
我拿軟件工程與建筑工程比較，目的就是想強調做軟件是很強調學習的，很強調不斷改進的（當然建筑工程也重視學習）。我們應該慶幸，我們這些做軟件的要比做建筑工程的要幸福的多了，我們不太可能犯一些不可以彌補的錯誤。
“那些忘記過去的人肯定會重復過去（的錯誤）�！�
——George Santayana
我們要讓大家從自己或者別人的失敗和成功中學習，要幫助小組成員再次獲得成功，捕捉和共享技術的或者非技術的最佳實踐，并想辦法讓學習制度化。
學習制度化的辦法很多，如項目總結、例會等，但要注意的是學習應該是隨時進行的，抱著學習一切可以學習的態度來工作。
微軟的項目團隊結構
談了微軟MSF的八大基本原理，我們來看看，微軟的團隊是怎樣組成的？
很多軟件公司的開發團隊，大部分是由一名項目經理，若干項目成員組成，項目成員包括需求分析、架構設計、編碼、測試等角色。
而微軟的團隊非常特別是沒有項目經理的，由6類角色組成，分別是產品經理(Product Management)、程序經理(Program Management)、開發(Development)、測試(Test)、發布管理(Release Management)、用戶體驗(User Experience)。
圖二：微軟的團隊角色
各類角色負責的職責如下：
|
角色 |
目標 |
職能領域 |
職責 |
|
產品管理 |
滿足客戶 |
市場開發 業務價值 客戶擁護 產品計劃 |
為項目小組充當客戶角色 驅動共同的項目和方案設想 管理客戶需求說明 開發和維護業務案例 管理客戶期望 驅動產品特征、日程表、資源權衡決策 管理市場開發、產品宣傳和公共關系 開發、維護和執行交流計劃 |
|
程序經理 |
交付滿足項目約束的解決方案 |
項目管理 解決方案體系結構 過程保證 管理服務 |
驅動開發過程以期按時的交付產品 管理產品規格說明書 － 首席項目構架師 促進小組內部的交流和商議 維護項目日程表和報告項目狀態 驅使關鍵的權衡決策的實現 開發、維護和執行項目總規劃和日程表 驅使和管理風險評估和風險管理 |
|
開發 |
根據規格說明創建解決方案 |
技術咨詢 實現的構架和設計 應用程序開發 基礎結構開發 |
指定物理設計的特征 估算完成每個特征所需的時間和精力 構建每個特征并監督其實現 準備部署時使用的產品 為小組提供技術主題的專門知識 |
|
測試 |
在所有產品質量事宜被識別并處理后進行發布 |
測試規劃 測試工程 測試報告 |
確保了解所有問題 決定測試策略和制定計劃 執行測試 |
|
用戶體驗 |
提高用戶效率 |
技術交流 培訓 可用性 用戶界面設計 國際化 易用性 |
為項目小組充當用戶的角色 管理用戶需求說明 設計和開發性能支持系統 驅動可用性和用戶性能增效的權衡決策 為用戶提供幫助特點和幫助文檔的規格說明書 開展和提供用戶培訓 |
|
發布管理 |
進行平滑的部署及日常運行 |
基礎結構 支持 操作 業務發布管理 |
管理產品部署 驅使可用性和可支持性權衡決策 管理各種操作、支持和交付渠道之間的關系 為項目小組提供后勤支持 |
微軟的團隊模型中的6種角色，不代表團隊最少要6個人組成，一個人可以兼任多種角色，也不代表每一種角色只有一個人，可以多個人公擔一個角色。
微軟這種團隊結構與我們常見的團隊結構相比，有這樣的特點：
l 扁平對等的團隊結構，強調每個人的價值
這種團隊結構，是“賦予小組成員權力”、“清晰的責任和共同的職責”、“推動開放式溝通”這三個原理的表現。這樣的結構，讓每位小組成員都感受得到自己的重要性，項目的成敗與每位成員直接相關。這樣的結構更容易調動每位成員的工作積極性，更容易讓團隊激發工作熱情，產生更多的創造性成果。
l 微軟很重視的我們常會忽略的用戶體驗和發布管理
微軟團隊的6種角色所負責的工作，覆蓋了軟件開發中需要考慮的各個方面，用戶體驗、發布管理是常被我們忽視的地方。微軟軟件的用戶體驗都非常好，規范一致的界面，詳細的幫助系統，良好易用的安裝程序，良好的技術支持等。微軟創造了很多界面規范，操作習慣，這些都是我們需要認真去學習的。
知識管理
軟件開發團隊是知識密集型的團隊，學習再學習，是軟件開發團隊的重要特點。沒有學習的團隊，是沒有活力的！
如何保證團隊的每位成員都具備完成本項目的能力呢？就緒管理就是來解決這個問題的。
小組成員的6種角色，需要不同的技能來完成本職工作，任何一種角色技能的欠缺，都會影響最終解決方案。小組應該根據項目的前景，列出各成員所欠缺的技能，這些技能包括技術方面的也包括非技術方面的，安排相應的學習計劃、培訓計劃，保證每位成員的技能都達到要求。
圖三：就緒管理
就緒管理是知識管理的重要組成部分，知識管理還包括知識的共享和積累、技能的評估、技能提升機制等。從微軟提供的系列認證，如MCSD、MCP等，大家就可以感受到微軟系統的培訓制度。項目團隊的知識管理，應該在組織層面上進行，跨越項目組進行，每位團隊成員都可以學習其他團隊的經驗，每位團隊成員都可以共享知識給其他的團隊。
MSF是靈丹妙藥嗎？
2000年我第一次參加MSF課程的時候，給我很大的震撼，微軟的團隊管理很有學問，而很切合我們這些軟件開發人員的心聲。MSF的團隊管理辦法，似乎就是解決我們開發團隊管理問題的靈丹妙藥。但實際上沒有這么簡單，這種管理辦辦法要成功，還必須滿足這樣的條件：
l 必須要有坦誠、積極、向上的企業文化。
沒有這樣的文化，什么“推動開發式溝通”、“質量投資”等原理是難以做到的。
l 團隊中每一位成員都是能力相當水平相當的，沒有素質特別差的成員。
這點做不到，是很難應用“為共同的前景工作”、“賦予小組成員權力”等原理的。
實際上這兩點都是很難做到的，微軟是通過招聘優秀的人來滿足這兩個前提條件，另外美國文化下成長的軟件開發人員，都是很有主見，溝通很主動，表達能力強，也注重自我價值的，而我國開發人員，很多是少說話多干事，表達能力特別是書面表達能力差的。
當然難做到不代表做不到，MSF的團隊管理中有很多值得我們學習、品味、實踐的地方，我們要做的是掌握其精髓，結合我們自己的實際情況，靈活地用起來。本文結合我多年實踐MSF經驗，談了自己的體會，希望對大家有用。
