我所親身經歷的CMMI3 [問題點數：20分，結帖人outer2000]--轉載

很榮幸，做爲某公司軟件部門的軟件項目經理，親身經歷了CMMI3，如下就把整個改進過程，用本身的親身體會，詳述以下，文中一些觀點與見解不免帶有我的感情，還請各位酌情參考。
公司狀況簡單介紹下，由於是爲某大型上市公司提供技術支撐，因此總體來講公司利潤豐厚，更是由於與大型上市公司錯綜複雜的關係，很容易獲得一些大的IT項目建設與維護。通常來講，作CMMI3認證的企業，大都不愁項目來源和利潤。
大概是從2006年下半年開始作這個事情的吧，當時要先選擇諮詢公司，經過招標，最後肯定了某家信譽不錯的諮詢公司，聽說有多名主任評估師在該公司任職。說明下，參加過9000的公司可能都比較明白，這個CMMI3的認證過程與9000相似，最後都須要一個證書，CMMI呢就須要主任評估師簽發，並且到美國的總部備案。
通常的認證過程是先找一家諮詢公司，在該公司指導下進行相關的準備，而後準備好一些軟件項目，最後再由該公司出面，動用主任評估師，對項目是否符合CMMI要求進行評估，固然經過後才能搞定。
持續發佈.敬請期待

不得不說，公司爲了搞CMMI，剛開始就投入了巨大的熱情和人力，記得那時候俺也成爲了EPG的成員之一，聽了很多諮詢師關於CMMI的介紹以及相關過程域的培訓。公司抽調了多名項目經理和業務骨幹，組成了EPG，也就是公司的軟件過程改進小組，負責整個CMMI的評估準備工做。這個過程域有必要解釋下，說簡單點，就是軟件項目的某個方面，好比管理，好比配置管理，又好比需求等吧，大體上分了四個部分，爲管理類的，組織類的，軟件工程類的和支持類，整體看來，仍是比較全面。
若是各位大大對PMBOK有所瞭解的話，就會發現CMMI比PMBOK的九個項目管理知識領域增長了軟件工程方面的東西，其餘的仍是有不少相同之處。
EPG小組剛開始的工做就是要創建組織，也就是小組內按咱們開發，設計，測試來分不一樣的角色。咱們定的角色包括EPG的小組長，EPG的配置管理員，EPG的質量保證員，還有CCB等機構。這個CCB叫變動控制委員會，說白了就是軟件項目的一些重大決定要由CCB來決定，而不是項目經理啦。

公司呢專門開了一個CMMI啓動大會，弄得挺正式，公司相關領導都出面，諮詢公司的領導也來了，洋洋灑灑把把CMMI的必要性和帶來的收益說的神乎其神，恩，那時候，俺看諮詢師的眼神都是那樣的…..景仰。
諮詢師大概花了兩個星期左右吧，才把CMMI3的20多個過程域給咱們這些CMMI菜鳥培訓了一遍，當時一個感受：暈啊。培訓完，諮詢師就要咱們開始幹了，只以爲CMMI好複雜，簡直是無從着手。這時候EPG小組的人開始從網上找一些資料，一些其餘公司準備的文件模板。俺也找了一套，很不錯，如今公司用的就有。
諮詢師這時候也發覺了，對咱們的指望彷佛高了點，私下說，應該過CMMI2可能比較合適。看咱們實在不知道作什麼，就先讓咱們準備一個組織級別的WORD模板，還有縮略表等，挺多的，也記不清楚了。還讓咱們把軟件過程按標準的瀑布模型進行拆分，越細越好。

迷茫中,CMMI3起航了...
培訓完,EPG也成立了,這邊EPG開始按照諮詢師的要求,準備拆分軟件過程,另外一邊,諮詢師又開始了另外一項重要的工做，那就是對公司的整個軟件流程進行診斷,說白了，就是找軟件過程當中的各個角色進行座談,包括項目經理,普通開發,美工,部門領導,人力資源部分,公司領導等等..問的問題很詳細,舉個例子,問開發人員的時候問到了一天能寫多少行代碼,問測試的時候問平均千行的BUG率,這個診斷過程大概有一個星期吧..諮詢公司最後出了一個診斷報告,不過惋惜的是，這個報告俺只看到了一部分,大體是說公司的軟件過程仍是不錯的,固然也須要進一步的改進..云云..
不提那邊診斷的事情,這只是必要的一個過程，並不影響咱們EPG的工做,仍是回到EPG的工做上來.

會議連着會議,不記得那時候開了多少會,總之成天彷佛都在和別人爭論着...EPG將公司的某會議室整個包了下來，按照標準的瀑布模型,從最開始的項目招標,可研一直到項目的驗收,售後維護全理了一遍.如今回頭想一想,這個過程整個是一個學習的過程,每每覺得很簡單的過程,可仍有那麼多的迷惑和未知.舉個例子,需求的過程,不是簡單的與用戶溝通,記錄,而是要有確認,要注意需求的可測試,完整..各類特性,還要進行需求的跟蹤,橫向和縱向等等...這個過程一方面結合公司的實際,另外一方面還要符合CMMI的要求,難啊.
從一開頭,EPG就是一個爭吵的局面,前面說了，公司的位置比較特殊,與客戶有複雜的關係,好比說能夠不籤合同就開工,或者一個項目幹N多年也沒完,這麼說吧,咱們公司簡直就是客戶的親戚,想怎麼來，就怎麼來.這對EPG分析軟件過程產生了不可估計的影響...

看來關心此方面內容的大大很多,俺也就再寫一段,給你們提提神.
其實CMMI自己也有兩種模型,或者不用模型這兩個字了,這個詞彙聽着彆扭,簡單說就是達到CMMI標準的方法有兩種,其中一種呢,就是把CMMI的20多個過程域按1-5級劃分,每一級都增長一些過程域,等到了5級就全知足了;另一種不是這樣,是按先實現組織方面的過程域,而後是管理方面的,而後是軟件工程方面的，而後是支持的...道理同樣，總之到了5級所有支持.
用軟件生命週期模型來比喻這個可能比較合適,前一種呢就是疊代模型,1-5級每一個級別均可以運行,只不過功能逐漸知足...然後一種就是完整的瀑布模型,先從需求作起..最後才能看到一個完整的系統.
我所在的公司選擇的是分級的方法來實現CMMI,也就是前一種方法,把CMMI3級所包含的18個過程域一塊兒都實現.

這幾天要CMMI3評估了..緊張啊,不過也讓我更深入的體會到之前所作的工做..不少，可是真的對評估沒什麼用.
上回說到,EPG進行軟件過程的分析,因爲公司環境特殊,形成了不少困難,可是工做還得要開展,是不?固然，公司正常的項目還須要開展,對不?一下抽了這麼多骨幹,對正常的項目的影響也逐漸暴露出來了...有兩個月吧,時間這時候大概到了07年初春節左右.
通過艱苦的內部鬥爭,EPG也算初步整理出一個按瀑布模型劃分的過程清單,諮詢公司根據這個過程清單,開始讓EPG整理過程清單裏中每個過程的體系文件了,這個很好理解,就是把這些細小的過程都通過定義,包括過程的輸入,輸出,過程的步驟,一些關鍵的要求等等,舉個簡單的例子,好比開周例會這個過程,就須要先準備材料,發通知,進行會議記錄,會議內容,會議紀要..等等,固然是越詳細越好，還得與公司實際結合,諮詢師當時甚至要求記錄每一個會議議題所花費的時間...
如今回頭看看,這個過程,其實就是軟件工程的一個過程,包括並符合了CMMI不少的過程域,如:需求開發,需求管理,系統解決方案等,經過這個過程,按照瀑布模型定義了一個詳細的軟件過程.

很不幸,在這麼一個關鍵的階段，本人被EPG無情的拋棄了,也不是被拋棄,春節後項目正常的工做愈來愈多,EPG的會議常常沒法參加,記得那時我所負責的過程是可研的過程,包括準備PPT啦,準備技術建議書,與用戶講解系統方案,投標前準備等等..因爲時間的確不夠用,部門經理決定，將大部分項目經理從新還回到項目中,只保留了幾個有限的人手,EPG的工做,也就正式進入了持久戰.

從07年4月份開始,本人正式脫離了公司的EPG組織,這段時間因爲沒有親自參與EPG的工做，一些細節只能經過EPG的其餘同事來得到了.期間EPG建立了公司的CMMI站點,按照組織,管理,工程，支持分類,把所有的過程都編寫好過程文件,並陸續發佈到公司的站點,接受熱愛此工做的程序員,測試，開發等各角色的建議.一直到07年9月份,將近有五個月的時間，EPG一直在辛勤的工做着,按照CMMI的目標和實踐,整理咱們的過程體系文件,真的很是辛苦.
要知道,過程體系文件只是一個工做，還有要建立各類MODEL,好比需求說明書,設計說明書..好比項目計劃MODEL,配置管理計劃，質量保證計劃..好比評審單,過程檢查單,會議紀要,我的週報..還要準備組織級別的一些規範,目標如編碼規範,測試規範,工做環境規定,風險清單,資源清單,技能清單..還要進行公司內的CMMI培訓..培訓教材,不少，很複雜.

這些文件大致上分爲四類,一種是規範和標準方面的,如編碼規範,測試規範,角色職責等;一種是過程文件，告訴咱們怎麼執行過程;一種是指南類的,幫助咱們執行過程，好比裁減指南,生命週期模型說明,估算指南等;還有一種是各類的審查單,任務單等,通常配合過程文件中使用的模板.這四類文件組成了整個的CMMI文檔體系,粗略算下來，總共應該有2百個左右吧.

各位大大應該都比較喜歡看書，要是一本200多頁的書，大概會看多長時間?
呵呵，沒錯，下面我要說說這些文件怎麼使用的問題.這200多個文件要真正的應用的具體的項目中,恐怕產生的實際數量文件會比200多幾倍,管理起來也是一個大的問題,後面我會說配置管理方面，如今先說說培訓.
把這些文件一股腦交給項目經理,實際的去執行...感受有些不現實,各位大大以爲呢?我所在的公司是這麼作的,就是不斷的培訓,考試...再培訓,再考試...

大概的統計下，爲了在技術開發部門推廣CMMI,公司組織的培訓應該超過3次,各個角色[項目經理,QA,CM,開發,測試],全員的培訓,因爲俺早期參加了EPG,這些培訓的考試應付仍是比較輕鬆的..記得有次考試竟然得分比EPG小組的某些人還高,呵呵,臭美了好幾天.
一般來講,QA與CM的工做對大部分軟件公司來講是一個的弱點,我所在的公司也不例外,配置工具也就是簽入和簽出用得最多,至於QA則更是基本上不設置,本人也重點學了學相關的兩個過程域CM和PPQA,老實說,本人並非科班出身,大學學機械,工做後進工廠,跳槽幹了兩年市場...才轉到開發的.自認爲經歷仍是比較複雜,呵呵,別拿磚頭丟我啊..
不知道有沒有大大喜歡下圍棋,韓國,有個比較牛的人物..不是那小李飛刀,是一個叫劉昌赫的，也是半路出家,原來是業餘選手..雖然很猛但有時會下一些很低級錯誤的棋...道理差很少吧,本人對QA與配置管理能夠說是半知半解..也出了很多洋相.
學過CM與PPQA後,總體感受工做嚴謹了不少,就象..流氓學武術啦,哈哈.

仔細想了想仍是說兩句這兩個過程域的感覺吧,CM,就是配置管理,講了先要你弄一個配置管理計劃，前提固然是配置管理員幹,項目經理不用弄...並且不容許兼任.固然這個計劃和總體的項目計劃要有對應,好比項目計劃1月1日作完需求,那配置管理計劃也應該1月1往後幾天弄個什麼BASELINE基線吧.配置管理計劃有個日程表,里程碑與項目計劃對應上,啥時候該作配置審計...就是看看Y的項目組成員是否是按計劃把輸出物都籤進來的..這叫物理審計..還有功能審計,就要看文件的內容是否是符合要求了..聽說這個很難,還好，俺不是CM.
做爲CM的配置管理計劃，還要識別配置項..真難聽，說白了就是那些比較重要的輸出物文件如需求說明書什麼的,一個基線..就是這些輸出物某個版本的集合.好比項目需求完了，通過技術評審..就是開個小會兒,肯定需求完啦,那這個需求說明書就要弄一個BASELINE,可就不能隨便改了.有了基線的意思,俺的理解就是不能隨便變動啦,要想變得CCB的批准才能夠..權利大着呢..隨着項目的進展,這些配置項會愈來愈多..固然不是全部的輸出物都要作爲配置項,不然..CM真的不用作了.
剛開始的時候,某CM竟然把我的週報也弄配置項裏啦..哈哈

再說兩句配置管理...說下配置庫與配置項,基線的關係..通常咱們弄三個配置庫,開發庫..誰均可以隨便籤入簽出..受控庫,通常CM本身有權利..BASELINE庫,基本上不多變化的;說配置管理太多了，有點口乾舌燥.....不說了,想學本身看書去.
QA也就是質量保證員,公司弄9000的都曉得，也有這麼個角色,惋惜的是，9000與CMMI比起來,QA的角色差異仍是很大的.

我也參加過CMMI3和CMMI4的這個評估，我當時仍是一個小小的測試人員，可是由於開發的時候很是注重流程，反而給吸取進EPG了

並且也是從零開始一直就參加這些培訓

學習一下CMMI流程是很是有用處的

這裏面有些很死板的規定，看起來很繁瑣，其實堅持下來最後能看到很是好的做用，這點深有體會

可是能作全也不是那麼容易的

謝謝樓上的朋友，本身連續只能發三次，再發說發言太快，這經歷還就寫不下去了.
前幾天說了CM,原本想說QA,看樓上的朋友說測試,也稍微說幾句.有兩個過程域主要講這個,俺是沒學好，記得叫驗證和確認,諮詢師講了半天也沒聽明白，卻是EPG有個簡單的說法,驗證就是測試,確認就是評審.
回過來講QA,怎麼都以爲QA象是EPG在項目安排的內奸和臥底,不光有事情能夠直接向高層彙報,還要檢查項目的過程是否是按CMMI寫的執行了，一些輸出物與CMMI的MODEL是否是吻合等...還有跟蹤一些評審的問題和項目中的其餘問題..
說這些真的很枯燥,但是不說清楚,後面的故事就沒辦法開展啦..回過頭來講說俺的項目,9月中吧,參加了甲方的招標,天然,也是走走過場,雖然中標是必定的，但標書也不能馬虎,該講解PPT也不能省略,合同還得簽訂，不是?到10月份吧,肯定了中標,而後是弄合同...俺這忙裏忙外,殊不知一場"陰謀"正在悄然降臨...CMMI的魔爪終於成型了，向修真小說裏的那樣，練成內丹要出山,而我所負責的這個項目,就成爲了檢驗CMMI的:實驗品.

上面說到了EPG修煉出內丹,不過要知道是修煉的魔門功法仍是仙家正宗練氣之術,還得靠事實檢驗,弄個把項目操練一翻,天然有個分曉.
做爲項目經理,在向部門經理申請到並不充足的人手後,開始了項目的漫漫征程.公司早在2003年左右就經過了ISO9000,對軟件過程仍是有一個基本過程要求的,好比需求，設計,測試,開發..等階段的定義也算是清晰.2007年10月下旬,項目順利啓動,進入整理需求階段.
今天思路比較混亂,CMMI3的正式評估正在進行當中...

EPG在整理這些過程文件當中,諮詢師大概每月都會到公司進行現場指導,就一些具體的作法與EPG進行商討,說好聽點是根據本公司的實際進行改進和修正,說白了就是COPY一套其餘公司較好的流程,而後把不適應的地方裁掉...這純粹是我的見解,EPG看到這些,恐怕會殺了我...
還好，這段時間諮詢師正在就EPG的工做成果進行全面的審覈,個人項目也循序漸進進入了設計階段.其實,CMMI以前,公司內部也在就軟件過程進行一些改進,包括公司領導提出的開發與設計分離等方面,軟件部門受此影響,也劃分了開發\需求設計\測試等部分,而個人項目也受到了必定的影響,初期只安排了需求與設計人員.2007年末吧,咱們項目設計完成,CMMI也終於發佈了第一個版本.

記得應該是2008年的1月初,CMMI體系的正式文件發佈,相似9000的發佈,公司還搞了一個發佈會,就此,EPG的工做進入了一個全新的階段.按照CMMI的要求,發佈後，要求至少有三個項目徹底實施才能參與評審,根據公司的項目狀況，呵呵，天然也爲了經過CMMI的認證,選擇了三個項目搞試點.
三個項目中有一個規模較大,其他兩個規模比較小,這其中不幸固然包括本人所負責的,每一個項目組EPG都派出一人作專門的指導,全程參與項目的過程.俺的項目到2008年初編碼都開始了...回過頭來,開始弄CMMI了...

原帖子連接：https://bbs.csdn.net/topics/280073485