產品經理應該了解的CMMI模型

5 評論 20478 瀏覽 42 收藏 21 分鐘

編輯導讀:產品經理學習CMMI,一方面是學習CMMI解決軟件問題的方法論,另一方面是了解主流的軟件開發流程,方便協調產品和項目開發。本文作者從CMMI的基本概念出發,對CMMI的級別和發展現狀展開了詳細的介紹,與大家分享,希望通過此文能夠加深你對CMMI的了解。

01 基本概念

1.1 過程改進

在軟件開發中,約束軟件項目的三個要素是質量、進度和成本,被稱為軟件開發鐵三角,軟件開發總是在這三個要素中妥協平衡,不時要抉擇保哪個犧牲哪個,不斷在刀尖上跳舞。而決定質量的要素又有三個:人、過程和技術,其中CMMI主要關注過程的改進。

因為CMMI有一個基本的假設前提:產品的質量很大程度上受影響于所使用的開放與維護過程的質量。所以為了改進產品質量,需要改進過程質量,稱為過程改進。

1.2 CMMI的定義

  • CMMI, Capability Maturity Model Integration,能力成熟度模型集成。
  • CMMI是美國國防部發起并資助的一個項目,由卡內基梅隆大學軟件工程研究所(SEI)開發。
  • CMMI是一種過程改進模型。
  • CMMI是業界過程改進的最佳實踐集合。

CMMI關注于改進組織內部的過程,描述了從隨意、不成熟的過程到提高了質量與有效性的、有秩序、成熟的過程的演進道路。

1.3 CMMI模型

CMMI 1.3分為三種模型:CMMI-DEV開發模型(應用最廣)、CMMI-SVC服務模型和CMMI-ACQ采購模型。它們有公用的一些過程域,也有特有的一些過程域。

CMMI的最新版本為2.0,但相關資料非常少,官網購買CMMI-DEV 2.0指南需要150美元。

1.4 過程域PA

CMMI-DEV-v1.3為例,包含22個PA,分為過程管理類、項目管理類、工程類和支持類4類:

  1. 過程管理5個PA:OPD組織級過程定義、OPF組織級過程關注、OPM組織級績效管理、OPP組織級過程性能、OT組織級培訓。
  2. 項目管理7個PA:IPM集成項目管理、PMC項目監督與控制、PP項目計劃、QPM量化項目管理、REQM需求管理、RSKM風險管理、SAM供應商協議管理。
  3. 工程管理5個PA:PI產品集成、RD需求開發、TS技術解決方案、VAL確認、VER驗證。
  4. 支持類5個PA:CAR原因分析與解決、CM配置管理、DAR決策分析與解決、MA度量與分析、PPQA過程與產品質量保證。

02 CMMI級別

即CMMI成熟度級別。CMMI把開發組織的成熟度分為1-5級,每一級是一個層次,作為繼續過程改進的基礎。其中1-3級為低成熟度級別,4-5級為高成熟度級別,所以4級是一個門檻。

2.1 CMMI 1級

CMMI 1級沒有標準,過程通常是隨意且混亂的,常超出預算。他們的成功依賴于組織內人員的能力與英雄主義。CMMI 1級組織的特征是具有過度承諾的傾向,他們在危機情況下會舍棄他們的過程,而且沒有能力去復制他們的成功。CMMI 1級又叫初始級,是不需要認證的。

以一次團隊聚餐為例:你被主管任命為團建組織者,現在有1000元經費,要求你組織一次團隊聚餐活動。

CMMI 1級水平相當于:沒有任何策劃,下班的時候口頭通知大家去江南大院聚餐。大家一哄而去,現場點菜大吃一頓。

存在大量風險:可能有人缺席,可能訂不到包廂,可能菜不合胃口,可能經費超支等等。

2.2 CMMI 2級

CMMI 2級已經有基本的項目管理,確保其過程按照方針得到計劃與執行。國內最早參與CMM認證(CMMI的前身)的公司,有認證CMM 2級,現在基本沒有了,至少從CMMI 3級開始起步。

還是以一次團隊聚餐為例,CMMI 2級水平相當于:實施了項目管理,做了項目計劃PP、度量分析MA、需求管理REQM、采購管理SAM、配置管理CM、產品和過程質量保證PPQA和項目監控PMC。

  • PP:大家什么時候有空?
  • MA:統計出席人數。
  • REQM:預定菜單,控制經費。
  • SAM:是否自帶酒水?
  • CM:整個策劃方案評審并歸檔。
  • PPQA:找一個人來監督計劃實施。
  • PMC:跟蹤大家出席的情況。

得到的結果:大家能夠吃得滿意而且費用不超支嗎?主管滿意嗎?

不一定,還遺忘了什么?等等看CMMI 3級是怎么做的。

2.3 CMMI 3級

CMMI 3級時,過程得到清晰的說明與理解,并標準化為組織級流程。項目根據裁剪指南,通過對組織的標準過程集進行裁剪來建立項目級過程。

仍然以一次團隊聚餐為例,CMMI 3級水平相當于:除了有CMMI 2級的項目管理,還實施了需求開發RD、確認VAL、風險管理RSKM、需求驗證VER、技術方案TS、組織過程定義OPD、組織過程焦點OPF和組織級培訓OT。

  • RD:需求調研“大家想吃什么?”
  • VAL:利用問卷調查App做了選菜的投票確認。
  • RSKM:提前打電話預定包廂。
  • VER:聚餐過程中利用問卷調查App收集反饋意見,觀察菜品的殘余程度。
  • TS:聚餐活動完成后總結問題,研討解決方案。
  • OPD:經過長期活動積累,輸出《吃喝玩樂一紙禪》活動指南。
  • OPF:發布團建活動PCB(過程能力基線),并確定未來一年的改進重點。
  • OT:新組織這上崗前先學習《吃喝玩樂一紙禪》。

備注:舉例并不覆蓋當前級別所有的PA。

2.4 CMMI 4級

CMMI 4級時,組織與項目建立了質量與過程性能的量化目標并將其用作管理項目的準則。CMMI 3級與CMMI 4級的關鍵區別在于對過程性能的可預測性。

CMMI 4級時,項目績效與選定的子過程的性能得以使用統計與其他量化技術進行控制,基于對細粒度的過程數據的統計分析進行預測。

和吃飯杠上了,繼續以一次團隊聚餐為例,CMMI 4級水平相當于:除了有CMMI 2級的項目管理和CMMI 3級的過程標準化,還實施了組織過程性能OPP和量化項目管理QPM。從CMMI 3級開始,感覺活動組織成功率提高了,大家比以前滿意了,但沒有具體的數字說明。

  • OPP:根據收集的大量歷史數據(網上公開點評數據,本公司的歷史聚餐數據等)和組織改進焦點(本團隊歷次聚餐的滿意度調查意見),建立了本團隊的過程性能模型——“團隊聚餐量化管理模型”。
  • QPM:具體到本次聚餐,運用“團隊聚餐量化管理模型”,輸入參數經費、人員及其他要求,預測出本次聚餐獲得的成功率(滿意度)將低于8成,模型給出推薦選擇方案:增加預算。經過向主管申請增加預算500元,獲得通過。調整輸入參數經費,得到新的成功率9成,可以按方案執行了。

到了CMMI4級,感覺一切盡在掌握,成敗在策劃中已確定。實話說,這是一種錯覺。

2.5 CMMI 5級

CMMI 5級時,組織基于對其業務目標和績效的需要,不斷改進其過程。組織使用量化的方法來理解過程中固有的偏差與過程結果的原因。CMMI 5級關注于通過增量式的與創新式的過程與技術改進,不斷地改進過程性能。

最后一次說吃飯了,仍然以一次團隊聚餐為例,CMMI 5級水平相當于:除了有CMMI 2級的項目管理、CMMI 3級的過程標準化和CMMI 4級的量化項目管理,還實施了組織績效管理OPM和原因分析與解決CAR。

  • OPM:定下組織新的績效目標——提升滿意度10%。
  • CAR:發現A同學組織活動的滿意度比基線高15%,調查分析后得知原因:A每次組織活動都會組織抽獎,并事先調查大家需要什么。把A的做法寫入流程,提升基線能力。

小結

從CMMI 1級到CMMI 5級,成熟度級別的提升帶來兩個變化:風險和浪費減少,生產率和質量提升。從CMMI 1級到CMMI 3級,關注點從個人到項目團隊,再到組織;從CMMI 3級到CMMI 5級,關注點從組織到項目團隊,再回歸個人。

03 CMMI發展和現狀

3.1 CMM起源

1960s開始,“軟件危機”出現,美國軍方項目受此影響嚴重。

1983年,美國審計局的研究表明只有3%軟件交付后可以使用,49%扔掉了,48%使用前需要返工。因此,美國國防部委托SEI研究解決方案,用于評估軍方軟件供應商的能力。

SEI對軟件危機的研究表明,軟件危機的主要問題不是技術,而是過程管理。

漢弗萊(Humphrey)借鑒了全面質量管理TQM的思想(還有休哈特、戴明、朱蘭、克勞士比等質量大師的思想),提出了能力成熟度模型CMM。

3.2 CMMI演化歷程

從CMM到CMMI

  • 1991年,SEI發布了第1個能力成熟度模型CMM 1.0,這是CMM的起源。CMM最初是為了解決軟件問題的,因此又叫SW-CMM,以區別后來出現的其他能力成熟度模型。
    CMM 1.0發布后很快在軟件界獲得了巨大的成功。SW-CMM模型的成功促使其他學科也相繼開發類似的過程改進模型:IPD-CMM集成產品開發能力成熟度模型,SECM系統工程能力成熟度模型,P-CMM人力資源能力成熟度模型,SA-CMM軟件采購能力成熟度模型。
  • 1993年,SEI發布CMM 1.1。至此,CMM就發布過2個正式版本。
  • 1997年,SEI準備發布CMM 2.0,被美國國防部叫停,因為有一個更緊急的項目CMMI等著SEI。
    CMMI項目產生的緣由是因為同一個組織采用多個CMM模型時,產生了新問題:多個CMM模型之間很可能會引起沖突和混淆。CMMI項目就是為了解決多個CMM模型之間的協調而產生的。
  • 2000年,SEI發布CMMI 1.02。這個CMMI 1.02包含了CMMI-SE/SW/IPPD三個模型,是個試用和推廣版本,其中SE來自SECM、SW來自SW-CMM、IPPD來自IPD-CMM。

CMMI演化歷程

  • 2001年11月,SEI發布CMMI 1.1(CMMI-SE/SW/IPPD/SS),這是一個正式版本。多了一個SS模型供選擇,來自SA-CMM。
  • 2003年,SEI宣布停止SW-CMM模型的維護。SEI并沒有廢除SW-CMM模型,而是停止了SW-CMM評估,改以CMMI評估代替。
  • 2006年,SEI發布CMMI 1.2。這個版本分為開發、服務與采購三種模型,使用開發模型取代CMM 1.1的軟件工程與系統工程領域。
  • 2010年11月,SEI發布CMMI 1.3。這個版本更加開放,把敏捷最佳實踐也納入規范框架(沒辦法,敏捷太火了)。
  • 2018年3月,SEI發布CMMI 2.0。這是當前的最新版本。

從CMMI的演化歷程我們可以看出,CMMI同樣關注自身的持續改進。

3.3 CMMI認證

國內學習和實踐CMM/CMMI已有二十多年歷史了,是CMMI最活躍的陣地(沒有之一)。SEI數據顯示,中國通過的CMMI評估總數已連續十年居世界第一。

2012年9月CMMI官網數據:全球通過CMMI評估的組織約5000家,中國2128家約占4成(其中4級50家,5級53家),美國1416家(其中4級5家,5級73家),印度581家(其中4級4家,5級139家),為TOP3國家。

據CMMI研究院2018年年報數據,2018年度一共有3049個評估項目,中國占了其中的65%。

2020年9月20日CMMI官網數據:中國已經通過CMMI認證(3年有效期內)的組織6509家(5級912家,4級70家,3級5511家,2級16家),不管是總數量還是高成熟度級別的數量都遠超過美國和印度。

國人參加CMMI認證的熱情令人咂舌!應了一句話——咱中國人不差錢。為什么會這樣?與政府鼓勵有很大關系。國務院2000年6月發表的《鼓勵軟件產業和集成電路產業發展的若干政策》第17條規定“對軟件出口型企業CMM認證費用予以適當支持”。

多年以前北上廣深、杭州、蘇州等地政府就對CMMI 3-5級分別獎勵30、40、50萬(以抵扣稅收方式),成都等地獎勵70%退稅抵扣,湖南、沈陽、煙臺等地獎勵50萬。現在,各地政府仍然對CMMI認證給予稅收獎勵,只是對CMMI 3級這樣的低級別已經沒有獎勵或獎勵較少了。

通過CMMI 3級認證的公司和通過CMMI 5級認證的公司有很大差別嗎?

實際上沒有多大差別,能過3級的公司,基本上就能過5級。我任職過兩家CMMI 5級的公司,第一家公司華三通信,確實在認真做過程改進,2009年通過CMMI 3級(親歷),2013年通過CMMI 4級(親歷),2020年通過CMMI 5級。第2家公司(名字就隱了),2017年7月通過CMMI 3級(也就只有這個水平),很快2019年1月跳過CMMI 4級馬不停蹄通過了CMMI 5級認證。

為什么能過?因為評估師的目標和公司的目標是一致的,都是要通過認證評估,否則評估師拿不到大部分認證費用(一般都是簽包過合同)。按CMMI的規定,評估師和咨詢師不能是同一個人,但是國內的情況,有幾個是這樣執行的?反正,我遇到的都是即當教練又當裁判,沒有碰到認證不通過的情況。

3.4 過程改進的目的

CMMI過程改進的目的,就是寫在CMMI文檔封面的一句話:

Improving processes for developing better products and services.

為開發更好的產品與服務而改進過程。

過程改進應該為了商業目標,即為了幫助業務而改進,而不是為了改進而改進。

更好、更快、更經濟地交付產品與服務,是所有公司夢寐以求的愿望,也是CMMI的愿望。CMMI迎合了很多組織的期望:生產率的增長、質量的提升、開發周期的縮短,并且計劃與預算變得更準確和可預測,所以獲得了巨大的商業成功。

3.5 CMMI的基本思想

1)過程改進不可能一蹴而就,而是一個長期的,甚至永無止境的過程。

2)持續改進——PDCA

3)流程也有保鮮期——定期審視、更新流程。

4)開放、學習的心態。

3.6 CMMI和敏捷

CMMI更傾向于把人看成是產品開發生產線上的螺絲釘,是可以替換的,大部分工序既不需要高超的技能、也不需要多面手。CMMI的方法更適合制造業和傳統IT行業,對個人的技能要求不高,對個人的紀律要求較高,適合大兵團作戰,適合暴兵的人海戰術。一個方陣過去,碾壓一切障礙,不會為損失小兵停下腳步,甚至不會為更換統帥停下腳步。

而現在流行的敏捷更傾向于把人看成是單打獨斗或小團隊作戰的特種兵,強調個人和小團隊的能力,既需要高超的技能、也希望成員都是多面手。敏捷的方法更適合互聯網行業,對個人的要求更高,適合小團隊作戰,適合重點突破斬首戰術,適合敵后滲透。

CMMI和敏捷兩種模型本身無所謂孰優孰劣,各有適合的行業和場景。當然,相比而言,CMMI對個人的要求更低一些,即使是平庸的人員在CMMI嚴密的流程管理下,也能夠做出合格的產品。

所以,那些逃離CMMI擁抱敏捷的個人或團隊,如果不是行業轉換的話,在CMMI流程下做不好的個人和團隊,在敏捷流程下很大可能更做不好,不關于流程,只關乎人。笨蛋就是笨蛋,難道換了套衣服就變聰明了嗎?只有那些在CMMI流程下能成功的個人和團隊,在敏捷流程下將延續成功的戰績,甚至釋放潛力,更加成功。

CMMI是持續改進的模型,在V1.3版本吸收了敏捷實踐。從這個意義上理解,敏捷與CMMI并不是對立或矛盾的。

參考資料

  • [1] CMMI-DEV 1.3
  • [2] CMMI認證數據查詢:https://sas.cmmiinstitute.com/pars/pars.aspx

 

作者:叔寶,微信公眾號“叔寶說”,專注產品設計和PPT設計。

本文由 @叔寶 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 講的很好??

    回復
  2. CMMI不太適用互聯網行業,倒適合工業和制造業

    來自北京 回復
    1. 基本上是這樣的

      回復
  3. 寫的很贊哦!
    【特別推薦】精選6本產品經理電子書PDF高清
    鏈接:https://pan.baidu.com/s/1xzmhSsrePIeRQcn0W9tvjw
    提取碼:tdnb

    來自上海 回復
    1. 謝謝!

      來自浙江 回復