第1章IT企業研發和管理綜述

TOC\o"1-5"\h\z\o"CurrentDocument"1.1企業研發管理的一些理念 2.\o"CurrentDocument"1.2常見方法論介紹和優缺點分析 3.\o"CurrentDocument"1.2.1覆蓋產品生命周期的研發管理體系 3.\o"CurrentDocument"ISO9000族質量管理體系 5.\o"CurrentDocument"CMM/CMMI 6\o"CurrentDocument"1.2.4項目管理知識體系（PMBOK） 9\o"CurrentDocument"1.2.5敏捷開發思想 1.1.\o"CurrentDocument"1.2.6RUP和面向對象方法論 13\o"CurrentDocument"1.3中小型IT企業的研發管理需求和解決方案 14\o"CurrentDocument"1.3.1研發管理需求 1.4..1.5 1.3.2研發管理解決方案.1.5 \o"CurrentDocument"1.4集成化研發管理方法論（SPP）介紹 1.7.\o"CurrentDocument"SPP的概念和模型 17SPP的特征和優點 191.5集成化項目管理系統（FUTURE1.5集成化項目管理系統（FUTURE）介紹1.9 1.5.1Future3.的1功能介紹 1.9 Future系統的特征和優點Future系統的特征和優點.2.0 1.5.3Future系統自身的開發和管理流程1.5.3Future系統自身的開發和管理流程.2.2 ?2 第1章IT企業研發管理綜述 大部分IT企業從事產品開發或者合同項目開發，有開發就要有管理，管理是為開發服務的。IT企業的開發過程通常指“需求開發、軟件硬件設計、軟件硬件實現、測試、發布、維護”。項目管理涵蓋的過程域有“組織結構和人力資源管理、立項與結項、項目規劃與監控、需求開發與管理、變更管理、軟件質量管理、軟件配置管理、日常工作和領導綜合管理等”。本章首先闡述企業研發管理的一些理念，中心思想是“圍繞企業利益最大化這個根本目標開展研發和管理工作”。接著介紹常見的研發管理方法論：產品生命周期管理、ISO9000族質量體系、軟件過程改進與CMM/CMMI、項目管理與PMBOK、敏捷軟件開發方法、RUP和面向對象方法論，并進行優缺點分析。之后，本章分析了國內中小型IT企業的研發管理需求，闡述作者創作的研發管理解決方案，核心成果是集成化研發管理方法論（SPP）和集成化項目管理系統（Future）。本章是全書的綜述文章，給出了提綱挈領的觀點和論斷，有益于讀者拓寬視野，取長補短。本書后面的章節將細致地解答IT企業項目管理的常見問題，闡述行之有效的方法和工具。讀者掌握后馬上就可以在企業中應用。1.1企業研發管理的一些理念企業的根本目標是“合法地賺取盡可能多的利潤，使企業利益最大化”。企業所有的特定目標和行動（例如研發和管理等）都是圍繞根本目標開展的，不能和根本目標抵觸。企業研發管理的指導思想是：結果導向，并且關注過程。“結果導向”是指：以最終產生的經濟效益來衡量研發項目的業績，追求利益最大化。“關注過程”是指：將期望的結果分解到每個過程域（即工作環節）去實現，努力把每項工作做好，從而得到好的結果。一般地，好的過程才可能得到好的產品，而差的過程只會得到差的產品。衡量工作優劣的三個關鍵指標是：質量、時間和成本。人們在工作的時候總是希望：做得好（即質量高）、做得快（即時間少）而且少化錢（即成本低）。如果出現三者難以同時兼得的情況，那么決策者一定要搞清楚質量、時間、成本之間的復雜關系，判斷孰重孰輕，給出優化和折中的措施。綜上所述，我們可以總結企業研發管理的目標：基本目標：讓所有人員有條不紊地開展工作，在預定的時間和成本之內，開發完成質量合格的產品，從而使企業和個人獲得預定的利益。奮斗目標：調動一切積極因素，努力提高產品質量、提高工作效率并且降低成本，使企業和個人獲得比預定目標更多的利益。在IT企業中，研發項目所涉及的主要過程域有:項目管理過程域：立項管理，結項管理，項目規劃、項目監控、配置管理、變更管理等；項目研發過程域:需求開發與管理、軟件硬件設計、軟件硬件實現、軟件硬件測試等、發布與驗收等；機構支持過程域:質量保證、客戶服務等；上述過程域中的任何活動都會影響研發項目的質量、時間和成本。人們顯然難以一股腦地把所有的事情做好。在企業里，大部分工作是成熟的，有成功的模式可以套用，應當走規范化路線；而另外小部分工作可能是獨特的，并不適宜套用規范（也可能沒有規范可以套用），那么應當采用超越規范化的管理方式。一般地，企業既需要大量的規范化管理方式，又需要小量的超越規范化的管理方式。通常前者約占80%，而后者約占20%（這里80－20僅僅是建議比例）。國內大部分IT企業的研發管理現狀是:規范化管理太少，非規范化的管理太多，到處都是土匪游擊隊的運作方式。阻礙國內IT企業發展的瓶頸問題通常不是技術問題，而是雜亂無章的管理。國內IT企業喜歡標榜自己是“高科技企業”，在開發高科技產品的同時，自己內部的管理卻非常落后。真是“鞋匠的兒子沒鞋穿”，這是對IT企業的莫大諷刺。本書倡導的研發管理思想是:以追求商業利益最大化為總目標，將提高質量、提高效率、降低成本的方法（經驗）融入到所有過程域中，形成適合于本企業的研發管理規范；開發和部署與規范配套的管理工具，從而有效地幫助企業依據規范開展研發管理工作。1.2常見方法論介紹和優缺點分析1.2.1覆蓋產品生命周期的研發管理體系早在1986年，美國PRTM公司創作了PACE（ProductAndCycle-timeExcellence,產品及周期優化法）方法論。PACE關注的要素有：正確決策項目小組構成開發活動的結構開發工具與技術產品戰略技術管理資源管理PACE算得上是產品生命周期和流程管理領域的方法論鼻祖。PACE誕生之后，很多企業和學術機構不斷地提出了適合于本行業的研發管理方法論，概念和術語“之多、之大”令人眼花繚亂、茫然失措。20世紀90年代初，IBM公司遭受了巨大的經營挫折，年虧損額高達近 80億美元。為了擺脫經營困境，IBM實施了以系統性研發管理解決方案為核心的企業再造方案。 IBM引進了PACE方法論，并獲得了巨大的成功。從1993年到1998年總共節省了120億美元的費用，產品平均開發周期4年下降到16個月。在PACE的基礎上，IBM總結了一套行之有效的產品開發模式，稱之為 IPD（IntegratedProductDevelopment，集成產品開發）。IBM不僅內部使用IPD，而且還把IPD方案賣給別的企業賺大錢。1999年，華為公司成為國內第一家引入PACE和IPD的大型企業，據說花費上億元人民幣，方案供應商自然是IBM。華為公司在推廣IPD過程中遭遇重重困難，付出了高昂代價，最終評價是成功的。目前華為已經是國內最大的電信設備供應商，也可以說是國內最大、最好的高科技企業。在企業流程改進領域，華為創作了一句廣為流傳的名言：“先僵化，再優化，后固化”。相似地，上海貝爾阿爾卡特為了建立適合自身發展需求的研發管理體系（類似于IPD），從2002年開始引入PACE方法論，公司在研發管理體系的投入累計達數千萬元人民幣。本人是該項目的ProcessLeader。我和組員們最初接觸PACE的時候，覺得神秘高深，很是昂慕。我們和PRTM公司的咨詢師相處了3個多月，最大的工作成果是制訂了“新產品開發流程”，如圖1-1所示。有一天，我凝視著那幅花費了一百多萬元經費而產生的流程圖，突然發現：所有的流程細節都是我們自己制訂的，咨詢師僅僅告訴我們幾個先進的概念和術語而已，并沒有給予任何超出我意料的革新，竟然賺了很多錢。之后一年，我親身感受到，所謂國際先進的研發管理方案，實際上效率低下、浪費很大。于是我和合作伙伴創作了面向國內中小型 IT企業的研發管理方法論（SPP）和工具（Future），并于2004年創業。由于有前車之鑒，我們不做華而不實的事情，我們的價值觀是“為客戶創造的利益必須高于客戶付出的成本”。由于有親身經歷，我對PACE和IPD方案作個簡要的評論，以便讀者辨析：PACE和IPD方案適合于指導大型企業的研發管理流程改進，由于涉及面很廣，實施過程中會遭遇重重困難，可能導致半途而廢；投入經費巨大，見效時間比較長，企業可能挺不住；如果成功，則有巨大的長期收益，但是失敗的可能性比成功的可能性高得多。如華為和上海貝爾阿爾卡特之類的研發管理體系，根本不適合于國內中小型IT企業，因為嘗試不起、承擔不起。

DR2DR3LiLts?juroingbfena ertDR6二gwlodulmpcud口瞿0.Pr^DR01.OpportiiiiityDefinitioiiII.Planniig0.1IntiKBusinessiCase1.1ConceptDescription&BusinessCase2.1IrtHiTBtAdProject-SFrcdudPlanning~f =iIII.D總DR2DR3LiLts?juroingbfena ertDR6二gwlodulmpcud口瞿0.Pr^DR01.OpportiiiiityDefinitioiiII.Planniig0.1IntiKBusinessiCase1.1ConceptDescription&BusinessCase2.1IrtHiTBtAdProject-SFrcdudPlanning~f =iIII.D總velopnientIV.Valklatioii3.1Lt-danIPPP5.1ProducthjtainterariLH!Planning3.2Prudjdh右rketLainch

Prepareionth.iferiHHtPnomation2.3Product

RnqijraTiert

Defiriition3.4SystemDesign 3.5Ftardi.i.iareDeveloprrent3.6Software：Development3.7IrpdustrslDeveloFrrerit4.4ProdjdCertificdionbyGowEfTiTiHrt3.9h.itanijfajti-ririgPrecess匸leuieh耳仃imrt2.4h.i^erBl&ComponertFhK：uraTiHrtandSoirchg6.1Prc-djii

fiitainteranis&圖1-1根據PACE方法論制訂的新產品開發流程ISO9000族質量管理體系國際標準化組織（ISO）為了滿足國際經濟交往中質量保證活動的需要，在總結各國質量保證制度經驗的基礎上，經過近十年的工作，于 1987年發布了ISO9000質量管理和質量保證標準系列。1994年進行了第一次修訂，形成了ISO9000族標準。2000年再進行了重大修訂，發布了ISO9000新標準（2000版）。ISO9000族標準問世至今，已經被全世界幾乎所有行業廣泛采納。人們到商店買東西，隨處可見“本產品通過ISO9000質量認證”的標記。“產品通過ISO9000質量認證”幾乎成為上市銷售的必要條件。盡管ISO9000族標準已經在各行各業普及，功勞莫大。但是人們在實踐中發現ISO9000族標準對低技術的生產企業幫助很大，但是對以研發為主的IT企業的幫助比較弱。主要原因如下：（1）ISO9000稱得上是放之四海皆準的標準，但是適用面越廣意味著專業性越弱。一個生產瓜子的小工廠和生成軟件硬件系統的企業，都可以采用ISO9000族質量標準。顯然前者的成功經驗不能套用到后者上。ISO9000標準不可能對“軟件、嵌入式系統、集成電路”等領域的質量問題有深入的論述，所以它對IT企業的質量管理缺乏專業性的指導，其專業程度遠遠不及CMM/CMMI。（2）基于ISO9000的質量保證活動，其關注的焦點是“輸入、輸出”是否符合既定的流程。對于低技術的企業而言，如果“輸入、輸出”都符合既定的流程，那么基本可以斷定產品的質量不錯。然而對于高科技企業而言，“輸入、輸出”都符合既定的流程并不意味著能夠生產出高品質的產品，因為研發水平對產品質量的影響更大。對于“軟件、嵌入式系統、集成電路”這類以智力創作為核心的產品而言，ISO9000質量標準的指導價值不高。我對“軟件、嵌入式系統、集成電路”此類研發企業的建議是，學習和應用ISO9000質量標準是有意義的，但是不必費時、花錢去搞ISO9000認證（除非公司策略需要），因為業內人士并不看重ISO9000認證。CMM/CMMI1986年11月，美國聯邦政府委托卡內基梅隆大學（Carnegie-Mellon）軟件工程研究所（SEI）開發一套用于評估軟件承包商能力的方法。SEI于1987年9月發布了一套軟件過程成熟度框架和一套成熟度問卷。1991年，SEI將軟件過程成熟度框架發展成為軟件能力成熟度模型（CapacityMaturityModelCMM），誕生了CMM1.0o1993年，SEI推出了CMM1.1，這是目前世界上應用最廣泛的CMM版本。十幾年來，CMM的改進工作一直不斷地進行。美國國防部希望把現在所有的、以及將被開發出來的各種能力成熟度模型，集成到一個框架中去。到2000年,CMM演化成為CMMI（CapabilityMaturityModelIntegrat能力成熟度模型集成）。CMMI不僅適合軟件，而且適合于軟件硬件結合的系統，這是對CMM最大的改進。從20世紀90年代至今，軟件過程改進成為軟件工程學科的一個主流研究方向，其中CMM和CMMI是該領域舉世矚目的重大成果。CMM/CMMI 是世界范圍內用于衡量軟件（硬件）過程能力的事實上的標準，同時也是軟件（硬件）過程改進最權威的指南。CMM將能力成熟度分為5個級別，這5個成熟度等級為評價機構軟件過程能力提供了一個有序的級別，如圖1-2所示。同時也為機構的軟件過程改進工作指明了方向，讓人們分清輕重緩急，指導人們一步一步地改進過程能力而不是企圖跳躍式地前進。L2可重復級有紀律的過程L1初始級圖1-2CMM的5個能力成熟度等級人們往往搞不清楚CMM和軟件過程改進的關系，將二者混為一談。下面作個比喻來解釋：把“軟件過程改進”比喻為“學英語，提高英語能力那么CMM就好比是“英語等級評估標準(考試大綱)”。一般情況下，英語等級考試的成績反映了英語能力。但是，在特別擅長應試的中國，英語考試成績很好并不見得英語能力很好，甚至可能差到“啞巴英語”的程度。這種“特性”傳染到軟件領域，不少企業雖然通過了高級別的CMM等級評估，但是其實際能力卻非常低下。軟件過程改進的真正目的是提高機構的軟件過程能力，而不是為了達到CMM高等級。“汝果欲寫詩，功夫在詩外”，這是很好的啟示。2000年至2003年，我在上海貝爾有限公司負責CMM/CMMI的研究和推廣工作，公司的每個事業部都有軟件(硬件)過程改進人員。公司在CMM/CMMI過程改進方面的投入巨大，取得一些成效，但是沒有達到我的期望值。感慨很多，一言難盡。此處，我對CMM/CMMI過程改進做個簡要的評論，供同行企業參考。—、CMM等級評估：從狂熱回歸理性2000-2003年是國內IT企業搞CMM等級評估最狂熱的時期，主要原因有：2000年，CMM剛剛在國內興起，感興趣(學習、研究)的人非常多。近幾年國內出版了不少關于CMM、軟件過程改進的書籍，相關論壇、會議也比較多。有良好的群眾基礎。那個時候ISO9000認證已經被國人搞臭了，而當時國內CMM等級評估還很少見，企業達到CMM2級、3級是很榮耀的事情。物以稀為貴，人們把認證的目光從ISO9000轉向了CMM。為了扶持當地軟件企業，鼓勵軟件出口，各地方政府相繼出臺了“資助企業搞CMM等級評估的政策”。最先搞CMM評估的企業嘗到了甜頭，自己拿到了比較吃香的CMM等級證書，昂貴的評估費用大多由政府支付了。這—劑催化劑，進—步激發了企業搞CMM評估的熱情。2000-2003年期間，國內有數百家企業通過了CMM2級、3級評估，大部分企業搞CMM評估是“為了拿證書”而不是“真正提高軟件過程能力”。到2004年，國內CMM評估從狂熱回歸理性。主要原因有：地方政府基本上不再資助企業搞CMM等級評估了。企業自己掏錢搞CMM評估就舍不得了，要掂量是否值得(理性的表現)。由于國內通過CMM2級、3級評估的企業已經很多，而且評估時“放水”現象嚴重，CMM評估的聲譽已經大不如2000年。最讓人失望的是，雖然有些企業通過了CMM2級、3級評估，但是實際的軟件過程能力卻依然底下。有些企業實施CMM后，質量沒有明顯提高，進度更落后了，成本增加了，人員更累了。現在軟件業界普遍關注的是：企業如何以比較低的代價有效地提高軟件過程能力。CMM等級評估則退居次要地位。二、CMM的盲區和常見應用問題用CMM指導企業的軟件過程改進工作是相當不錯的，但是企業要做的重要事情顯然不僅是軟件過程改進。企業最關注的是生存和發展問題，一切離不開賺錢。CMM本身不談如何賺錢的問題。它假設了美好的前提條件，即企業有充足的人員、資金、時間從事軟件過程改進，當軟件過程能力提高了，那么產品的質量、生產率自然上去了（同時成本也下降了），企業自然能夠獲取更多的利潤。軟件過程改進對企業經濟效益的貢獻是間接的，從投入到產出，時間相對比較長。遺憾的是，國內大部分企業沒有能力提供那么好的前提條件，企業最缺乏的資源往往就是人員、資金和時間，企業領導當然想把資源用在“刀刃”上，即賺錢最多最快的地方。當軟件過程改進和其它直接賺錢的事情“發生資源沖突”時，只好“拆東墻，補西墻”，往往減少軟件過程改進的資源。如果完全按照CMM的要求遍歷“18個關鍵過程域和百余個關鍵實踐”的話，無疑會占用大量的資源，資源沖突在所難免，失敗的風險很高。所以切勿照搬CMM，一定要根據企業的實際情況（企業發展戰略、產品特征、資源狀況）給出軟件過程改進的措施。CMM對軟件項目管理和機構過程管理論述很深入，但是對軟件開發的核心工作即“需求開發、軟件設計、編程、測試、維護”論述非常少，CMM把它們壓縮為一個過程域叫做“產品工程”（ProductEngineerin）近乎一筆帶過。所以導致一個怪現象，管理人員覺得CMM真是好，而大量開發人員學了CMM后卻很是迷惘，感覺CMM對他們的開發工作沒有直接的指導。CMM方法論有個明顯的傾向，即“管理的規范化”重于“開發的規范化”。CMM2級的6個關鍵過程域全部是論述項目管理的，而唯一論述“需求開發、軟件設計、編程、測試、維護”的“產品工程”關鍵過程域則放在CMM3級。對于國內大多數軟件項目而言，技術開發占總工作量的80％以上，而項目管理占總工作量的20％以下，因為企業銷售的是軟件產品，而不是管理。明眼人都看得出，技術開發的規范化要比項目管理的規范化尤為重要與迫切（至少也是同等吧）。由于CMM強調過程改進要循序漸進，不要跳躍式前進。人們自然而然地會先把精力集中在CMM2級的6個關鍵過程域上，而忽視了技術開發的規范化，這顯然是誤導。如果這樣做的企業通過了CMM2級評估，然后聲稱他們能夠把產品做得又快又好，無疑是自欺欺人。三、對應用CMM/CMMI的建議在軟件過程能力比較低的企業里，經常會發生項目開發過程混亂、產品質量低下、進度延誤、成本高昂等問題。一批人馬累死累活地做完產品后，馬上又因質量問題被折騰得焦頭爛額。這種現象反反復復地發生，讓人疲憊不堪。有遠見的企業領導應當下決心去改進軟件過程能力。提高軟件過程能力實際上就是“練內功”，“練內功”沒有捷徑可走，唯有走“規范化”之路。即：制定適合于本企業的軟件過程規范，并按照此規范執行。CMM是衡量企業軟件過程能力的國際標準，它對軟件過程改進有很多有益的指導。CMM僅僅對等級評估做了強制要求，但是對企業“如何進行軟件過程改進”沒有強制要求，CMM的數百頁文本并不是“放之四海皆準”的，企業可以采納也可以不采納。對于軟件過程改進而言，CMM/CMMI和ISO等等都是用來參考的，而不是用來迷信的。企業在參考業界推薦的標準或規范時，要舍棄那些聽起來很先進但是對本企業無益處的東西，只選取對企業有實用價值的東西。1.2.4項目管理知識體系（PMBOK）項目管理協會（ProjectManagementInstitutiorPMI）于1966年在美國賓州成立，是目前全球影響最大的項目管理專業機構，該機構的項目管理專家認證（ProjectManagementProfessionalPMP）被廣泛認同。PMI的突出貢獻是總結了一套項目管理知識體系（ProjectManagementBodyOfKnowledge，PMBOK）。PMBOK總結了項目管理實踐中成熟的理論、方法、工具和技術，也包括一些富有創造性的新知識。PMBOK把項目管理知識劃分為9個知識領域：綜合管理、范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、風險管理和采購管理。每個知識領域包括數量不等的項目管理過程。PMBOK把項目管理過程分為5個階段：（1） 啟動。開始項目或進入項目的新階段。啟動是一種認可過程，用來正式認可一個新項目或新階段的存在。（2） 計劃。定義和評估項目目標，選擇實現項目目標的最佳策略，制定項目計劃。（3） 執行。調動資源，執行項目計劃。（4） 控制。監控和評估項目偏差，必要時采取糾正行動，保證項目計劃的執行，實現項目目標。（5） 結束。正式驗收項目或階段，使其按程序結束。每個管理過程包括輸入、輸出、所需工具和技術。各個過程通過各自的輸入和輸出相互聯系，構成整個項目管理活動。根據重要程度，PMBOK又把項目管理過程分為核心過程和輔助過程兩類。核心過程指那些大多數項目都必須具有的項目管理過程，這些過程具有明顯的依賴性，在項目中的執行順序也基本相同。輔助過程指那些視項目實際情況可取舍的項目管理過程。在PMBOK2000中，核心過程共17個，輔助過程共22個。PMBOK2000一共有39個項目管理過程，按所屬知識領域分為9類，按時間邏輯分為五類，按重要程度分為兩類。如表1-1所示，其中斜體為輔助過程。表1-1PMBOK項目管理過程一覽表啟動計劃執行控制結束綜合管理項目計劃編制項目計劃執行綜合變更控制

范圍管理啟動范圍規劃范圍定義范圍審核范圍變更控制時間管理活動定義活動排序活動周期估計講度安排進度控制成本管理資源計劃成本估計成本預算成本控制質量管理質量計劃質量保證質量控制人力資源管理組織計劃人員獲取團隊建設溝通管理溝通計劃信息分發績效報告行政收尾風險管理風險管理計劃風險識別定性風險分析定量風險分析風險響應計劃風險監控采購管理采購計劃招標計劃招標選擇供應商合同管理合同收尾PMBOK和CMM/CMMI對比簡評：CMM/CMMI論述的項目管理方法僅僅適用于軟件項目，但是不適用于其它行業的項目管理。PMBOK論述的方法適用于任何行業的項目管理，但是對軟件項目管理而言，PMBOK的針對性不夠強。CMM/CMMI不僅論述軟件項目管理，而且論述整個機構的軟件研發管理。PMBOK的方法局限于項目管理，對于企業研發管理則不夠用。CMM/CMMI基本上不談“成本管理”和“人力資源管理，”它先假設機構有充足的資金和人力資源，通常不切合企業實際情況。因此PMBOK的“成本管理”和“人力資源管理”可以彌木CMM/CMMI 的不足。建議：對于軟件機構研發管理或者軟件項目管理，采用CMM/CMMI為主導的方法論，并結合PMBOK的知識，取長補短。1.2.5敏捷開發思想2001年，為了解決許多公司的軟件團隊陷入不斷擴大的過程泥潭，一批業界專家概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟（AgileAllianc）e。他們起草了一個旨在鼓勵更好的軟件開發方法的宣言，稱為敏捷聯盟宣言（TheManifestooftheAgileAllianC目表1-2所示。然后在該宣言基礎上制定了12條原則用于指導實踐。該宣言和12條原則是敏捷軟件開發方法的核心。表1-2敏捷軟件開發宣言我們正在通過親身實踐和幫助他人實踐，揭示了更好的軟件開發方法。我們認為：個體和交互勝過過程和工具可以工作的軟件勝過詳盡的文檔與客戶合作勝過合同談判及時響應變化勝過遵循計劃雖然右項很有價值，但是我們認為左項有更大的價值。KentBeckJamesGrenningRobertC.MartinMikeBeedleJimHighsmithSteveMellorArievanBennekumAndrewHuntKenSchwaberAlistairCockburnRonJeffriesJeffSutherlandWardCunninghamJonKernDaveThomasMartinFowlerBrianMarick敏捷軟件開發的12條原則如下：（1） 我們最優先要做的是通過盡早地、持續地交付有價值的軟件來使客戶滿意。（2） 即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。（3） 經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。（4） 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。（5） 圍繞被激勵起來的個人來構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。■12 第1章IT企業研發管理綜述 （6） 在團隊內部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。（7） 可以工作的軟件是首要的進度度量標準。（8） 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。（9） 不斷地關注優秀的技能和好的設計會增強敏捷能力。（10） 簡單——把無需做的工作最大化的藝術——是最根本的。（11） 最好的構架、需求和設計出于自我組織的團隊。（12） 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。人們在敏捷軟件開發宣言和12項原則的指導下，創作了更多的富有特色的開發方法和最佳實踐。例如“敏捷的面向對象設計"，請參考AgileSoftwareDevolopment:Principle,Patterns,andPractices,RobertC.Marg，中譯本為《敏捷軟件開發：原則、模式與實際》。例如“敏捷建模"，請參考AgileModeling:EffectivePracticesforextremeProgrammingandtheUnifiedProcess,ScottW.Amgr中譯本為《敏捷建模：極限編程和統一過程的有效實踐》。本文作者的觀點如下：敏捷軟件開發宣言和12條原則并非普遍適用。我大約贊同60％，我和軟件人員交流的時候，有時會引用其中的原則，感慨甚多，忍不住拍案叫好。但是約有40%的內容我并不認同，主要原因是“過于理想化、絕對化，不適合國情”。我認為“宣言”中的左右4項都很重要，但是不能絕對地說左邊4項“勝于”右邊4項，這是“一刀切”的結論，沒有考慮成千上萬企業的具體情況。上述12項原則中的（2）、（4）、（5）項，看似很好，但是不符合中國軟件機構的普遍現狀，實際上可能行不通。我個人比較贊同的是（1）、（3）、（6）、（7）、（12）項。敏捷開發方法表達了“簡單、快速、實用”的軟件開發思想，它不是成熟的理論、也不是事實上的標準（不像CMM、PMB0K那樣具有嚴密的理論體系，被企業廣泛接受）。即使人們認同某些原則，但是不同的人往往有不同的理解，實踐差異很大。敏捷開發方法對于提高個人、小型團隊的工作效率是很有幫助的（如果用對了的話）。但是企圖用它指導大型、中型軟件機構的研發管理是有很高風險的，它的某些主張是局部觀點而不是全局觀點，如果把握不好分寸的話可能導致整體混亂，而“整體的混亂”會淹沒“局部的好處”。作者研制的“精簡并行過程（SPP）”的理論基礎是“經典軟件工程、CMM、PMB0K”。為了提高效率，局部借鑒了“敏捷軟件開發的思想”，用于裁減過于冗長、笨重的過程規范。1.2.6RUP和面向對象方法論RUP（RationalUnifiedProcesS是Rationa公司推出的軟件過程模型，它是軟件業界迄今為止商品化最成功的軟件過程模型。RUP的近千頁文檔可以從Rational公司的網站（http://www.ration3l下載，RUP2000中文版也已經發布。RUP的主要特征是：采用迭代的、增量式的開發過程，如圖1-3所示。采用UML語言描述軟件開發過程。有一系列功能強大的軟件工具支撐（Rational公司的軟件產品）。UML是三位面向對象大師Jacobson、Booch、Rumbaugh創作的面向對象建模語言，1997年UML被國際對象管理組織（0MG）采納為國際標準。UML是獨立于過程的，可以應用于任何開發過程模型。由于UML和RUP都是Rational公司的研究成果，兩者有天然的聯系。RUP的文檔里面充滿了UML模型，需求建模、分析與設計、實現、測試等階段的角色的主要工作都是用UML來描述的。與RUP配套的軟件工具相當完備，例如面向對象分析設計工具Rose，配置管理工具ClearCase，變更控制工具ClearQuest，需求管理工具ReQuisitePrc，文檔生成工具SoDA，測試工具Purify還有TeamTest/TestStudidL具等。2003年，IBM斥資10億美元收購了Rational公司。現在國內軟件開發人員學習UML、使用盜版Rose的勁頭很足，相關書籍和網站也越來越多，造成了一派紅火的景象。但是完整采用RUP的國內企業則非常少。?14 第1章IT企業研發管理綜述 圖1-3RUP模型RUP及其配套軟件工具是重量級的軟件研發管理解決方案，它面向的是高端用戶，對用戶的財力、開發和管理能力要求都很高：首先，用戶得有錢買Rationa的軟件工具，否則光有RUP方法論如同紙上談兵。Rationa1的軟件工具都是非常昂貴的，例如配置管理工具幾乎是每個項目成員都要使用的，但ClearCase的每個License大約5000美元，這個費用相當于中國普通程序員一年的工資收入！顯然，大部分國內企業沒有錢購買Rationa公司的軟件工具。如果要使用RUP方法，得先熟悉UML，否則除了RUP模型圖之外你基本上看不懂細節內容。可是在普通企業里，大部分人（尤其是領導和管理人員）不熟悉UML。學習UML和RUP的難度遠高于CMM和PMBOK。項目經理和開發組長要有能力控制迭代過程，否則迭代式開發就變得混亂無序和漫無邊際。可是國內很多項目經理連瀑布式開發過程都控制不住，他們又怎么能夠管理好迭代過程呢？使用RUP的風險是很高的。根據上述分析和許多同行的反饋，我們可以得出一個結論：RUP及其配套的軟件工具基本上不適合于國內中型和小型軟件機構。1.3中小型IT企業的研發管理需求和解決方案1.3.1研發管理需求IT產業目前是中國的第一大支柱創業。國內從事“軟件、軟硬件系統、集成電路”

開發的IT企業非常多，其中200人以下的中小型IT企業占絕大多數，估計在萬家以上。國內千人以上的大型IT企業雖然實力不錯，但是數量太少（估計只有百余家），不具有典型性。大量的中小型IT企業是推動國內IT產業發展的主流力量，提升它們的研發管理能力是非常有意義的。國內50人至200人左右的中小型IT企業不小于千家，它們對研發管理有如下共性需求：必要性。如果企業只有數人或者十幾個人，即使沒有研發管理規范，能力強的領導一個人也能從容指揮。但是當企業超過數十人后，如果還沒有研發管理規范的話，那么企業領導將會力不從心。人數越多，非規范化管理越容易產生混亂，迫使企業不得不走規范化管理的路線，以降低管理代價和風險。經濟基礎。建立規范化的研發管理是需要一定的投資的，例如咨詢、培訓、購買工具等等。如果IT企業能夠養活50-200人，表明它們是有一定經濟實力的，只要投資額適當而且產生的效益高于投資，那么企業領導一般都愿意做這件事情。發展欲望。不少中小型IT企業的領導雄心勃勃，高瞻遠矚，他們迫切希望提高研發管理能力從而提升整個企業的核心競爭力，產生源源不斷的推動力，推動企業持續發展壯大。他們對研發管理的態度是主動的，而不是被動的。國內一些大型IT企業建立了完整的研發管理體系，投資巨大。例如上海貝爾、華為分別請HP、IBM建立研發管理體系，投資額分別達到數千萬元、上億元。這種投資額是中小型企業望塵莫及的。在研發管理方面，中小型企業無法效仿大型企業的做法。據我們調查分析，國內中小型IT企業對研發管理的投資額大約在數萬元至數十萬元。這點“小錢”根本無法引入IBM、HP、Rationa等公司的研發管理解決方案。國內大部分中小型IT企業需要的是“輕量級”的研發管理解決方案，包括咨詢、培訓、購買工具，總費用在5萬元至20萬元之間比較合適。粗略估計，按國內中小型IT企業總數的10％需求計算的話（約1000家），市場規模約為5000萬元至2億元。1.3.2研發管理解決方案作者創作的面向中小型IT企業的研發管理解決方案如圖1-4所示。該解決方案的目標是：通過深入的調查分析，建立適合于企業自身需求的研發管理規范，部署與企業研發管理規范配套的工具。通過充分的培訓，幫助員工掌握提高質量、提高生產率、降低成本的方法建立有效的執行、監控和考核制度，使員工們依據既定的規范和工具，開展相應的研發和管理工作。從而持續提升企業的研發和管理能力。1.調查分析問題r r2?制定研發管理規范1.廠( ]*方法論* ■*配套工具*SPP,CMMI等Future,Satisfy,Performance等圖1-4中小型IT企業研發管理解決方案的模型一般地，為了持續提升企業的研發管理能力，企業要做五項重要的工作：（1）調查分析問題（2） 制定研發管理規范（3） 部署配套的工具（4） 培訓和輔導（5） 執行與改進為了有效實現上述五項工作，需要方法論和配套的工具來支持。我們自主研制的方法論和工具有：（1） 集成化研發項目管理方法論（SPP）；（2） 集成化項目管理系統（Future）；（3） 客戶服務管理系統（Satisf）y；（4） 人力資源管理系統（Performance）。方法論SPP用于指導企業開展軟件（硬件）開發、項目管理、客戶服務、人力資源管理等活動。三個管理系統Future、SatisfyPerformance采用統一的技術平臺，可以無縫集成。方法論和工具之間的關系如圖1-5所示。1.4集成化研發管理方法論（SPP）介紹1.4.1SPP的概念和模型SPP是基于“CMMI、軟件工程和項目管理”知識創作了集成化研發管理方法論，稱為“精簡并行過程”（SimplifiedParallelProc^ssSPP由眾多的過程規范和模板組成。精簡并行的含義是：對CMMI3級以內各過程域的內容和要求作了“精簡”處理。在產品生命周期內，項目管理過程、項目研發過程和機構支持過程“并行”開展。SPP的模型如圖1-6所示，分三類過程：項目管理過程，項目研發過程，機構支持過程。共13個過程域。圖1-6SPP的模型項目管理過程包含4個過程域：立項管理結項管理項目規劃與監控變更管理項目研發過程包含7個過程域：需求開發與管理軟件硬件設計軟件硬件實現測試與改錯發布與試用客戶驗收（合同項目有客戶驗收，非合同項目無客戶驗收）配置管理機構支持過程包含2個過程域：質量管理客戶服務與產品維護SPP的特征和優點一、 清晰直觀的過程模型產品生命周期和項目管理過程、項目研發過程、機構支持過程的結構清晰，相互關系直觀明了。根據SPP模型，機構領導、項目經理、項目成員（開發人員、測試人員等）很容易知道自己“應該在什么時候、按照什么規范做什么事情”。SPP模型有助于使企業內部的各個職能單位有條不紊地開展工作。二、 融合了CMMI、項目管理與軟件工程知識SPP吸納了CMMI3級以內的大部分關鍵過程域，補充“立項管理”和“結項管理”兩個過程域（CMM不涉及立項與結項），使研發管理有始有終。SPP細化了項目研發過程的規范（這是CMMI的薄弱環節），如“需求開發與管理”、“軟件硬件設計”、“軟件硬件實現”、“測試與改錯”、“發布與試用”、“服務與維護”等過程域，更加適合于項目研發團隊。三、 容易裁剪與擴充SPP模型的三類過程貫穿了產品的整個生命周期，13個最常見的過程域都合理地安排在產品生命周期中的某些階段。用戶可以根據本企業的特征，適當地裁剪或擴充SPP的過程域，很容易制定出最適合于本企業的過程模型。1.5集成化項目管理系統（Future）介紹1.5.1Future3.的1功能介紹Future是基于Web的集成化研發項目管理系統，目標是“讓項目管理變得簡單有效”。Future3.1的功能結構如圖1-7所示。Future的主要客戶是國