01 前言

本篇文章是麥哲思科技 任老師的見解，關(guān)注任老師很久了，總覺得一些浮于紙面的理論到了任老師口中就變成了活脫脫的實踐，這里給麥哲思和任老師打個廣告...

原文鏈接：https://measures.blog.csdn.net/article/details/98940870

02 CMMI和敏捷的目標定位

? ? CMMI是用來評價組織級能力的模型，是指導組織持續(xù)進行過程改進的模型，它給出了過程改進的路線圖。

? ? 敏捷方法是用來指導解決快速高質(zhì)量交付高價值產(chǎn)品的思想與框架。

? ? 所以：

? ? 1） CMMI給出了what to do, 敏捷給出了how to do。

? ? CMMI給出了很多實踐，敏捷也給出了一些儀式，但二者的詳細程度、抽象層次不同。例如：

? ? 二者都要做計劃，CMMI要求做任務拆分，要做規(guī)模估算、工作量估算，要有進度表，要做計劃評審等。敏捷給出了迭代策劃會議的解決方法，實現(xiàn)了CMMI中EST，PLAN實踐域的實踐。

? ? 二者都要做計劃跟蹤，敏捷給出了每日站立會、迭代評審、迭代回顧會議實現(xiàn)了CMMI中MC實踐域的實踐。

? ? CMMI要做驗證與確認，敏捷要做檢視，CMMI中有VV與PR兩個實踐域，敏捷有結(jié)對編程、測試驅(qū)動的開發(fā)、迭代評審等儀式。

? ? ? what to do 與how to do 是對具體做法的不同抽象層次，how to do 可以有很多種不同的做法，敏捷實踐是其中一種。CMMI并不排斥敏捷，它只是定義了what to do。

? ? 敏捷中有價值觀、原則，在符合敏捷的價值觀與原則之下，有各種各樣的敏捷方法、敏捷儀式，敏捷價值觀與原則抽象了儀式背后的目的，是對how to do的思想的提煉，但是仍然是處在how to do的層次上。

? ? 以吃飯來舉例：

CMMI模型的鼻祖Watts Humphrey老先生是偉大的，他負責開發(fā)了CMM，還繼續(xù)開發(fā)了小組軟件過程（TSP）與個體軟件過程（PSP），試圖解決團隊級與個人級的how to do的問題，解決CMMI落地的問題。PSP給出開發(fā)人員能力提升的路線圖，包括了個人的技術(shù)能力與管理能力，TSP給出了不超過10人的團隊如何采用迭代的生命周期模型進行開發(fā)，PSP與TSP試圖解決CMMI在項目級、在個人級如何做的問題，但是它們并沒有吸收更多的敏捷元素，沒有在業(yè)內(nèi)流行開來，很是可惜。

? ? 企業(yè)可以采用CMMI+TSP+PSP搭建自己的管理體系，當然也可以采用CMMI+看板+XP+Scrum+LeSS搭建自己的管理體系。what to do 與how to do 本身并不矛盾。

? ? how to do 不能否定what to do， 比如你篤信過午不食是最正確的，但是你不能據(jù)此來否定人要吃飯。

2） CMMI側(cè)重于建立組織級的能力，大多數(shù)敏捷方法側(cè)重于團隊級的能力。

? ? CMMI最初是美國國防部為評價一個組織的開發(fā)能力而定義的模型，它是站在組織級的角度看待過程能力。它定義了高層管理者的治理職責，要求組織級要定義管理的方針、流程、裁剪指南、模版等，組織級要進行流程執(zhí)行情況的檢查，要給團隊提供資源、工具、培訓等支持，組織級要采集經(jīng)驗教訓、典型案例、改進建議、度量數(shù)據(jù)等進行持續(xù)改進，要將組織的規(guī)范固化為大家的工作習慣。

? ?? TSP是側(cè)重于建立團隊級的能力，PSP是側(cè)重于建立個人級的能力。

? ?? SCRUM，XP等敏捷方法大都是側(cè)重于構(gòu)建團隊級的能力，給出了一個小團隊的角色劃分、管理實踐與技術(shù)實踐，如果需要進行大產(chǎn)品的開發(fā)，可以采用規(guī)模化敏捷的方法，如LeSS， SAFe等。當團隊規(guī)模越大時，需要的管理活動就越多，SAFe之類的大規(guī)模敏捷框架受到的質(zhì)疑就比較多。組織級敏捷文化的形成需要借助變革管理的理論、方法來輔助Scrum, XP, LeSS, SAFe等敏捷方法構(gòu)建組織級的能力，在組織內(nèi)如果不能形成敏捷文化，敏捷不能持久。

? ? 上述這個分類圖，可以厘清各種模型、框架、標準的定位。

? ?? 沒有必要絕對的評價各種方法的誰好誰壞，只能講在某種場景下，誰最適合。

二 思想焦點

? ?? 1） 流程的重要程度。

? ?? CMMI強調(diào)通過規(guī)范的流程，將人、技術(shù)、工具集成在一起，從而產(chǎn)生好的結(jié)果。

? ? 敏捷依賴人的經(jīng)驗+做事的原則快速交付高質(zhì)量的產(chǎn)品，敏捷并不否定流程的重要，只是和個體與協(xié)同相比，不如后者重要。

? ? CMMI重視流程的重要性，但是沒有強調(diào)簡潔的流程、增值的流程、無浪費的流程更有價值！QA要對項目的合規(guī)性進行檢查，而敏捷認為非增值的合規(guī)活動是一種浪費。

? ? 在實踐中，很多項目追求合規(guī)時，往往迷失了目標，為規(guī)范而規(guī)范。而敏捷認為為了產(chǎn)生好的結(jié)果，應該靈活地配置流程，靈活的配置流程比預定義的流程更重要。

? ? 從本質(zhì)上來講，二者都是為了解決更好、更快交付的問題，但是解決問題的方式不同。這是在對待流程的認識上與實踐中，敏捷與CMMI的本質(zhì)差別。

? ? 2）文檔的重要性與多少。

? ? 敏捷宣言中明確提到：能夠工作的軟件勝過完備的文檔。不是沒有文檔，而是可以工作的軟件比文檔更重要。

? ? 敏捷中的文檔數(shù)量少，文檔內(nèi)容簡化、文檔形式靈活，編寫剛剛好的文檔即可。

? ? CMMI的每條實踐在評估時，要從制品和訪談兩個維度進行考察。

? ? CMMI并沒有要求文檔一定要有多少個，一定要包含什么內(nèi)容，一定要什么格式，一定有多么正式。

? ? 但是：

? ? ? ?? ?a） 由于CMMI內(nèi)容的完備性，需要證明某些PA是否滿足了，需要有證據(jù)。

? ? ? ?? ?b）由于實踐中大家對CMMI的誤解，很多組織過度準備了證據(jù)。

? ? 所以第1種原因造成的文檔增加與第2種原因造成的文檔增加其必要性是不同的。

? ? 敏捷認為面對面的溝通傳遞信息比文檔傳遞信息更高效。而CMMI并沒有在how to do的層級強調(diào)這一點。

? ? 需求、設計、測試用例這些工程制品無論敏捷還是CMMI都是有的，只不過在敏捷里給出了明確的建議而已，采用product backlog、 用戶故事、CRC卡片、設計草圖、測試代碼等。拿需求文檔來舉例：CMMI要求有客戶需求、產(chǎn)品需求，可以映射為敏捷中的用戶故事、用戶故事的驗收標準。CMMI要求要區(qū)分必須的需求與期望，可以映射為敏捷中的需求劃分優(yōu)先級。CMMI要求要包含接口需求與約束，要有系統(tǒng)的操作概念。接口需求與約束在敏捷中可以表現(xiàn)為技術(shù)故事或約束故事，操作概念可以映射為在制作故事地圖時梳理出來的客戶的作業(yè)流程。

? ? 計劃書、計劃跟蹤記錄這些管理制品無論是敏捷還是CMMI也是有的，只不過在敏捷里給出了明確的建議而已，采用產(chǎn)品路線圖、發(fā)布計劃、迭代計劃、任務白板、燃盡圖等。但是CMMI對計劃的內(nèi)容做了比較完備的要求，比如要有人員能力的獲取計劃（培訓計劃或人員配備招聘計劃）、資料的管理計劃、風險的管理計劃等等。而在敏捷策劃時，這些計劃是根據(jù)需要來定義的，團隊根據(jù)經(jīng)驗想到了就做，沒想到就等出了問題再去解決。

? ? 從主要的工程制品與管理制品的要求上，其實二者并沒有本質(zhì)的差別。那CMMI的文檔多在什么地方呢？

? ? ? ? ? a）文檔內(nèi)容的完備性。如上面我們所舉的項目計劃的例子。

? ? ? ?? ?b）CMMI中有支持類的PA，包含了質(zhì)量保證、配置管理、決策與解決方案、度量與分析、根因分析與解決方案，這些PA的活動都要有計劃，這些活動計劃可以是單獨的文檔，也可以是scedule中的活動，這些活動的實際執(zhí)行也要有記錄。

? ? ? ? ?c) CMMI中有組織級的過程管理類的PA，包含了組織過程焦點、組織過程定義、組織過程性能、組織級培訓、組織性能管理。這些PA的制品是敏捷方法中沒有涉及到的。

? ? 對于文檔的多少，我們需要冷靜分析：

? ? ? ??????? ?該不該有？

? ? ? ? ?????? 如果需要，完備到什么程度？

? ? CMMI說了要有某些證據(jù)，說了，讓大家聽起來覺得需要好多文檔。

? ? 敏捷沒說，沒說不代表實踐中不需要有！不能回避，不能視而不見，否則就是皇帝的新裝了。

? ? 在實踐中，可以根據(jù)文檔的價值來決定文檔的多少、表現(xiàn)形式與內(nèi)容多少：

? ??? ? a) 用戶需要的文檔必須有。

? ??? ? b) 工程類的文檔，直接輔助我們來開發(fā)產(chǎn)品的文檔，如需求，設計，測試用例等，盡量有。

? ? ??? c) 管理類的文檔，幫助團隊來開發(fā)產(chǎn)品，交付產(chǎn)品的文檔，如計劃，計劃跟蹤結(jié)果等，盡量少。

? ?? ?? d) 記錄類的文檔，只是記錄我們的工程活動與管理活動的結(jié)果的文檔，盡量無。

? ? 敏捷就是平衡靈活性與穩(wěn)定性，平衡的能力，至關(guān)重要。

? ? 3）如何應對變化？

? ? 敏捷的流程是隨需而變，是經(jīng)驗型過程控制，是在團隊級靈活變化的，是以變化應對變化，擁抱變化，不是以不變應萬變。不變的是原則，變化的是具體做法。

? ? CMMI的三級強調(diào)已定義的流程，組織級統(tǒng)一定義了流程，項目組可以裁剪，但是如果組織級的約束太多，項目組就懶得去裁剪，而是表面上合規(guī)，實際自己按自己的套路去做。當外部環(huán)境發(fā)生了改進，需要對流程修改時，需要在組織級統(tǒng)一修改流程，經(jīng)過多個作業(yè)環(huán)節(jié)的認可后才可以變更，這影響了應對變化的速度。

? ? 如果CMMI的組織級流程是一套原則+簡化的流程而不是一套完備的流程，賦予團隊更多的流程決策權(quán)力、提供更大的靈活性，是否就敏捷化了呢？這個問題值得思考。

? ? CMMI在what to do給出了實踐，但是對how to do并沒有給出融合敏捷思想的建議，這是導致大家對CMMI有誤解的原因之一。雖然在CMMI 1.3中和CMMI2.0中給出了一些在特定敏捷環(huán)境下，CMMI從what to do 到how to do的解釋說明，但是并沒有觸及根本。

三 核心理念

? ? 敏捷宣言，敏捷的12個原則以及各種敏捷方法自己的原則，構(gòu)成了敏捷的價值觀，這些是敏捷的思想理念，是敏捷的根本。

? ? CMMI推崇的價值觀，理想以及自己的原則是什么？CMMI沒有明確的喊出來！CMMI的共性實踐可以認為代表了它的一些核心理念，不是全部，它是通過實踐來描述的，沒有提煉、抽象出來。CMMI2.0推出以后，我試圖概括了CMMI的核心價值觀如下，這僅是我的理解，并非CMMI的官宣：

? ? ? ? ? ?a)商業(yè)目標驅(qū)動改進

? ? ? ? ? ?b)轉(zhuǎn)型過程實現(xiàn)目標

? ? ? ? ? ?c)定量數(shù)據(jù)量化性能

? ? ? ? ? ?d)固化習慣成為文化

? ? ? ? ? ?e)高層支持全員參與

? ? ? ? ? ?f)循序漸進持續(xù)優(yōu)化

? ? 敏捷的價值觀描述的比較簡單、清晰，辨識度很高，更接底氣，更容易打動人！這對于敏捷的宣傳推廣起到了很好的助力！不容易讓人誤解。

? ? 當人們一提到敏捷時，首先想到的是快速交付產(chǎn)品，而提起CMMI時首先想到的是文檔和過程。這種第一印象未必準確、未必正確，但是卻是有很大的輿論效應。

四 內(nèi)容范圍

? ? 1）CMMI完備，敏捷簡單。

? ? CMMI試圖規(guī)避在開發(fā)與管理中遇到的各種風險，所以總結(jié)了很多實踐，是相對完備的集合，在完備性上鮮有類似的模型。CMMI的實踐覆蓋了管理、技術(shù)、支持、過程改進的活動，一個組織內(nèi)的采購、開發(fā)、服務、人力資源管理的業(yè)務都可以參照進行改進。CMMI中包含了組織級支持團隊交付產(chǎn)品或服務的基礎設施的建立、企業(yè)文化的形成。單一的敏捷方法中則缺少這些基礎設施與文化建立的儀式，需要融合多種敏捷方法或輔助以其他方法才可以建立敏捷的基礎設施與文化。

? ? 敏捷試圖規(guī)避在開發(fā)與管理中遇到的最主要的風險，所以總結(jié)了很少的儀式。當在實踐中遇到具體的問題，再來及時應對，它是探索式的管理，不是預測式的管理。不同的敏捷方法有不同敏捷儀式，百花齊放，因為不同的敏捷方法的側(cè)重點不同。Scrum側(cè)重于單團隊的管理活動，XP側(cè)重于單團隊的技術(shù)活動，LeSS、SAFe側(cè)重于多團隊的協(xié)同活動。

? ? 如果要做一個敏捷方法與CMMI的映射，需要將多種敏捷方法的儀式與CMMI的實踐域進行映射才可以覆蓋到。單一的敏捷方法在完備性是無法實現(xiàn)CMMI模型的實踐要求的。

? ? 而一個組織的實際做法往往是介于CMMI與敏捷之間，畫一個示意圖大概如下：

2）二者的很多思想都是共通的。

? ? CMMI的大部分實踐與敏捷的儀式其實思想是相同的，在很多地方都是有共識的，都是來自于歷史的成功組織的最佳實踐。

? ? 他們都要做計劃，都要做計劃跟蹤，都需要配置管理，都要度量數(shù)據(jù)，都要根因分析，都要做反思回顧，都要做驗證與確認等等。只不過是whao to do 與how to do的區(qū)別，活動的抽象層次不同。

? ? 高成熟度的實踐是CMMI特有的，它們也可以嘗試應用于敏捷環(huán)境，但并非必須，當敏捷的實踐在組織內(nèi)成熟到一定程度后也可以做統(tǒng)計管理。

五 推廣難度

? ? CMMI模型區(qū)分了連續(xù)式（自定義視圖）與階段式表示方法（預定義視圖），連續(xù)式表示方法允許企業(yè)自選過程域進行改進，而階段式表示方法則預定義了路線圖，規(guī)定了要包含的PA，階段式表示方法的評估等級稱為組織的成熟度等級，連續(xù)式表示方法的評估等級稱為PA的能力等級。前者在行業(yè)內(nèi)進行標桿對比時，概念簡單，后者則逐個PA進行比較，在實踐中絕大多數(shù)的組織都選擇的是階段式比表示方法，使連續(xù)式表示方法形同虛設。這種結(jié)局也是違背了CMMI模型的初衷，它是期望組織能夠針對自己的實際問題，有選擇性的進行自定義改進路線圖進行提升的，而不是以通過評估為目的的“改進”。

? ?? CMMI模型1.3版本的構(gòu)件中目標是評估時必須考察的，必須滿足的。實踐是期望的，但是企業(yè)在理解CMMI模型、實際執(zhí)行時，咨詢顧問在咨詢時，評估師在評估時往往是把實踐也作為了必須滿足的。這也導致了CMMI模型的初衷與現(xiàn)實的巨大差距！

? ?? 從人的本性來講，人們更喜歡簡單的事物，不喜歡被約束，所以原則+少量的儀式+團隊的自信這種模式更容易被開發(fā)人員認可，從而流行起來。

? ? 但，這并不認為敏捷就比CMMI容易推廣。

? ? CMMI在推廣中面臨形似而神非的現(xiàn)象，敏捷在推廣中也面臨類似的問題。

? ? 一個組織在導入敏捷時，要選擇自己認可的價值觀、原則、儀式、工具等等，也要定義規(guī)范，推廣規(guī)范，需要有教練指導這些原則、儀式、工具的落地。

? ? 很多組織做了迭代策劃、每日站立會議、迭代評審、迭代回顧，但是實際旁觀他們的行為，卻發(fā)現(xiàn)并沒有貫徹敏捷的原則、敏捷的價值觀。因為很多團隊并沒有理解敏捷儀式背后的原理，導致敏捷儀式走樣，不能達到預期的效果。

? ? 也有很多組織只是實施了敏捷的管理實踐，而沒有實施敏捷的技術(shù)實踐，產(chǎn)品的質(zhì)量并沒有得到真正的提高。

? ? 也有的企業(yè)沒有建立組織級敏捷的文化，公司中高層的思想沒有同步更新，團隊的敏捷則無法持久。

? ? 經(jīng)驗型過程控制，追求技術(shù)卓越，這些都要求團隊的核心成員具有豐富的開發(fā)經(jīng)驗、較高的技術(shù)水平，而軟件組織的很多人員并不具備這個基礎。

? ? 譴責CMMI模型不好或者譴責敏捷方法不好，都是片面的，更大程度上是我們落地方法有問題，是我們?nèi)ヂ涞氐娜说膯栴}。

? ? 在一個組織內(nèi)，誰最先發(fā)起要導入CMMI與敏捷的呼吁呢？

? ? 如果是市場的呼吁，那可能側(cè)重的是證書，是投標的需要。

? ? 如果是開發(fā)的呼吁，那可能側(cè)重的是減負，是提高效率的需求。

? ? 如果是老板的呼吁，那可能側(cè)重的是交付高質(zhì)量的產(chǎn)品，快速響應市場的需求。

? ? 不同的sponsor，推動的力度，推動的結(jié)局是不同的。

? ? 對企業(yè)而言，對老板而言，要平衡短期利益與長期利益，活下去，活得好，活得久，需要平衡。

? ? CMMI與敏捷都不是萬能的，都有其適用場景，不能盲目迷信，盲目崇拜，要秉持開放的心態(tài)，持續(xù)發(fā)展的心態(tài)，兼收并蓄，取長補短。

? ? 從理想到實現(xiàn)，都有很遠的路要走，都應該聚焦于給客戶帶來實際效果，立足當下，扎扎實實的去解決問題。

? ? 喧囂之中，需要冷靜思考，務實平衡！