小型組織推行CMM

1、 如何在小型組織中推行CMMCMM SM是適用于小工程項目和小規(guī)模組織的經(jīng)剪裁的CMM版本。而CMM V1.1是用適宜于那些和政府簽約的大型組織的標準實踐來表達的，這些實踐必須剪裁才能適合不同于這個樣板的組織的需要。摘要有關在小工程或小組織中應用CMM的一些常見問題包括：·什幺樣的才算做“小”？標準是根據(jù)人？時間？項目大?。窟€是產(chǎn)品的艱難復雜程度？· 什幺是CMM的“需求”？是否有不該被應用到小項目/小組織中去的關鍵過程區(qū)域或目標？有好的過程“不變量”嗎？· 造成CMM被濫用的驅(qū)動力和動機是什幺？這篇論文以小型組織為例討論了怎樣在各種商業(yè)環(huán)境中正確而有效地使用CM

2、M。作者簡介 Mark是美國軟件工程學會（SEI）的一名技術人員。他1987年加入SEI ,最初參與的是軟件能力評價項目的工作。Mark從一開始就工作在軟件能力成熟度模型方面，并且是開發(fā)CMM1.1版本時的項目領導人。他也一直活躍在制定有關軟件工程的標準上, 這些標準包括：· ISO 15504 ( 也稱為SPICE-軟件過程改進和能力決斷),一整套軟件過程評估的國際標準· ISO 12207 , 軟件生存周期過程· ISO 15288 , 系統(tǒng)生存周期過程在加入SEI之前，Mark是系統(tǒng)開發(fā)公司（System Development Corporation，即優(yōu)

3、利國防系統(tǒng)公司Unisys Defense Systems的前身）的位于亞拉巴馬州Huntsville的彈道導彈防護高級研究中心（Ballistic Missile Defense Advanced Research Center）的一名高級系統(tǒng)分析員。Mark在德比爾特大學獲得了他的計算機科學碩士學位。在Huntsville的亞拉巴馬州立大學獲得了他的數(shù)學和計算機科學學士學位。專業(yè)資格與證明·電子學會高級研究員與電子工程師 (IEEE，美國電氣與電子工程師學會）·美國質(zhì)量協(xié)會高級研究員 (ASQ，美國質(zhì)量協(xié)會)· 美國質(zhì)量協(xié)會（ASQ）認證軟件質(zhì)量工程師提供了路

4、標。CMM定義了怎樣使開發(fā)組織的軟件過程走向成熟的5個等級的框架結(jié)構。這些等級描述了從特別紊亂的混沌過程到成熟的、有紀律的軟件過程的進化路徑。CMM在稱心如意地實施管理與工程實踐方面，都提供了良好的建議，它強調(diào)以人為核心的管理、溝通和協(xié)調(diào)以與能體現(xiàn)軟件開發(fā)和維護特性的強化設計的過程。無論如何，把它看成靈活的指南而非生硬的指令吧，還有對于軟件工程和管理，以與應用領域和組織的商業(yè)環(huán)境等方面，CMM用戶必須能夠在這些方面應用其基于知識和經(jīng)驗的專業(yè)判斷。因為CMM聚焦于軟件，所以TQM的一些重要方面不能直接照搬到模型里，比如系統(tǒng)工程里的“人的問題（people issues）”和“較寬泛的審視（bro

5、ader perspective）”，這些在商業(yè)上可能是至關重要的。CMM應該被看成使用在軟件過程改進系統(tǒng)步驟里的一種上下文工具，比如SEI的IDEAL模型，如圖2所示McFeeley96。/ / TQC abbr. 全面質(zhì)量管理 (total quality control)在對軟件過程改進的討論中，開始的問題總應該是這樣的：為什幺軟件組織會對使用CMM感興趣？如其愿望是以直接依從商業(yè)目標以與心甘情愿投身改革而來改進過程，那幺CMM確實是效用非凡、功能強大的工具；如果CMM只被當成單純的短期時髦，那可真是把一劑糟糕的藥方拿到了手。如果驅(qū)動力是客戶利益，理想情況下客戶利益將導致客戶和供應商之間

6、協(xié)作的改進。有時供應商的利益集中在軟件能力評價(Software Capability Evaluations，SCEs)上, 如此則可在那些來源選擇與簽約監(jiān)督方面是由政府獲取代理的項目上有所表現(xiàn)。國防部在執(zhí)行軟件能力評價(SCEs)標準的政策上是排斥絕大多數(shù)小組織和小項目的Barbour96，但也存在它們可以有所作為的機遇。很多CMM的濫用都對“其它人”可以做什幺的擔心置于不顧。如若一個開發(fā)組織能在用CMM來導引勝過被需求來牽引上達成共識，那幺在模型中要解決問題的很大一部分就化解掉了。有很多這樣的案例。盡管如此，那些對于好的工程和管理實踐的無知仍將成為問題。對于那些只有很少的管理方面的經(jīng)驗和

7、訓練而只是因技術優(yōu)秀就被提拔到管理層職位的人來講，問題是顯而易見的。由DOD（美國國防部）特種部隊確認并提出的問題是DOD87：· “少數(shù)區(qū)域在最佳當前實踐和平均當前實踐之間有著如此巨大的缺口?！?#183; “大問題不在技術方面現(xiàn)今軍事軟件開發(fā)的主要問題不再是技術問題，而是管理問題?！?. 小組織和小項目本篇論文的焦點對準了在小組織正確而有效地使用CMM，因為經(jīng)常有人問我，“CMM是否能被用在小項目(或小組織)？”然而有關“小”的定義卻是模糊難解的，如表1所示。在某段時間里我們致力于為小項目和小組織而開發(fā)出剪裁適當?shù)腃MM，1995年CMM剪裁工作室的結(jié)論是我們甚至不能對什幺才算“

8、小”的真正含義達成一致意見！這個結(jié)果得出了一篇更注重于“如何剪裁CMM”而不是“已為小組織而裁好的CMM”的報告Ginsberg95。1998年SEPG會議關注于CMM與小組織上，“小”被定義成“5個或更少的人為期3至4個月的開發(fā)”。Brodman和Johnson則定義“小組織”為少于50個軟件開發(fā)人員并且“小項目”為少于20個開發(fā)人員Johnson98。表1. 定義一個小項目小的變體人數(shù)總的時間小 3-5 6個月很小 2-3 4個月微小 1-2 2個月個人 1 1星期荒唐！ 1 1小時注意從小到微小的項目是在被Humphrey稱為小組軟件過程（Team Software Process，TS

9、P）的圍里，而個人的開發(fā)努力則在個人軟件過程（Personal Software Process，PSP）的圍里Humphrey95。TSP和PSP闡明了CMM的概念是如何應用到小項目中的?！盎奶啤弊凅w則描述了一個解釋性的問題。在兩種場合里，變體都會被論述，問題是“項目”的定義。兩種情況下它都是個維護環(huán)境，而且組織的“項目”將被描述為CMM的任務；更多關于CMM“項目”的精確解釋是一個基線的升級或者維護的發(fā)行但術語的沖突會將其搞亂。對于那些使用CMM的小組織來說，首要的挑戰(zhàn)就是其主要商業(yè)目標要能存活下來！甚至在決定之后，現(xiàn)狀是不能令人滿意的而且過程改進也將有助于發(fā)現(xiàn)資源并為過程改進分派職責,接

10、下來通過制定與部署過程所要做的是一項艱難的商務決定。小組織往往相信：· 我們?nèi)际莿偃蔚娜藗兪潜还蛡騺碜龉ぷ鞯?，我們可不想負擔那些要在雇傭期間進行培訓所花的任何時間或金錢。· 我們?nèi)急舜藴贤ㄒ蛭覀兪侨绱司o密地在“滲透式”工作。· 我們?nèi)际怯⑿酆脻h我們無論做任何需要做的事情，規(guī)則都不適用于我們（這些恰恰達成了將工作完成的方式），我們承受住了短周期與高壓力。然而對于小組織，也正象大組織一樣，有著非文檔化的需求所帶來的麻煩，以與無經(jīng)驗的經(jīng)理人員、資源分配、培訓、同行評審和產(chǎn)品文檔等方面帶來的問題。盡管有著這些挑戰(zhàn)，小組織仍能非同尋常地進行創(chuàng)新和提高生產(chǎn)率。盡管有一大

11、把需要人們?nèi)ソ鉀Q的大塊問題，通常小組織比大組織更具生產(chǎn)效率，他們能更敏銳地成形生產(chǎn)要素并且遠遠更少見有溝通方面的問題。無論如何，遺留下來的問題是，小組織也需要過程紀律嗎？回答這些CMM咒語,我們需要考慮到紀律包括了什幺? 而那將引入這篇有關CMM指導性課題論文的核心。即便如此，評估小組織時運用最新式的評估過程是明智可取的。為期兩周的CMM部過程改進基礎評估(CMM IPI)的形式也許是多余的Strigel95, Paquin98, Williams98，甚至會由于缺乏監(jiān)控而導致某些遺漏，而關鍵是有效地確認重大問題。我建議將注意力集中在建立在企業(yè)文化上的制度化實踐方面：如規(guī)劃、培訓等等，并確切地

12、將過程改進落實到商業(yè)需要上。3. 解釋CMM CMM都適用在什幺地方呢？CMM是按照在任何環(huán)境中為任何項目都能提供良好的軟件工程和管理實踐來塑造的。模型是被分層次描述的：成熟度等級 (5)->關鍵過程區(qū)域 (18)->目標（52）->關鍵實踐（316）->子實踐和例子 (許多)根據(jù)我最近十年來在軟件過程工作方面的經(jīng)驗，闡述的環(huán)境以與CMM的剪裁需要包括：·非常大的程序·虛擬項目或組織· 地點上分布式的項目·快速原型法的項目·研究與開發(fā)組織·軟件服務組織· 小項目和小組織對于小項目和小組織的解釋性指導也

13、同樣適用于大項目和大組織。在正確有效地使用CMM的過程中，智能和常識是必要的Paulk96。所有（軟件）項目都有所不同，但所有（軟件）項目也都有所一樣這可全都是真的。我們必須平衡現(xiàn)實：相似與唯一，秩序與混亂。那些成功所締造出的持久組織Collins94是真正有能力的學習型組織Senge90；此外在其它地方也必須得益于其成功。CMM的標準構件是成熟度等級、關鍵過程區(qū)域和目標。CMM的所有實踐都是有益處的。既然那些詳細的實踐都首先支持大型簽約的軟件組織，也就沒必要正好寫成是直接適用于小項目和小組織然而它們同樣提供了如何達到目標和可重復地實現(xiàn)已定義的、規(guī)的、不斷改進的軟件過程。這樣就會避免了過程評估

14、方式上的簡單武斷諸如“去問老吧”。我最通常的指導性建議是開發(fā)出一套適用于組織的置于CMM術語和語言間的映像。特別地,組織結(jié)構的期限行為、角色、關系以與過程的形式都需要映像到其組織的相應部分，以防止出現(xiàn)無法理喻的事情，諸如“荒誕的一小時項目”。組織結(jié)構的例子包括諸如質(zhì)量保證、測試與配置管理等“獨立小組”。應該用術語明確地指定適當?shù)慕M織角色，諸如項目經(jīng)理與項目軟件經(jīng)理等。人們可以擔當多重角色，例如，一個人可以同時做項目經(jīng)理、項目軟件經(jīng)理、軟件配置管理（SCM）經(jīng)理等等。明確規(guī)劃好這些，將生發(fā)出對CMM更生動簡潔也更協(xié)調(diào)一致的闡明。一旦術語問題被理解了，我們就得考慮什幺是守紀律過程的“不變量”|he

15、re|（invariant，一個必須永遠為真的約束）以與哪些實踐依賴于上下文關系。除了軟件轉(zhuǎn)包合同管理（即若無轉(zhuǎn)包合同的話就可能成為“不可用的”），一般來說我們總是假定關鍵過程區(qū)域與目標關聯(lián)到任何環(huán)境。我想象不出同行評審被等級3的組織適當剪裁掉的情形。盡管所選擇出的實踐（諸如正式方法）可以替代同行評審，但這還是一個需要足夠?qū)I(yè)性判斷的問題。擁有專業(yè)性的判斷和訓練、經(jīng)驗豐富的評估人員是至關重要的，甚至對小組織也一樣！Abbott97我從沒見過下列哪個環(huán)節(jié)是不必要的(盡管實現(xiàn)方式不同)：· 將客戶(系統(tǒng))的需求記錄成文檔·與客戶(并且最終用戶)溝通·同意承諾并簽約&#

16、183;計劃· 文檔化過程· 工作細化結(jié)構當然，一些實踐都被處理成了“大項目的實現(xiàn)”。小的項目未必需要軟件配置管理組或者變更控制部門，然而配置管理與變更控制總還是要有的。一個獨立的軟件質(zhì)量保證(SQA)組也許不是必要的，但目標的認可始終是需求要被滿足。一個獨立的測試組也許沒必要設立，但測試總是必要的。即使小組織和大組織之間的實現(xiàn)有著根本的不同，但我們看到對于上下文相關的實踐，其意旨是建設性的。如果有人讀到CMM所定義的“組”，它是被述為“一個組可以是被分派兼職的單獨個人、從不同部門分派了幾個兼職的個人，也可以是全職的幾個個人”，這里就有意迎合了環(huán)境的變化。除了這些, 一些特

17、殊的問題再三地出現(xiàn), 尤其是對于小組織，涉與有：·管理資助·度量· 軟件工程過程組(SEPGs，Software Engineering Process Groups)·“不保修”過程· 文檔化過程·剪裁·培訓·風險管理·計劃· 同行評審獲取高層管理的贊助是構建組織能力的關鍵成分，這看起來固然很腐老套。做為個體，我們可以在我們可操控的圍磨練自身的專業(yè)素養(yǎng)與自制能力?？墒侨粢粋€組織作為一個整體來改善其效能，那幺其高層管理就必須積極地支持變革。由下至上地改革，無須贊助和協(xié)同，卻能夠?qū)虺^可預期改

18、進的組織能力的勝地，這可真是奇聞了。即便如此，當總裁（或者公司創(chuàng)始人）是主角時，敬重“冠軍”往往是具有撼動整個組織的影響力的包括總裁本人。對于大多數(shù)組織而言，管理實際上是必須基于一個度量基礎的例轉(zhuǎn)換。掌握有用的數(shù)據(jù)，就是說你必須了解性能數(shù)據(jù)的含義以與如何有價值地去分析它。從收集簡單的有用數(shù)據(jù)開始，你也不得不敏感于經(jīng)由度量而導致紊亂行為的潛在因素Austin96。度量活動要確認什幺是重要的，但一些事情是難于度量的。管理需要確保注意力傾注在項目的所有可評價方面，包括那些難于度量的，而不僅僅是那些易于度量和跟蹤的。在大多數(shù)組織中，軟件工程過程組(SEPG)或一些類似小組應該成為協(xié)調(diào)過程定義、改進與部

19、署活動的工作組。把資源奉獻給SEPG的原因之一是要確保完成評估調(diào)查。許多改進綱要僅僅因為有著不是從評估所導致的行動而失敗。小組織可能沒有全職的SEPG人員，但改進的職責應該明確地加以指派和監(jiān)控。起始于“不保修”（"as is"）過程，而不是“合理”（"should be"）過程對于有效實施的實踐與對指派任務的抵觸來說，這相當于兩者之間的杠桿，此起彼落。要求自上而下的每個人都遵循的“合理”過程，若其顯著地不是由被授權的工人所參與開發(fā)的，則將是一個通用的失敗處方?！安槐Ｐ蕖边^程進化的理由是人們從事工作是希望工作任務能被完成（即使那意味著要整天圍著系統(tǒng)轉(zhuǎn)）?！?/p>

20、合理”過程或可行，或不可行只有在特定的文化環(huán)境中才能成為可行。伴隨著過程管理和改進的組織焦點，“不保修”和“合理”過程將聚合在一點即導致有組織地進行學習。文檔化你的過程。文檔化地記錄一個過程(或產(chǎn)品)的原因是1)溝通給別人一個當前的交待以與給自己一個今后的備忘；2)理解如果你不能寫下它，你就不能真正理解它；以與3)鼓勵連貫一致性擁有可重復的優(yōu)勢。文檔化過程支持有組織地學習以與避免重復地打造解決通用問題的車輪（車輪在任何地方都被置于一個反復重用的過程）。歸檔是如此重要，但有用的文檔最好不要冗長繁雜。我們生活在一個迅速變化的世界里，請保持文檔簡潔吧。過程也不要冗長繁復。CMM關注做事（doing

21、things），而不是成事（having things）。一個1-2頁的過程說明是足夠了，子過程和步驟能按需調(diào)用就行。運用好的軟件設計原則，比如在定義過程中使用存空間的局域性、信息隱藏以與抽象。另外的實用經(jīng)驗是每周最多跟蹤2-3個任務的工作。其順序應由少量指導性原則或法則所確立，而不是由復雜的控制來確立Wheatley92, page 11。過程需要剪裁到項目所需的程度Ginsberg95,Ade96。雖然標準過程提供了一個基礎，但每一個項目也都將有其獨特的要求。剪裁時不切實際的約束可導致執(zhí)行過程中的重大阻力。正如Hoffman所表述的，“別生造感悟也別強求過程?！盚offman98過程所需的

22、形式化程度對大組織和小組織都構成了威脅Comer98。對于那些每每提到要“按照文檔化步驟”的等級2的25個關鍵實踐中的每一個，應該存有很個別的步驟嗎？答案正如在CMM書籍文檔和CMM(Documentation and the CMM)的4.5.5小節(jié)所論述的，是一個響亮的“不！”文檔的包裝是組織化的必然結(jié)果。文檔化的過程如果沒有加以有效地部署，只會具有很小的價值。要想達成文檔化的大量買進，過程實現(xiàn)必須成為過程定義和改進的一部分。通過多種機制的培訓，對于協(xié)調(diào)一致和效力非凡的軟件工程與管理將是建設性的。培訓的動機是發(fā)展技能。有很多“培訓機制”不同于能有效培養(yǎng)技能的正規(guī)課堂培訓。其中應該被認真考慮

23、的是正規(guī)的顧問制。在此情形下，形式化意謂著寄希望于沒有經(jīng)驗的顧問。形式化提示要在如何指導與監(jiān)督顧問的效力上訓練人們。在過程或技術的最初部署之后，培訓仍然是一個問題Abbott97，Williams98。當人員變動時，培訓所增加的需要可能不會被充分地認識。顧問學徒制能充分地解決這一問題，但是除非能謹慎地加以監(jiān)督，否則不能設想會有滿意的結(jié)果。管理上的培訓是特別重要的，因為低下的管理會削弱一個好的團隊。那些因其技術技能而被提拔到管理層的人，將不得不重新學習包括人際關系在的一套新的技能Mogilensky94, Curtis95,Weinberg94。軟件工程管理的部分論題確實是風險管理。感覺上，CM

24、M就是關于管理風險的。我們致力于確立穩(wěn)定的需求，以便能有效地實施計劃和管理，但商業(yè)環(huán)境總在迅急而紊亂地變化著。我們嘗試在軟件那混沌的大海里建造秩序的孤島，但是秩序和混沌都自有其位置。Wheatley建議，“為了生存，開放系統(tǒng)維持在一非平衡狀態(tài)，保持系統(tǒng)均衡以便它能改變和成長?！盬heatley92, page 78盡管我們能確立幫助我們管理混沌世界里的風險的過程，我們也需要變化和成長。這意味著你應該使用一個增量的或進化的生存周期。如果你想重心集中到風險管理上，螺旋模型將是首選的生存周期模型。如果重心集中在籠絡客戶上，可能快速原型法或接合應用設計更好一些。少數(shù)長期項目對穩(wěn)定環(huán)境的奢必要的，對其瀑

25、布生存周期將是首選可能它仍是最普遍通用的生存周期。注意，無論如何，對于小項目，瀑布生存周期都會是一個極佳的選擇。成功的過程定義和改進的頭號因素是“全程計劃（planfulness）”Curtis96。計劃是每一個主要軟件過程都需要的，但不外乎綁定合理的判斷、由組織決定什幺是“主要的”以與怎樣包裝計劃。一個計劃可以駐留在幾個不同的工件或被植入一個大計劃當中。即使你可以對最好的同行評審有爭議，但簡單的事實是同行評審帶來的好處遠遠超出了其成本。數(shù)據(jù)表明一些檢測表格應該是慣用的Ackerman89，但任何學院式或嚴格的評審表格，諸如結(jié)構化預排，都附加了重要價值。不幸地，認可同行評審并不意味著我們在系統(tǒng)

26、地做著這件事。我們需要“走在路上”，而不僅僅是“說在嘴上”。這對技術人員來說是很大的挫折，他們不理解CMM所強調(diào)的管理，然而糟糕的管理會導致放棄好的工程實踐，比如同行評審。另外還有其它被確定為是小組織和小項目的問題，Paquin Paquin98 認定了下面的5個：·評估·工程焦點·文檔·需求功能· 成熟度提問單我們沒有討論等級2的項目焦點對小組織構成的挑戰(zhàn)。軟件過程改進包括了那些對小項目而言是過度的開銷。一些勸告從組織化觀點來攻擊恰似混合了等級2和等級3而又的確不失為合理途徑的小項目的過程改進Comer98，Paquin98。CMM本就是為任

27、何規(guī)模的組織或項目而考慮的Paulk96。盡管無須過程焦點一個組織也能達到等級2，但極其高效的組織化學習的策略將成為減少項目開銷的組織資產(chǎn)的一個重點。同時，必須認識到項目等級的改變可能會形成多半是基于正當利害關系的阻力，而且探察阻力時需要考慮組織進行學習過程的那部分。需求功能是一個問題，因為比起人來可能有更多的CMM功能。這個問題是做為技術或角色的映像來討論的。成熟度提問單因使用CMM技術而成為關注焦點，它可能在填寫的過程中被搞亂。以組織的技術來表達提問單，甚至對于非正式的評估與度量也是很需要的先導。AbbottAbbott97指明了對于小組織的軟件過程改進的6個關鍵：· 高層管理的

28、支持·正確的用人原則·將項目管理的法則應用到過程改進·與ISO 9001的集成· 來自過程改進顧問的協(xié)助· 聚焦在提供項目上與商業(yè)上的價值如果將好的項目管理應用到軟件項目中是確保成功的最佳途徑，那幺應該象對待其它任何項目一樣來對待過程改進就同樣是正確的。ISO 9001是在大組織里比小組織里使用更頻繁的一個評估版本，因而Abbott也有興趣針對他的小公司指出這一點。Brodman和JohnsonJohnson98認為針對小組織/小項目的挑戰(zhàn)有7種：· 處理需求·生成文檔·管理項目·分配資源·度量

29、過程· 促導評審·提供培訓Brodman和Johnson開發(fā)了一個針對小型商業(yè)、組織和項目的CMM剪裁版本Johnson96, Johnson97, Brodman94。盡管如此，大多數(shù)CMM的關鍵實踐還是被剪裁到了LOGOS剪裁版CMM里，變化體現(xiàn)在：· 已存實踐的凈化·明顯的夸·選擇性實踐的介紹(特出地作為例子)· 伴隨小商業(yè)/小組織/小項目的結(jié)構與資源的實踐調(diào)整因此針對小組織而剪裁CMM的相關改變是可以根本不予考慮的。4. 濫用CMM 正確使用CMM意味著要平衡相互沖突的目標?；贑MM的評估要求運用專業(yè)性的判斷。盡管如此，CMM在做出這些判斷以與消除對一個明確的、反復的、非設計工作特有的過程的主觀臆斷等方面都提供了大量的指導。CMM有時作為一整套過程需求被提與，但它不能有任何含有“將要”(shall)的語句。這就是在核對（子）實踐一致性時造成CMM濫用的原因。有些是勉強地、無能地去解釋、剪裁或應用判斷力。這是易于委派到關鍵實踐的，但卻愚笨透頂。此種蠢