軟件研發(fā)管理問題和解決方案課件

軟件研發(fā)管理問題和解決方案常見問題分析基礎方法論介紹整體解決方案林銳博士軟件研發(fā)管理問題和解決方案林銳博士目錄1.企業(yè)研發(fā)管理的理念2.常見問題分析3.中型企業(yè)的研發(fā)管理需求4.基礎方法論介紹－CMM5.基礎方法論介紹－PMBOK6.基礎方法論介紹－敏捷開發(fā)7.基礎方法論介紹－RUP8.面向企業(yè)的軟件研發(fā)管理解決方案9.基于Web的集成化項目管理系統(tǒng)Future3.0目錄1.企業(yè)研發(fā)管理的理念1.企業(yè)研發(fā)管理的理念1.1目標企業(yè)的根本目標是“合法地賺取盡可能多的利潤，使企業(yè)利益最大化”。企業(yè)所有的特定目標和行動都是圍繞根本目標開展的。根本目標進一步?jīng)Q定了企業(yè)研發(fā)管理的目標和策略。企業(yè)研發(fā)管理的基本目標是：讓所有人員有條不紊地開展工作，在預定的時間和成本之內(nèi)，開發(fā)完成質(zhì)量合格的產(chǎn)品，從而使企業(yè)和個人獲得預定的利益。企業(yè)研發(fā)管理的奮斗目標是：調(diào)動一切積極因素，努力提高產(chǎn)品質(zhì)量、提高工作效率并且降低成本，使企業(yè)和個人獲得比預定目標更多的利益。1.2質(zhì)量、進度（時間）、成本“質(zhì)量、進度（時間）、成本”通常是衡量企業(yè)研發(fā)管理“優(yōu)劣”的三個關鍵指標。不同的企業(yè)，甚至同一企業(yè)在不同時期，對三者的重要性看法是不一樣的。如果出現(xiàn)“三者難以同時兼得”的情況，那么產(chǎn)品的決策者一定要搞清楚質(zhì)量、進度（時間）、成本之間的復雜關系，判斷孰重孰輕，給出優(yōu)化和折衷的措施。

1.3規(guī)范化vs.超越規(guī)范化在企業(yè)里，大部分的工作是成熟的，有成功的模式可以套用，應當走規(guī)范化的路線；而另外小部分的工作可能是獨特的，并不適宜套用規(guī)范（也可能沒有規(guī)范可以套用），那么應當采用超越規(guī)范化的管理方式。通常前者約占80%，而后者約占20%

1.企業(yè)研發(fā)管理的理念1.1目標

2.1常見問題分析：立項管理2.1.1自主研發(fā)產(chǎn)品的立項問題擁有決策權的領導人獨自決定，或者招集有關人員開會商議是否開發(fā)某個產(chǎn)品。決策過程中的主觀臆斷比較多，風險很高。如果決策錯誤，即使人們努力開發(fā)出功能很好的產(chǎn)品，卻可能在商業(yè)上失敗。由于沒有進行充分必要的調(diào)研、可行性分析、立項建議、立項評審等工作，企業(yè)領導在組建開發(fā)團隊時難以給出恰當?shù)馁Y源和進度計劃。團隊只知道干活，卻不了解產(chǎn)品的開發(fā)背景，不清楚用戶期望的產(chǎn)品應該是什么樣的。在開發(fā)過程中經(jīng)常迷失方向，導致進度延誤、費用超支等問題。2.1.2合同項目的立項問題

委托方（客戶方）和承包方（開發(fā)方）在簽訂合同的時候，雙方對軟件需求的了解并不深入，合同中對“開發(fā)什么”的描述比較空洞。合同簽訂之后，客戶經(jīng)常變更需求，開發(fā)方被迫不斷修改軟件，弄得疲憊不堪?？鋸埖馗爬ǎ撼撕贤痤~不變，其它一切都可能改變。剛簽訂合同時開發(fā)方似乎賺錢了，后頭卻可能得不償失。雙方在簽訂合同的過程中給出了一些空頭承諾（例如對進度、質(zhì)量、費用的估計過于樂觀），在實際執(zhí)行時卻難以兌現(xiàn)這些承諾。處理不好將引發(fā)合同糾紛，輕則雙方提前終止合同，重則雙方反目成仇。2.1.3建議創(chuàng)建一種群體決策的立項管理規(guī)范，不僅讓群眾貢獻智慧，而且讓群眾分擔責任，使成功的經(jīng)驗被企業(yè)不斷復用，并升華成為企業(yè)的制度。

2.1常見問題分析：立項管理2.1.1自主研發(fā)產(chǎn)品的立項2.2常見問題分析：

結項管理2.2.1共性問題某些項目由于進度拖延，不能按計劃結項；某些項目即使開發(fā)完成了，由于利益關系也不愿結項。這些“不良”項目或者已經(jīng)完成的項目一直占用企業(yè)資源（如人力資源和設備），無疑違背企業(yè)利益最大化的目標。在結項時，人們往往對財務和設備進行了詳細的清算，卻忽視了對知識財富、經(jīng)驗教訓的總結。殊不知設備越用越差，但是知識財富越用越好，可謂主次顛倒。沒有對項目的價值進行評估，開發(fā)人員干完活后，不知道自己的工作成果產(chǎn)生多大的效益，缺乏成就感。結項后，不能對員工的業(yè)績進行公正考核，自然不能很好地激勵員工。合同軟件項目在結項之前，還面臨“客戶驗收”的一些問題。例如缺乏雙方認同的“驗收標準”，導致驗收過程混亂，過多地消耗雙方的精力。2.2.2建議首要措施是建立企業(yè)的“結項管理規(guī)范”和“驗收與發(fā)布”規(guī)范。自主研發(fā)的軟件產(chǎn)品在結項之前，公司內(nèi)部要進行類似的“驗收”，防止不良項目蒙混過關。2.2常見問題分析：結項管理2.2.1共性問題2.3常見問題分析：項目規(guī)劃2.3.1共性問題在項目剛開始階段，人們對產(chǎn)品需求和技術的了解還比較膚淺，項目不確定因素比較多，此時很難對工作量和進度作出比較準確的估算。軟件工程教科書和CMM推薦的COCOMO模型、代碼行估算方法等等，對大多數(shù)國內(nèi)項目無法適用，效果如同“電腦算命”。由此制定的項目計劃可能不切實際，后面經(jīng)常發(fā)生項目計劃的變更（所以業(yè)界流傳“計劃快不如變化快”），將導致項目管理的復雜性和風險提高。項目的人員已經(jīng)被上級領導限定死了，再多的活也是那幾個人干；項目的結束日期早就被領導和客戶指定了，不管合理不合理，反正時間一到就要交付軟件；除了辦公計算機和工資外，這個項目沒有其它經(jīng)費，項目經(jīng)理只有干活的權利沒有用錢的權利。如果人員、資金、時間都已經(jīng)被毫無道理地指定了，那么項目規(guī)劃就失去意義，這樣的項目在國內(nèi)非常普遍。

2.3.2建議建立企業(yè)的“項目規(guī)劃規(guī)范”，給出合適的項目估算方法和項目計劃模板。使用方便的軟件工具，幫助項目經(jīng)理進行項目規(guī)劃。2.3常見問題分析：項目規(guī)劃2.3.1共性問題2.4常見問題分析：項目監(jiān)控2.4.1共性問題許多項目經(jīng)理肩負重要的軟件開發(fā)工作，他們往往把注意力集中在開發(fā)上面，很少認真考慮如何進行項目監(jiān)控。沒有突出項目監(jiān)控的重點，項目經(jīng)理要么什么都不監(jiān)控（導致項目失控），要么監(jiān)控得太多而陷入瑣碎事務中。項目經(jīng)理寫周期性項目進展報告時，記流水帳，或者復制上次的報告，應付了事。懶得動腦筋分析項目遇到的一些問題，例如某些任務的進度延誤了，不分析為什么延誤了，就順延。導致問題越積越多。項目實際執(zhí)行情況與原定的項目計劃嚴重脫節(jié)，領導、客戶、市場人員、開發(fā)團隊不了解項目真正的狀況，使項目計劃行同虛設。2.4.2建議建立企業(yè)的“項目監(jiān)控規(guī)范”，使用方便的軟件工具，幫助項目經(jīng)理進行項目監(jiān)控。上級領導和相關人員每周都要檢查項目的監(jiān)控要素，及時發(fā)現(xiàn)問題，及時解決問題，既要關心結果也要關心過程。

2.4常見問題分析：項目監(jiān)控2.4.1共性問題2.5常見問題分析：配置管理和變更管理2.5.1共性問題有些軟件機構竟然不使用軟件配置管理工具，用最原始的方式手工管理代碼和文檔，經(jīng)常出現(xiàn)“成果丟失、版本混亂”等問題。不少機構按照的CMM的要求制定了配置管理規(guī)范。該規(guī)范在理論上比較完善，面面俱到，但是實際操作比較麻煩，沒有突出重點。久而久之，人們厭煩后就逐漸放棄了規(guī)范，按自己的習慣操作，留下了隱患。例如不少程序被

checkout后長久沒有

checkin；有些程序保留在開發(fā)者本機，根本就沒有放入配置庫。維護期間修改了程序，但是沒有放入配置庫。沒有變更控制流程，經(jīng)常隨意變更需求、設計、代碼等，嚴重影響項目的正常開發(fā)進程。2.5.2建議建立簡單有效的“配置管理規(guī)范”和“變更管理規(guī)范”。并使用方便的工具，幫助團隊進行軟件配置管理和變更管理。2.5常見問題分析：配置管理和變更管理2.5.1共性問題2.6常見問題分析：質(zhì)量管理2.6.1共性問題雖然人們大都認可軟件的質(zhì)量很重要，但是許多軟件人員并不懂得如何有效地改善軟件質(zhì)量屬性如正確性、健壯性、可靠性、性能、易用性、安全性、可擴展性、可復用性、兼容性、可移植性等等。不會分析當前軟件的質(zhì)量要素是什么，沒有把精力集中在改善對經(jīng)濟效益貢獻最大的質(zhì)量要素上面。

有些軟件機構沒有軟件質(zhì)量管理的措施，開發(fā)人員把完成功能當成終極目標。用戶在使用軟件的過程中發(fā)現(xiàn)許多Bug，導致開發(fā)方的糾錯性維護代價很高。

有些軟件機構雖然很重視軟件質(zhì)量，按照ISO,CMM的要求建立了管理規(guī)范，但是效果不明顯。人們搞不清楚軟件測試、技術評審、質(zhì)量保證的作用和關系。不懂得內(nèi)建質(zhì)量，主要靠修補錯誤的方式提升質(zhì)量，代價比較高。

很多人誤以為提高軟件質(zhì)量是質(zhì)量保證人員和測試人員的責任，沒有意識到任何開發(fā)人員、管理人員都會對質(zhì)量產(chǎn)生影響，都要對質(zhì)量負責。另外，質(zhì)量保證人員的權力比較小，很難推動質(zhì)量改進措施。2.6.2建議讓人們理解“什么是軟件質(zhì)量”及常見的軟件質(zhì)量屬性，樹立全面軟件質(zhì)量管理的理念（模型），制定軟件測試、技術評審、質(zhì)量保證的規(guī)范。并使用方便的工具，幫助團隊進行軟件質(zhì)量管理。2.6常見問題分析：質(zhì)量管理2.6.1共性問題2.7常見問題分析：需求開發(fā)與管理2.7.1共性問題對于大部分軟件機構而言，需求開發(fā)與需求管理是問題最多、最難解決的過程域。軟件機構中，通曉需求調(diào)查、需求分析、需求定義、需求評審、需求跟蹤、需求變更控制的人員本來就比較少，也不容易招聘和培養(yǎng)這樣的人才。

用戶說不清楚需求、用戶經(jīng)常變更需求是普遍現(xiàn)象，令開發(fā)方非常頭痛。開發(fā)人員不善于寫文檔，很難寫出清楚、完整的軟件需求規(guī)格說明書。后續(xù)開發(fā)人員可能誤解需求，做出與需求不一致的設計、代碼、測試用例等等，最后不得不大量返工重做。最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”?？蛻魰氘斎坏匾詾樽兏枨笫撬臋嗬?，因為他付錢給開發(fā)方。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。2.7.2建議建立“需求開發(fā)與管理規(guī)范”，給出合適的文檔模板，采用方便的需求分析和管理工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。

制定應對需求變更的辦法，例如：(1)雙方簽訂需求變更管理協(xié)議;(2)將重大需求變更延緩到下個軟件版本中實現(xiàn);(3)讓客戶欠下人情。

2.7常見問題分析：需求開發(fā)與管理2.7.1共性問題2.8常見問題分析：軟件設計2.8.1共性問題對于大部分軟件機構而言，用戶界面設計是弱項。國內(nèi)絕大多數(shù)大學的計算機學科沒有開設人機工程學、美學、心理學這些必修課。由于學生們接受的教育幾乎全是科學與技術，他們根本不知道怎樣才能設計出易用、美觀的用戶界面，很多人甚至想都沒有想過。當他們畢業(yè)后真正參與軟件產(chǎn)品開發(fā)時，只好憑著個人的經(jīng)驗與感覺設計軟件的用戶界面，這樣產(chǎn)生的界面往往得不到大眾用戶的認可。

大部分軟件機構都有一些技術出色的軟件人員，他們在系統(tǒng)構架、數(shù)據(jù)庫方面的設計能力相當不錯。但是很多人不愿意、不善于寫系統(tǒng)設計報告，這不利于后續(xù)的軟件開發(fā)和維護。軟件設計應當“細到什么程度”很難把握。太粗了的話，對后續(xù)開發(fā)工作的指導價值不高；反之倘若太細的話，耗費時間就比較多，如果后面不斷改進設計的話，前面的設計浪費太多。2.8.2建議建立“軟件設計規(guī)范”，給出合適的文檔模板，采用方便的設計工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。

2.8常見問題分析：軟件設計2.8.1共性問題2.9常見問題分析：編程與調(diào)試2.9.1共性問題軟件機構的大部分程序員的技能是合格的，但是他們編寫的程序風格差異較大，代碼質(zhì)量有高有低。大多數(shù)軟件機構沒有編程規(guī)范，即使有的話，開發(fā)人員也沒有很好地按規(guī)范編程。相當多的程序員沒有養(yǎng)成對所有代碼進行“單步跟蹤調(diào)試”的習慣。嫌單元測試很麻煩，懶得執(zhí)行，卻沒有替代方案。2.9.2建議制定簡單明了、重點突出的“編程規(guī)范”，讓團隊遵照此規(guī)范編寫程序。采用集成化的開發(fā)調(diào)試工具，提高編程質(zhì)量和效率。2.9常見問題分析：編程與調(diào)試2.9.1共性問題2.10常見問題分析：軟件測試2.10.1共性問題許多軟件人員沒有系統(tǒng)地學習過軟件測試，搞不清楚各種測試的概念，例如單元測試、集成測試、驗收測試、黑盒測試、白盒測試、功能測試、性能測試等等，混為一談，不知如何下手。測試人員沒有掌握有效測試的方法，大多憑感覺測試，結果重復測試已經(jīng)測試過的，那些深藏的bug卻發(fā)現(xiàn)不了。客戶在使用軟件的過程中發(fā)現(xiàn)的bug比公司內(nèi)部測試時發(fā)現(xiàn)的還多，不僅改錯代價高，而且降低了客戶對產(chǎn)品的滿意度。團隊沒有采用有效的缺陷跟蹤工具。測試人員發(fā)現(xiàn)bug時，口頭告知有關人員或者記在Word、Excel文件中，修改bug信息或者測試報告時非常麻煩。難以及時從bug列表中找出規(guī)律，測試的效率比較低。2.9.2建議建立“軟件測試規(guī)范”，采用方便的測試管理工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。2.10常見問題分析：軟件測試2.10.1共性問題2.11常見問題分析：軟件維護2.11.1共性問題在維護期間，除了糾錯性維護外，客戶可能提出需求變更（但是不支付費用），維護人員對客戶妥協(xié)，導致維護工作量增大、成本增加。如果是合同軟件項目，用戶對開發(fā)方的依賴性比較大，不愿意自己解決粗淺的問題，經(jīng)常叫開發(fā)方“干這干那”。開發(fā)方不敢得罪客戶，導致開發(fā)方做了許多不屬于維護的工作，吃啞巴虧。開發(fā)人員一邊開發(fā)新項目，一邊維護老項目。而維護為體現(xiàn)不出業(yè)績，又影響了新項目的進度，開發(fā)人員比較心煩。2.11.2建議制定“軟件維護規(guī)范”，界定什么是“免費維護”、什么是“有償維護”，以及相應的操作規(guī)則，提高維護效率并且降低維護成本。

2.11常見問題分析：軟件維護2.11.1共性問題2.12常見問題分析：其它問題2.12.1技術vs.市場許多開發(fā)人員喜歡技術研究和技術挑戰(zhàn)。雖然嘴上說開發(fā)產(chǎn)品要以“客戶（市場）為中心”，但是在開發(fā)軟件的時候，卻不知不覺以技術為中心，例如喜歡采用新技術、追求技術上的完美。導致進度延誤，成本增加，甚至可能有質(zhì)量風險。他們開發(fā)出來的軟件在技術上可能很先進，但是并不是用戶所關心的。多數(shù)開發(fā)人員缺乏商業(yè)頭腦，常常做出背離企業(yè)根本目標的事情。企業(yè)領導應當重視這個問題，要經(jīng)常性地向開發(fā)人員們灌輸商業(yè)理念。讓他們明白“能夠賺錢的技術才是好技術”。在企業(yè)里，商業(yè)利益高于技術追求。

2.11.2項目經(jīng)理的財務權國內(nèi)大部分企業(yè)的項目經(jīng)理有帶頭干活的權利和義務，他們對項目的進度和質(zhì)量負最大責任，但是沒有財務權。大部分項目沒有經(jīng)費，即使有經(jīng)費，也得由上級領導審批使用，不能自己作主。有時團隊加班干了不少活，項目經(jīng)理卻沒有錢“意思意思”，很沒有面子。沒有財務權的項目經(jīng)理，不是完整意義上的項目經(jīng)理。企業(yè)不給項目經(jīng)理財務權的初衷是為了控制成本，防止項目經(jīng)理亂花錢。但是實際上效果適得其反。由于項目經(jīng)理沒有財務權，他們就不會關心成本也不懂得如何控制成本。因管理不成熟、工作效率不高、進度延誤等問題導致“隱性成本”不斷增加，錢在不知不覺地流失。企業(yè)領導應當給予項目經(jīng)理“適當”的財務權，只要確定項目財務制度并限定經(jīng)費額度，就不會造成失控。既讓項目經(jīng)理“有點小錢”慰勞團隊，有工作積極性；又讓他真正重視成本控制，并付諸實踐。用“小量胡蘿卜”獲得大回報。

2.12常見問題分析：其它問題2.12.1技術vs.3.中型企業(yè)的研發(fā)管理需求3.1需求特征必要性。如果軟件機構只有數(shù)人或者十幾個人，即使沒有研發(fā)管理規(guī)范，能力強的機構領導一個人也能從容指揮。當軟件機構的人數(shù)超過50人后，如果還沒有研發(fā)管理規(guī)范的話，那么機構領導將會力不從心。人數(shù)越多，非規(guī)范化管理越容易產(chǎn)生混亂，迫使企業(yè)不得不走規(guī)范化管理的路線，以降低管理代價和風險。經(jīng)濟基礎。建立規(guī)范化的研發(fā)管理是需要一定的投資的，例如咨詢、培訓、購買工具等等。小型軟件機構通常沒有錢去做這件事情，望洋興嘆。中型機構能夠養(yǎng)活50－200人，表示它們是有一定經(jīng)濟實力的，只要投資額適當而且產(chǎn)生的效益高于投資，那么中型機構一般都愿意做這件事情。

發(fā)展欲望。有些中型機構的領導雄心勃勃，高瞻遠矚，他們迫切希望提高研發(fā)管理能力從而提升整個企業(yè)的核心競爭力，產(chǎn)生源源不斷的推動力，推動企業(yè)持續(xù)發(fā)展壯大。他們對研發(fā)管理的態(tài)度是主動的，而不是被動的。

3.2費用估算國內(nèi)一些大型IT企業(yè)建立了完整的研發(fā)管理體系，投資巨大。例如上海貝爾、華為分別請HP、IBM建立研發(fā)管理體系，投資額分別達到數(shù)千萬元、上億元。這種投資額是中型企業(yè)望塵莫及的。在研發(fā)管理方面，中型企業(yè)無法效仿大型企業(yè)的做法。國內(nèi)中型軟件機構對研發(fā)管理的投資額大約在數(shù)萬元至元數(shù)十萬元。這點“小錢”根本無法引入IBM、HP、Rational等公司的研發(fā)管理解決方案。

大部分國內(nèi)中型軟件機構需要的是“輕量級”的研發(fā)管理解決方案，包括咨詢、培訓、購買工具，總費用在5萬元至20萬元之間比較合適。

3.中型企業(yè)的研發(fā)管理需求3.1需求特征4.基礎方法論介紹－CMM4.1基本概念產(chǎn)品是在過程中研制出來的。一般地，好的過程才可能得到好的產(chǎn)品，而差的過程只會得到差的產(chǎn)品。提高軟件過程能力的實踐通稱為軟件過程改進（SoftwareProcessImprovement）。軟件過程改進的根本目的是：提高質(zhì)量、提高生產(chǎn)率并且降低開發(fā)成本。

CMM/CMMI是世界范圍內(nèi)用于衡量軟件過程能力的事實上的標準，同時也是軟件過程改進最權威的指南。

CMM等級評估：從狂熱回歸理性?，F(xiàn)在軟件業(yè)界普遍關注的是：企業(yè)如何以比較低的代價有效地提高軟件過程能力。CMM等級評估則退居次要地位。

4.2CMM的盲區(qū)和常見應用問題CMM本身不談如何賺錢的問題。它假設了美好的前提條件，即企業(yè)有充足的人員、資金、時間從事軟件過程改進，當軟件過程能力提高了，那么產(chǎn)品的質(zhì)量、生產(chǎn)率自然上去了（同時成本也下降了），企業(yè)自然能夠獲取更多的利潤。軟件過程改進對企業(yè)經(jīng)濟效益的貢獻是間接的，從投入到產(chǎn)出，時間相對比較長。

企業(yè)領導當然想把資源用在“刀刃”上，即賺錢最多最快的地方。當軟件過程改進和其它直接賺錢的事情“發(fā)生資源沖突”時，人們只好“拆東墻，補西墻”，往往減少軟件過程改進的資源。小結：對于軟件過程改進而言，CMM/CMMI和ISO等等都是用來參考的，而不是用來迷信的。企業(yè)在參考業(yè)界推薦的標準或規(guī)范時，要舍棄那些聽起來很先進但是對本企業(yè)無益處的東西，只選取對企業(yè)有實用價值的東西。4.基礎方法論介紹－CMM4.1基本概念5.基礎方法論介紹－PMBOK5.1基本概念項目管理協(xié)會（PMI）是目前全球影響最大的項目管理專業(yè)機構，該機構的項目管理專家認證（PMP）被廣泛認同。PMI的突出貢獻是總結了一套項目管理知識體系（PMBOK）。

PMBOK把項目管理知識劃分為九個知識領域：綜合管理、范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、風險管理和采購管理。每個知識領域包括數(shù)量不等的項目管理過程。5.2PMBOK和CMM/CMMI對比簡評CMM/CMMI論述的項目管理方法僅僅適用于軟件項目，但是不適用于其它行業(yè)的項目管理。PMBOK論述的方法適用于任何行業(yè)的項目管理，但是對軟件項目管理而言，PMBOK的針對性不夠強。

CMM/CMMI不僅論述軟件項目管理，而且論述整個機構的軟件研發(fā)管理。PMBOK的方法局限于項目管理，對于企業(yè)研發(fā)管理則不夠用。

CMM/CMMI基本上不談“成本管理”和“人力資源管理”，它先假設機構有充足的資金和人力資源，通常不切合企業(yè)實際情況。因此PMBOK的“成本管理”和“人力資源管理”可以彌補CMM/CMMI的不足。

建議：對于軟件機構研發(fā)管理或者軟件項目管理，采用CMM/CMMI為主導的方法論，并結合PMBOK的知識，取長補短。5.基礎方法論介紹－PMBOK5.1基本概念6.基礎方法論介紹－敏捷開發(fā)6.1基本概念2001年，為了解決許多公司的軟件團隊陷入不斷擴大的過程泥潭，一批業(yè)界專家概括出了一些可以讓軟件開發(fā)團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯(lián)盟（AgileAlliance）。他們起草了一個旨在鼓勵更好的軟件開發(fā)方法的宣言，稱為敏捷聯(lián)盟宣言（TheManifestooftheAgileAlliance）。然后在該宣言基礎上制定了12條原則用于指導實踐。該宣言和12條原則是敏捷軟件開發(fā)方法的核心。

6.2我們的觀點敏捷軟件開發(fā)的宣言和12條原則并非普遍適用。敏捷開發(fā)方法表達了“簡單、快速、實用”的軟件開發(fā)思想，它不是成熟的理論、也不是事實上的標準（不象CMM,PMBOK那樣具有嚴密的理論體系，被企業(yè)廣泛接受）。即使人們認同某些原則，但是不同的人往往有不同的理解，實踐差異很大。敏捷開發(fā)方法對于提高個人、小型團隊的工作效率是很有幫助的（如果用對了的話）。但是企圖用它指導大型、中型軟件機構的研發(fā)管理是有很高風險的，它的某些主張是局部觀點而不是全局觀點，如果把握不好分寸的話可能導致整體混亂，而“整體的混亂”會淹沒“局部的好處”。我們研制的“精簡并行過程（SPP）”的理論基礎是“經(jīng)典軟件工程、CMM、PMBOK”。為了提高效率，在局部地方借鑒了“敏捷軟件開發(fā)的思想”，用于裁減過于冗長、笨重的過程規(guī)范。6.基礎方法論介紹－敏捷開發(fā)6.1基本概念6.基礎方法論介紹－敏捷開發(fā)敏捷軟件開發(fā)的12條原則：（1）我們最優(yōu)先要做的是通過盡早地、持續(xù)地交付有價值的軟件來使客戶滿意。

（2）即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。（3）經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

（4）在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天都在一起工作。

（5）圍繞被激勵起來的個人來構建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。

（6）在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。

（7）可以工作的軟件是首要的進度度量標準。

（8）敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。

（9）不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。

（10）簡單——把無需做的工作最大化的藝術——是最根本的。

（11）最好的構架、需求和設計出于自我組織的團隊。

（12）每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調(diào)整。6.基礎方法論介紹－敏捷開發(fā)敏捷軟件開發(fā)的12條原則：7.基礎方法論介紹－RUP7.基礎方法論介紹－RUP8.面向企業(yè)的軟件研發(fā)管理解決方案8.1目標幫助企業(yè)建立適合于自身需求的軟件研發(fā)管理規(guī)范，并部署配套的軟件工具；通過充分的培訓，幫助員工們掌握提高質(zhì)量、提高生產(chǎn)率、降低成本的方法；協(xié)助企業(yè)依據(jù)規(guī)范開展軟件研發(fā)和管理工作，持續(xù)提升能力。

8.2工作流程

面向企業(yè)的軟件研發(fā)管理解決方案8.面向企業(yè)的軟件研發(fā)管理解決方案8.1目標

面向企業(yè)的8.面向企業(yè)的軟件研發(fā)管理解決方案8.3集成化研發(fā)管理方法（SimplifiedParallelProcess,SPP）

8.面向企業(yè)的軟件研發(fā)管理解決方案8.3集成化研發(fā)管理8.面向企業(yè)的軟件研發(fā)管理解決方案8.4內(nèi)容和時間

1.調(diào)查分析問題

對企業(yè)研發(fā)管理的能力現(xiàn)狀進行調(diào)查與分析，調(diào)查內(nèi)容要覆蓋所有工作領域（過程域），總結“強項”和“弱項”，給出建議。

預計時間跨度為2個月，乙方到甲方現(xiàn)場工作和服務約20工作日。日程安排由雙方共同商定。

2.制定研發(fā)管理規(guī)范

繪制研發(fā)管理的總體流程圖；繪制組織結構圖，并確定角色職責表；定義每個過程域的規(guī)范（目的，關鍵活動和流程，工作成果）

3.選用合適的工具

選擇并部署合適的開發(fā)工具和管理工具。推薦管理工具是Future和CVS。含1年免費維護和升級服務4.充分必要的培訓

為研發(fā)管理流程中的所有人員提供充分必要的培訓，包括軟件工程、項目管理等，讓人們掌握提高軟件質(zhì)量、提高生產(chǎn)率、降低成本的方法。

5.執(zhí)行、監(jiān)督與反饋

協(xié)助客戶依據(jù)規(guī)范開展軟件研發(fā)和管理工作。跟蹤試點項目的執(zhí)行情況，及時解答執(zhí)行過程中遇到的問題，持續(xù)地提升客戶的軟件研發(fā)能力。

乙方提供一年的售后服務。

解決方案的內(nèi)容視企業(yè)的實際情況而定。

8.面向企業(yè)的軟件研發(fā)管理解決方案8.4內(nèi)容和時間

1.8.5相關著作8.5相關著作9.集成化軟件項目管理系統(tǒng)（Future）9.集成化軟件項目管理系統(tǒng)（Future）

9.集成化軟件項目管理系統(tǒng)（Future）9.2Future的特色物美價廉、富有成效的集成化項目管理工具Future將企業(yè)研發(fā)管理過程中最常用的工具全部集成于Web環(huán)境，并與方法論“精簡并行過程SPP”配套，相互支持。企業(yè)不必購買多個分立的管理工具，避免了管理工具之間不兼容、數(shù)據(jù)孤立的問題。不僅提高了研發(fā)管理效率，而且大大降低了購買工具的成本。Future軟件不僅可以為企業(yè)建立完備的研發(fā)管理數(shù)據(jù)庫，而且?guī)椭髽I(yè)領導對所有項目的進度、工作量、成本、質(zhì)量進行數(shù)據(jù)分析，為研發(fā)績效考核提供客觀依據(jù)。易用美觀的用戶界面Future軟件的系統(tǒng)視圖、項目視圖、個人視圖、領導視圖、文檔視圖、論壇視圖具有高度一致、易用美觀的用戶界面。用戶使用Future，可以輕松地完成研發(fā)項目的管理工作。這源于我們對用戶特征的深刻理解，和對用戶界面的精心設計。

容易擴展、與流行軟件兼容Future3.0的所有頁面數(shù)據(jù)可以導出到Excel文件；后續(xù)版本可以導入、導出MSProject數(shù)據(jù)；后續(xù)版本可以訪問配置管理軟件CVS的文件庫；后續(xù)版本將集成更多的工具，如人力資源管理系統(tǒng)、客戶關系管理系統(tǒng)等。為了方便地和企業(yè)現(xiàn)有的管理系統(tǒng)交互信息，我們提供WebService接口，并幫助用戶對Future進行二次開發(fā)。9.集成化軟件項目管理系統(tǒng)（Future）9.2Futu9.集成化軟件項目管理系統(tǒng)（Future）9.3Future3.0的運行環(huán)境服務器端操作系統(tǒng)：Windows2000/2003/XP，或Linux數(shù)據(jù)庫：缺省采用MySQL4.0.*，兼容Oracle,SQLServerJAVA運行環(huán)境：J2SE1.4以上版本W(wǎng)eb服務器：Tomcat4.1以上版本內(nèi)存：建議至少512M客戶端的配置操作系統(tǒng)：Windows2000/2003/XP瀏覽器：IE6.0以上版本內(nèi)存：建議至少256M9.集成化軟件項目管理系統(tǒng)（Future）9.3Futu9.4Future3.0功能示例－系統(tǒng)視圖－立項結項9.4Future3.0功能示例－系統(tǒng)視圖－立項結項9.5Future3.0功能示例－項目視圖－任務管理9.5Future3.0功能示例－項目視圖－任務管理9.6Future3.0功能示例－項目視圖－Gantt圖9.6Future3.0功能示例－項目視圖－Gantt圖9.7Future3.0功能示例－項目視圖－缺陷跟蹤9.7Future3.0功能示例－項目視圖－缺陷跟蹤9.8Future3.0功能示例－項目視圖－缺陷統(tǒng)計圖9.8Future3.0功能示例－項目視圖－缺陷統(tǒng)計圖9.9Future3.0功能示例－文檔視圖9.9Future3.0功能示例－文檔視圖9.10Future3.0功能示例－領導視圖－人員工作統(tǒng)計9.10Future3.0功能示例－領導視圖－人員工作統(tǒng)9.11Future3.0功能示例－個人視圖－個人任務9.11Future3.0功能示例－個人視圖－個人任務9.12Future3.0功能示例－論壇視圖－發(fā)貼回貼9.12Future3.0功能示例－論壇視圖－發(fā)貼回貼軟件研發(fā)管理問題和解決方案常見問題分析基礎方法論介紹整體解決方案林銳博士軟件研發(fā)管理問題和解決方案林銳博士目錄1.企業(yè)研發(fā)管理的理念2.常見問題分析3.中型企業(yè)的研發(fā)管理需求4.基礎方法論介紹－CMM5.基礎方法論介紹－PMBOK6.基礎方法論介紹－敏捷開發(fā)7.基礎方法論介紹－RUP8.面向企業(yè)的軟件研發(fā)管理解決方案9.基于Web的集成化項目管理系統(tǒng)Future3.0目錄1.企業(yè)研發(fā)管理的理念1.企業(yè)研發(fā)管理的理念1.1目標企業(yè)的根本目標是“合法地賺取盡可能多的利潤，使企業(yè)利益最大化”。企業(yè)所有的特定目標和行動都是圍繞根本目標開展的。根本目標進一步?jīng)Q定了企業(yè)研發(fā)管理的目標和策略。企業(yè)研發(fā)管理的基本目標是：讓所有人員有條不紊地開展工作，在預定的時間和成本之內(nèi)，開發(fā)完成質(zhì)量合格的產(chǎn)品，從而使企業(yè)和個人獲得預定的利益。企業(yè)研發(fā)管理的奮斗目標是：調(diào)動一切積極因素，努力提高產(chǎn)品質(zhì)量、提高工作效率并且降低成本，使企業(yè)和個人獲得比預定目標更多的利益。1.2質(zhì)量、進度（時間）、成本“質(zhì)量、進度（時間）、成本”通常是衡量企業(yè)研發(fā)管理“優(yōu)劣”的三個關鍵指標。不同的企業(yè)，甚至同一企業(yè)在不同時期，對三者的重要性看法是不一樣的。如果出現(xiàn)“三者難以同時兼得”的情況，那么產(chǎn)品的決策者一定要搞清楚質(zhì)量、進度（時間）、成本之間的復雜關系，判斷孰重孰輕，給出優(yōu)化和折衷的措施。

1.3規(guī)范化vs.超越規(guī)范化在企業(yè)里，大部分的工作是成熟的，有成功的模式可以套用，應當走規(guī)范化的路線；而另外小部分的工作可能是獨特的，并不適宜套用規(guī)范（也可能沒有規(guī)范可以套用），那么應當采用超越規(guī)范化的管理方式。通常前者約占80%，而后者約占20%

1.企業(yè)研發(fā)管理的理念1.1目標

2.1常見問題分析：立項管理2.1.1自主研發(fā)產(chǎn)品的立項問題擁有決策權的領導人獨自決定，或者招集有關人員開會商議是否開發(fā)某個產(chǎn)品。決策過程中的主觀臆斷比較多，風險很高。如果決策錯誤，即使人們努力開發(fā)出功能很好的產(chǎn)品，卻可能在商業(yè)上失敗。由于沒有進行充分必要的調(diào)研、可行性分析、立項建議、立項評審等工作，企業(yè)領導在組建開發(fā)團隊時難以給出恰當?shù)馁Y源和進度計劃。團隊只知道干活，卻不了解產(chǎn)品的開發(fā)背景，不清楚用戶期望的產(chǎn)品應該是什么樣的。在開發(fā)過程中經(jīng)常迷失方向，導致進度延誤、費用超支等問題。2.1.2合同項目的立項問題

委托方（客戶方）和承包方（開發(fā)方）在簽訂合同的時候，雙方對軟件需求的了解并不深入，合同中對“開發(fā)什么”的描述比較空洞。合同簽訂之后，客戶經(jīng)常變更需求，開發(fā)方被迫不斷修改軟件，弄得疲憊不堪?？鋸埖馗爬ǎ撼撕贤痤~不變，其它一切都可能改變。剛簽訂合同時開發(fā)方似乎賺錢了，后頭卻可能得不償失。雙方在簽訂合同的過程中給出了一些空頭承諾（例如對進度、質(zhì)量、費用的估計過于樂觀），在實際執(zhí)行時卻難以兌現(xiàn)這些承諾。處理不好將引發(fā)合同糾紛，輕則雙方提前終止合同，重則雙方反目成仇。2.1.3建議創(chuàng)建一種群體決策的立項管理規(guī)范，不僅讓群眾貢獻智慧，而且讓群眾分擔責任，使成功的經(jīng)驗被企業(yè)不斷復用，并升華成為企業(yè)的制度。

2.1常見問題分析：立項管理2.1.1自主研發(fā)產(chǎn)品的立項2.2常見問題分析：

結項管理2.2.1共性問題某些項目由于進度拖延，不能按計劃結項；某些項目即使開發(fā)完成了，由于利益關系也不愿結項。這些“不良”項目或者已經(jīng)完成的項目一直占用企業(yè)資源（如人力資源和設備），無疑違背企業(yè)利益最大化的目標。在結項時，人們往往對財務和設備進行了詳細的清算，卻忽視了對知識財富、經(jīng)驗教訓的總結。殊不知設備越用越差，但是知識財富越用越好，可謂主次顛倒。沒有對項目的價值進行評估，開發(fā)人員干完活后，不知道自己的工作成果產(chǎn)生多大的效益，缺乏成就感。結項后，不能對員工的業(yè)績進行公正考核，自然不能很好地激勵員工。合同軟件項目在結項之前，還面臨“客戶驗收”的一些問題。例如缺乏雙方認同的“驗收標準”，導致驗收過程混亂，過多地消耗雙方的精力。2.2.2建議首要措施是建立企業(yè)的“結項管理規(guī)范”和“驗收與發(fā)布”規(guī)范。自主研發(fā)的軟件產(chǎn)品在結項之前，公司內(nèi)部要進行類似的“驗收”，防止不良項目蒙混過關。2.2常見問題分析：結項管理2.2.1共性問題2.3常見問題分析：項目規(guī)劃2.3.1共性問題在項目剛開始階段，人們對產(chǎn)品需求和技術的了解還比較膚淺，項目不確定因素比較多，此時很難對工作量和進度作出比較準確的估算。軟件工程教科書和CMM推薦的COCOMO模型、代碼行估算方法等等，對大多數(shù)國內(nèi)項目無法適用，效果如同“電腦算命”。由此制定的項目計劃可能不切實際，后面經(jīng)常發(fā)生項目計劃的變更（所以業(yè)界流傳“計劃快不如變化快”），將導致項目管理的復雜性和風險提高。項目的人員已經(jīng)被上級領導限定死了，再多的活也是那幾個人干；項目的結束日期早就被領導和客戶指定了，不管合理不合理，反正時間一到就要交付軟件；除了辦公計算機和工資外，這個項目沒有其它經(jīng)費，項目經(jīng)理只有干活的權利沒有用錢的權利。如果人員、資金、時間都已經(jīng)被毫無道理地指定了，那么項目規(guī)劃就失去意義，這樣的項目在國內(nèi)非常普遍。

2.3.2建議建立企業(yè)的“項目規(guī)劃規(guī)范”，給出合適的項目估算方法和項目計劃模板。使用方便的軟件工具，幫助項目經(jīng)理進行項目規(guī)劃。2.3常見問題分析：項目規(guī)劃2.3.1共性問題2.4常見問題分析：項目監(jiān)控2.4.1共性問題許多項目經(jīng)理肩負重要的軟件開發(fā)工作，他們往往把注意力集中在開發(fā)上面，很少認真考慮如何進行項目監(jiān)控。沒有突出項目監(jiān)控的重點，項目經(jīng)理要么什么都不監(jiān)控（導致項目失控），要么監(jiān)控得太多而陷入瑣碎事務中。項目經(jīng)理寫周期性項目進展報告時，記流水帳，或者復制上次的報告，應付了事。懶得動腦筋分析項目遇到的一些問題，例如某些任務的進度延誤了，不分析為什么延誤了，就順延。導致問題越積越多。項目實際執(zhí)行情況與原定的項目計劃嚴重脫節(jié)，領導、客戶、市場人員、開發(fā)團隊不了解項目真正的狀況，使項目計劃行同虛設。2.4.2建議建立企業(yè)的“項目監(jiān)控規(guī)范”，使用方便的軟件工具，幫助項目經(jīng)理進行項目監(jiān)控。上級領導和相關人員每周都要檢查項目的監(jiān)控要素，及時發(fā)現(xiàn)問題，及時解決問題，既要關心結果也要關心過程。

2.4常見問題分析：項目監(jiān)控2.4.1共性問題2.5常見問題分析：配置管理和變更管理2.5.1共性問題有些軟件機構竟然不使用軟件配置管理工具，用最原始的方式手工管理代碼和文檔，經(jīng)常出現(xiàn)“成果丟失、版本混亂”等問題。不少機構按照的CMM的要求制定了配置管理規(guī)范。該規(guī)范在理論上比較完善，面面俱到，但是實際操作比較麻煩，沒有突出重點。久而久之，人們厭煩后就逐漸放棄了規(guī)范，按自己的習慣操作，留下了隱患。例如不少程序被

checkout后長久沒有

checkin；有些程序保留在開發(fā)者本機，根本就沒有放入配置庫。維護期間修改了程序，但是沒有放入配置庫。沒有變更控制流程，經(jīng)常隨意變更需求、設計、代碼等，嚴重影響項目的正常開發(fā)進程。2.5.2建議建立簡單有效的“配置管理規(guī)范”和“變更管理規(guī)范”。并使用方便的工具，幫助團隊進行軟件配置管理和變更管理。2.5常見問題分析：配置管理和變更管理2.5.1共性問題2.6常見問題分析：質(zhì)量管理2.6.1共性問題雖然人們大都認可軟件的質(zhì)量很重要，但是許多軟件人員并不懂得如何有效地改善軟件質(zhì)量屬性如正確性、健壯性、可靠性、性能、易用性、安全性、可擴展性、可復用性、兼容性、可移植性等等。不會分析當前軟件的質(zhì)量要素是什么，沒有把精力集中在改善對經(jīng)濟效益貢獻最大的質(zhì)量要素上面。

有些軟件機構沒有軟件質(zhì)量管理的措施，開發(fā)人員把完成功能當成終極目標。用戶在使用軟件的過程中發(fā)現(xiàn)許多Bug，導致開發(fā)方的糾錯性維護代價很高。

有些軟件機構雖然很重視軟件質(zhì)量，按照ISO,CMM的要求建立了管理規(guī)范，但是效果不明顯。人們搞不清楚軟件測試、技術評審、質(zhì)量保證的作用和關系。不懂得內(nèi)建質(zhì)量，主要靠修補錯誤的方式提升質(zhì)量，代價比較高。

很多人誤以為提高軟件質(zhì)量是質(zhì)量保證人員和測試人員的責任，沒有意識到任何開發(fā)人員、管理人員都會對質(zhì)量產(chǎn)生影響，都要對質(zhì)量負責。另外，質(zhì)量保證人員的權力比較小，很難推動質(zhì)量改進措施。2.6.2建議讓人們理解“什么是軟件質(zhì)量”及常見的軟件質(zhì)量屬性，樹立全面軟件質(zhì)量管理的理念（模型），制定軟件測試、技術評審、質(zhì)量保證的規(guī)范。并使用方便的工具，幫助團隊進行軟件質(zhì)量管理。2.6常見問題分析：質(zhì)量管理2.6.1共性問題2.7常見問題分析：需求開發(fā)與管理2.7.1共性問題對于大部分軟件機構而言，需求開發(fā)與需求管理是問題最多、最難解決的過程域。軟件機構中，通曉需求調(diào)查、需求分析、需求定義、需求評審、需求跟蹤、需求變更控制的人員本來就比較少，也不容易招聘和培養(yǎng)這樣的人才。

用戶說不清楚需求、用戶經(jīng)常變更需求是普遍現(xiàn)象，令開發(fā)方非常頭痛。開發(fā)人員不善于寫文檔，很難寫出清楚、完整的軟件需求規(guī)格說明書。后續(xù)開發(fā)人員可能誤解需求，做出與需求不一致的設計、代碼、測試用例等等，最后不得不大量返工重做。最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”?？蛻魰氘斎坏匾詾樽兏枨笫撬臋嗬驗樗跺X給開發(fā)方。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。2.7.2建議建立“需求開發(fā)與管理規(guī)范”，給出合適的文檔模板，采用方便的需求分析和管理工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。

制定應對需求變更的辦法，例如：(1)雙方簽訂需求變更管理協(xié)議;(2)將重大需求變更延緩到下個軟件版本中實現(xiàn);(3)讓客戶欠下人情。

2.7常見問題分析：需求開發(fā)與管理2.7.1共性問題2.8常見問題分析：軟件設計2.8.1共性問題對于大部分軟件機構而言，用戶界面設計是弱項。國內(nèi)絕大多數(shù)大學的計算機學科沒有開設人機工程學、美學、心理學這些必修課。由于學生們接受的教育幾乎全是科學與技術，他們根本不知道怎樣才能設計出易用、美觀的用戶界面，很多人甚至想都沒有想過。當他們畢業(yè)后真正參與軟件產(chǎn)品開發(fā)時，只好憑著個人的經(jīng)驗與感覺設計軟件的用戶界面，這樣產(chǎn)生的界面往往得不到大眾用戶的認可。

大部分軟件機構都有一些技術出色的軟件人員，他們在系統(tǒng)構架、數(shù)據(jù)庫方面的設計能力相當不錯。但是很多人不愿意、不善于寫系統(tǒng)設計報告，這不利于后續(xù)的軟件開發(fā)和維護。軟件設計應當“細到什么程度”很難把握。太粗了的話，對后續(xù)開發(fā)工作的指導價值不高；反之倘若太細的話，耗費時間就比較多，如果后面不斷改進設計的話，前面的設計浪費太多。2.8.2建議建立“軟件設計規(guī)范”，給出合適的文檔模板，采用方便的設計工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。

2.8常見問題分析：軟件設計2.8.1共性問題2.9常見問題分析：編程與調(diào)試2.9.1共性問題軟件機構的大部分程序員的技能是合格的，但是他們編寫的程序風格差異較大，代碼質(zhì)量有高有低。大多數(shù)軟件機構沒有編程規(guī)范，即使有的話，開發(fā)人員也沒有很好地按規(guī)范編程。相當多的程序員沒有養(yǎng)成對所有代碼進行“單步跟蹤調(diào)試”的習慣。嫌單元測試很麻煩，懶得執(zhí)行，卻沒有替代方案。2.9.2建議制定簡單明了、重點突出的“編程規(guī)范”，讓團隊遵照此規(guī)范編寫程序。采用集成化的開發(fā)調(diào)試工具，提高編程質(zhì)量和效率。2.9常見問題分析：編程與調(diào)試2.9.1共性問題2.10常見問題分析：軟件測試2.10.1共性問題許多軟件人員沒有系統(tǒng)地學習過軟件測試，搞不清楚各種測試的概念，例如單元測試、集成測試、驗收測試、黑盒測試、白盒測試、功能測試、性能測試等等，混為一談，不知如何下手。測試人員沒有掌握有效測試的方法，大多憑感覺測試，結果重復測試已經(jīng)測試過的，那些深藏的bug卻發(fā)現(xiàn)不了?？蛻粼谑褂密浖倪^程中發(fā)現(xiàn)的bug比公司內(nèi)部測試時發(fā)現(xiàn)的還多，不僅改錯代價高，而且降低了客戶對產(chǎn)品的滿意度。團隊沒有采用有效的缺陷跟蹤工具。測試人員發(fā)現(xiàn)bug時，口頭告知有關人員或者記在Word、Excel文件中，修改bug信息或者測試報告時非常麻煩。難以及時從bug列表中找出規(guī)律，測試的效率比較低。2.9.2建議建立“軟件測試規(guī)范”，采用方便的測試管理工具。還要多請有經(jīng)驗的人來培訓、傳授實戰(zhàn)經(jīng)驗。2.10常見問題分析：軟件測試2.10.1共性問題2.11常見問題分析：軟件維護2.11.1共性問題在維護期間，除了糾錯性維護外，客戶可能提出需求變更（但是不支付費用），維護人員對客戶妥協(xié)，導致維護工作量增大、成本增加。如果是合同軟件項目，用戶對開發(fā)方的依賴性比較大，不愿意自己解決粗淺的問題，經(jīng)常叫開發(fā)方“干這干那”。開發(fā)方不敢得罪客戶，導致開發(fā)方做了許多不屬于維護的工作，吃啞巴虧。開發(fā)人員一邊開發(fā)新項目，一邊維護老項目。而維護為體現(xiàn)不出業(yè)績，又影響了新項目的進度，開發(fā)人員比較心煩。2.11.2建議制定“軟件維護規(guī)范”，界定什么是“免費維護”、什么是“有償維護”，以及相應的操作規(guī)則，提高維護效率并且降低維護成本。

2.11常見問題分析：軟件維護2.11.1共性問題2.12常見問題分析：其它問題2.12.1技術vs.市場許多開發(fā)人員喜歡技術研究和技術挑戰(zhàn)。雖然嘴上說開發(fā)產(chǎn)品要以“客戶（市場）為中心”，但是在開發(fā)軟件的時候，卻不知不覺以技術為中心，例如喜歡采用新技術、追求技術上的完美。導致進度延誤，成本增加，甚至可能有質(zhì)量風險。他們開發(fā)出來的軟件在技術上可能很先進，但是并不是用戶所關心的。多數(shù)開發(fā)人員缺乏商業(yè)頭腦，常常做出背離企業(yè)根本目標的事情。企業(yè)領導應當重視這個問題，要經(jīng)常性地向開發(fā)人員們灌輸商業(yè)理念。讓他們明白“能夠賺錢的技術才是好技術”。在企業(yè)里，商業(yè)利益高于技術追求。

2.11.2項目經(jīng)理的財務權國內(nèi)大部分企業(yè)的項目經(jīng)理有帶頭干活的權利和義務，他們對項目的進度和質(zhì)量負最大責任，但是沒有財務權。大部分項目沒有經(jīng)費，即使有經(jīng)費，也得由上級領導審批使用，不能自己作主。有時團隊加班干了不少活，項目經(jīng)理卻沒有錢“意思意思”，很沒有面子。沒有財務權的項目經(jīng)理，不是完整意義上的項目經(jīng)理。企業(yè)不給項目經(jīng)理財務權的初衷是為了控制成本，防止項目經(jīng)理亂花錢。但是實際上效果適得其反。由于項目經(jīng)理沒有財務權，他們就不會關心成本也不懂得如何控制成本。因管理不成熟、工作效率不高、進度延誤等問題導致“隱性成本”不斷增加，錢在不知不覺地流失。企業(yè)領導應當給予項目經(jīng)理“適當”的財務權，只要確定項目財務制度并限定經(jīng)費額度，就不會造成失控。既讓項目經(jīng)理“有點小錢”慰勞團隊，有工作積極性；又讓他真正重視成本控制，并付諸實踐。用“小量胡蘿卜”獲得大回報。

2.12常見問題分析：其它問題2.12.1技術vs.3.中型企業(yè)的研發(fā)管理需求3.1需求特征必要性。如果軟件機構只有數(shù)人或者十幾個人，即使沒有研發(fā)管理規(guī)范，能力強的機構領導一個人也能從容指揮。當軟件機構的人數(shù)超過50人后，如果還沒有研發(fā)管理規(guī)范的話，那么機構領導將會力不從心。人數(shù)越多，非規(guī)范化管理越容易產(chǎn)生混亂，迫使企業(yè)不得不走規(guī)范化管理的路線，以降低管理代價和風險。經(jīng)濟基礎。建立規(guī)范化的研發(fā)管理是需要一定的投資的，例如咨詢、培訓、購買工具等等。小型軟件機構通常沒有錢去做這件事情，望洋興嘆。中型機構能夠養(yǎng)活50－200人，表示它們是有一定經(jīng)濟實力的，只要投資額適當而且產(chǎn)生的效益高于投資，那么中型機構一般都愿意做這件事情。

發(fā)展欲望。有些中型機構的領導雄心勃勃，高瞻遠矚，他們迫切希望提高研發(fā)管理能力從而提升整個企業(yè)的核心競爭力，產(chǎn)生源源不斷的推動力，推動企業(yè)持續(xù)發(fā)展壯大。他們對研發(fā)管理的態(tài)度是主動的，而不是被動的。

3.2費用估算國內(nèi)一些大型IT企業(yè)建立了完整的研發(fā)管理體系，投資巨大。例如上海貝爾、華為分別請HP、IBM建立研發(fā)管理體系，投資額分別達到數(shù)千萬元、上億元。這種投資額是中型企業(yè)望塵莫及的。在研發(fā)管理方面，中型企業(yè)無法效仿大型企業(yè)的做法。國內(nèi)中型軟件機構對研發(fā)管理的投資額大約在數(shù)萬元至元數(shù)十萬元。這點“小錢”根本無法引入IBM、HP、Rational等公司的研發(fā)管理解決方案。

大部分國內(nèi)中型軟件機構需要的是“輕量級”的研發(fā)管理解決方案，包括咨詢、培訓、購買工具，總費用在5萬元至20萬元之間比較合適。

3.中型企業(yè)的研發(fā)管理需求3.1需求特征4.基礎方法論介紹－CMM4.1基本概念產(chǎn)品是在過程中研制出來的。一般地，好的過程才可能得到好的產(chǎn)品，而差的過程只會得到差的產(chǎn)品。提高軟件過程能力的實踐通稱為軟件過程改進（SoftwareProcessImprovement）。軟件過程改進的根本目的是：提高質(zhì)量、提高生產(chǎn)率并且降低開發(fā)成本。

CMM/CMMI是世界范圍內(nèi)用于衡量軟件過程能力的事實上的標準，同時也是軟件過程改進最權威的指南。

CMM等級評估：從狂熱回歸理性?，F(xiàn)在軟件業(yè)界普遍關注的是：企業(yè)如何以比較低的代價有效地提高軟件過程能力。CMM等級評估則退居次要地位。

4.2CMM的盲區(qū)和常見應用問題CMM本身不談如何賺錢的問題。它假設了美好的前提條件，即企業(yè)有充足的人員、資金、時間從事軟件過程改進，當軟件過程能力提高了，那么產(chǎn)品的質(zhì)量、生產(chǎn)率自然上去了（同時成本也下降了），企業(yè)自然能夠獲取更多的利潤。軟件過程改進對企業(yè)經(jīng)濟效益的貢獻是間接的，從投入到產(chǎn)出，時間相對比較長。

企業(yè)領導當然想把資源用在“刀刃”上，即賺錢最多最快的地方。當軟件過程改進和其它直接賺錢的事情“發(fā)生資源沖突”時，人們只好“拆東墻，補西墻”，往往減少軟件過程改進的資源。小結：對于軟件過程改進而言，CMM/CMMI和ISO等等都是用來參考的，而不是用來迷信的。企業(yè)在參考業(yè)界推薦的標準或規(guī)范時，要舍棄那些聽起來很先進但是對本企業(yè)無益處的東西，只選取對企業(yè)有實用價值的東西。4.基礎方法論介紹－CMM4.1基本概念5.基礎方法論介紹－PMBOK5.1基本概念項目管理協(xié)會（PMI）是目前全球影響最大的項目管理專業(yè)機構，該機構的項目管理專家認證（PMP）被廣泛認同。PMI的突出貢獻是總結了一套項目管理知識體系（PMBOK）。

PMBOK把項目管理知識劃分為九個知識領域：綜合管理、范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、風險管理和采購管理。每個知識領域包括數(shù)量不等的項目管理過程。5.2PMBOK和CMM/CMMI對比簡評CMM/CMMI論述的項目管理方法僅僅適用于軟件項目，但是不適用于其它行業(yè)的項目管理。PMBOK論述的方法適用于任何行業(yè)的項目管理，但是對軟件項目管理而言，PMBOK的針對性不夠強。

CMM/CMMI不僅論述軟件項目管理，而且論述整個機構的軟件研發(fā)管理。PMBOK的方法局限于項目管理，對于企業(yè)研發(fā)管理則不夠用。

CMM/CMMI基本上不談“成本管理”和“人力資源管理”，它先假設機構有充足的資金和人力資源，通常不切合企業(yè)實際情況。因此PMBOK的“成本管理”和“人力資源管理”可以彌補CMM/CMMI的不足。

建議：對于軟件機構研發(fā)管理或者軟件項目管理，采用CMM/CMMI為主導的方法論，并結合PMBOK的知識，取長補短。5.基礎方法論介紹－PMBOK5.1基本概念6.基礎方法論介紹－敏捷開發(fā)6.1基本概念2001年，為了解決許多公司的軟件團隊陷入不斷擴大的過程泥潭，一批業(yè)界專家概括出了一些可以讓軟件開發(fā)團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯(lián)盟（AgileAlliance）。他們起草了一個旨在鼓勵更好的軟件開發(fā)方法的宣言，稱為敏捷聯(lián)盟宣言（TheManifestooftheAgileAlliance）。然后在該宣言基礎上制定了12條原則用于指導實踐。該宣言和12條原則是敏捷軟件開發(fā)方法的核心。

6.2我們的觀點敏捷軟件開發(fā)的宣言和12條原則并非普遍適用。敏捷開發(fā)方法表達了“簡單、快速、實用”的軟件開發(fā)思想，它不是成熟的理論、也不是事實上的標準（不象CMM,PMBOK那樣具有嚴密的理論體系，被企業(yè)廣泛接受）。即使人們認同某些原則，但是不同的人往往有不同的理解，實踐差異很大。敏捷開發(fā)方法對于提高個人、小型團隊的工作效率是很有幫助的（如果用對了的話）。但是企圖用它指導大型、中型軟件機構的研發(fā)管理是有很高風險的，它的某些主張是局部觀點而不是全局觀點，如果把握不好分寸的話可能導致整體混亂，而“整體的混亂”會淹沒“局部的好處”。我們研制的“精簡并行過程（SPP）”的理論基礎是“經(jīng)典軟件工程、CMM、PMBOK”。為了提高效率，在局部地方借鑒了“敏捷軟件開發(fā)的思想”，用于裁減過于冗長、笨重的過程規(guī)范。6.基礎方法論介紹－敏捷開發(fā)6.1基本概念6.基礎方法論介紹－敏捷開發(fā)敏捷軟件開發(fā)的12條原則：（1）我們最優(yōu)先要做的是通過盡早地、持續(xù)地交付有價值的軟件來使客戶滿意。

（2）即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。（3）經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

（4）在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天都在一起工作。

（5）圍繞被激勵起來的個人來構建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。

（6）在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。

（7）可以工作的軟件是首要的進度度量標準。

（8）敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。

（9）不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。

（10）簡單——把無需做的工作最大化的藝術——是最根本的。

（11）最好的構架、需求和設計出于自我組織的團隊。

（12）每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調(diào)整。6.基礎方法論介紹－敏捷開發(fā)敏捷軟件開發(fā)的