目錄

1、淺談CMMI與Scrum

2、CMMI與敏捷 DevOps

3、談?wù)劽艚蓍_發(fā)、SCRUM、DevOps及持續(xù)集成

一、淺談CMMI與Scrum

（原創(chuàng) 張兆東 PM日常）

淺談CMMI與Scrum

近一段時間沒更新公眾號了，趁機休息了下，發(fā)現(xiàn)一旦人的惰性養(yǎng)成，再想去堅持原來的事情就有點困難了。臨近春節(jié)，小伙伴要么回家過年了，要么留在駐地過年。很想寫一篇關(guān)于CMMI與敏捷Scrum的感悟，今天淺談個人理解的CMMI與Scrum

CMMI：Capability Maturity ModelIntegration；是軟件能力成熟度集成模型，是一種早期模型，用于處理各種類型的工程任務(wù)。其定義了成熟度模型的架構(gòu)，用來評價組織級能力的模型，是指導(dǎo)組織持續(xù)進行過程改進的模型，它給出了過程改進的路線圖。

Scrum是用于開發(fā)、交付和持續(xù)迭代復(fù)雜產(chǎn)品的一個框架，是一個增量的、迭代的開發(fā)過程。敏捷研發(fā)的一種方法，更多強調(diào)團隊級別。

相同點

二者都要做計劃，CMMI要求做任務(wù)拆分，要做規(guī)模估算、工作量估算，要有進度表，要做計劃評審等。Scrum也要做迭代計劃，比如迭代開始前的PBI（產(chǎn)品待辦列表）梳理，迭代計劃會。

二者都要做計劃跟蹤和檢視，Scrum通過迭代看板，每日站會、迭代評審、迭代回顧會實現(xiàn)了CMMI中MC實踐域的實踐。CMMI要做驗證與確認(rèn)，敏捷要做檢視。

不同點

1） 組織級、團隊級

CMMI側(cè)重于建立組織級的能力，Scrum側(cè)重于團隊級的能力。CMMI定義了高層管理者的治理職責(zé)，要求組織級要定義管理的方針、流程、裁剪指南、模版等，組織級要進行流程執(zhí)行情況的檢查，要給團隊提供資源、工具、培訓(xùn)等支持。

Scrum敏捷方法更側(cè)重于構(gòu)建團隊級的能力，給出了一個小團隊的角色劃分、管理實踐與技術(shù)實踐。

2） 流程的重要程度。

CMMI強調(diào)通過規(guī)范的流程，將人、技術(shù)、工具集成在一起，從而產(chǎn)生好的結(jié)果。CMMI重視流程的重要性，但是沒有強調(diào)簡潔的流程、增值的流程。

Scrum依賴人的經(jīng)驗+做事的原則快速交付高質(zhì)量的產(chǎn)品，敏捷并不否定流程的重要，只是更強調(diào)個體和互動高于流程和工具。

3）文檔的重要性與多少。

敏捷價值觀中強調(diào)：可工作的軟件高于詳盡的文檔。敲黑板，敏捷不是沒有文檔，而是可以工作的軟件比文檔更重要。敏捷中的文檔數(shù)量少，文檔內(nèi)容簡化、文檔形式靈活，編寫剛剛好的文檔即可。Scrum中文檔團隊根據(jù)團隊自適應(yīng)調(diào)整，強調(diào)夠用的文檔，包括用戶故事、測試用例、上線報告等。敏捷認(rèn)為面對面的溝通傳遞信息比文檔傳遞信息更高效

CMMI對流程文檔評估時，要從在制品和訪談兩個維度進行考察。 由于CMMI內(nèi)容的完備性，需要證明某些PA是否滿足了，需要有證據(jù)。CMMI對計劃的內(nèi)容做了比較完備的要求，比如要有人員能力的獲取計劃（培訓(xùn)計劃或人員配備招聘計劃）、資料的管理計劃、風(fēng)險的管理計劃等等。而在敏捷策劃時，這些計劃是根據(jù)需要來定義的，團隊根據(jù)經(jīng)驗想到了就做，沒想到就等出了問題再去解決。CMMI的文檔主要多在文檔內(nèi)容的完備性；CMMI有支持類的PA，包含了質(zhì)量保證、配置管理、決策與解決方案、度量與分析、根因分析與解決方案等。 CMMI有組織級的過程管理類的PA，包含了組織過程焦點、組織過程定義、組織過程性能、組織級培訓(xùn)、組織性能管理。這些PA的制品是敏捷方法中沒有涉及到的。

CMMI與敏捷DevOps

（評估師宋世杰 過程改進）

前幾天一位杭州總監(jiān)級朋友說，近Devops很火，給我發(fā)了一篇《CMMI 和 DevOps新舊時代的圖騰辨識》微信文章。

我從事CMMI的評估、培訓(xùn)已經(jīng)10多年,過去5年也開始學(xué)習(xí)敏捷—— PMI的 Agile Certified Practitioner(ACP), 也教過兩三年的ACP課。

我看完這篇微信文章的第一感覺是:從事CMMI的人真要自我反省，在市場的宣傳、培訓(xùn)方面做得不好，導(dǎo)致很多人對CMMI有誤解。

雖然我對DevOps不是很熟悉，但了解它是因為敏捷開發(fā)使得越來越多團隊在用，觸發(fā)需要有一系列的自動化工具(DevOps ToolChain)，使集成與發(fā)布可以更快速、更自動。（也有一些CMMI客戶開始使用這些自動化工具）。

常見誤解

學(xué)生問:"如果我們用敏捷做項目,是否就不適合用CMMI來評估？因為CMMI好像需要填寫很多文檔，而敏捷卻鼓勵盡量少文檔。”
我回應(yīng)說：“恰恰相反。4年前，CMMI研究院發(fā)布了一個調(diào)查，在使用CMMI模型來評估的公司中，有超過70%是有使用敏捷，說明敏捷項目在使用CMMI的公司中很常見，不會不合適。為什么很多人誤解CMMI是等同于填寫大量文檔？原因之一是，很多公司缺乏信息化系統(tǒng)，為了準(zhǔn)備CMMI所需要的證據(jù)，沒辦法，只可以依賴填一些模板來實現(xiàn)要求，如果公司使用敏捷+DevOps,用大量的自動化集成工具，對應(yīng)很多 CMMI實踐 (practices) 可以直接從工具上的報告截圖，來滿足CMMI的要求?！?p>

比如很多公司用JENKINS來做自動化集成，就不需要填很多集成測試報告來滿足CMMI的產(chǎn)品集成(PI ProductIntegration) 部分，這些工具也可以幫助定義集成的進入條件—— 自動跑對應(yīng)單元測試，比手工跑好得多。

很多人把CMMI等同于傳統(tǒng)的瀑布性開發(fā)。

我們在美國十幾年前參加CMMI培訓(xùn)時，老師都會以3種的場景教我們CMMI的實踐，包括軍方要求 (嚴(yán)謹(jǐn))，整個工作任務(wù)分解(WBS Work BreakdownStructure)便要做得很細(xì)，另外一邊是敏捷的場景，（當(dāng)時敏捷已經(jīng)有十多年二十年歷史）以工作任務(wù)分解為例，可能很簡單在白板上寫下、拍照，也可以達(dá)到工作任務(wù)分解的目的，所以我們常說CMMI只是把常用、通用的抽出，什么情況用什么方法，依據(jù)的事特定的場景需要，所以千萬不要以為CMMI是個過程、流程，有個CMMI過程。

很多做軟件開發(fā)的都對敏捷有興趣，所以在我們的 CMMI V2.0解讀系列中，每一篇都會包括敏捷的章節(jié)，如果在敏捷場景如何解讀CMMI實踐的要求。

教CMMI時，學(xué)生問：“是否可以拿CMMI模型書回去當(dāng)公司的過程嗎？”

我說不可以，因為它只是個面面俱全的框架，不是某個特定過程，只是公司可以依據(jù)實際情況，利用模型制定過程，評審公司的過程是否漏掉了一些必備的元素。

還有很多人誤解CMMI局限在研發(fā)、軟件工程，雖然CMMI源自針對軟件工程的改進，因為開始的時候，很多軟件過程做得不好，導(dǎo)致超支，甚至被取消，所以開始發(fā)展出這個模型來幫軟件公司進行改善，當(dāng)時叫CMM，后來發(fā)現(xiàn)發(fā)現(xiàn)很多成熟度模型的原則可以通用，便擴大到系統(tǒng)工程、硬件上便是現(xiàn)在的CMMI。

相反的是，很多敏捷的方式都是集中在項目級，缺乏從項目級擴大到公司級的做法，它不像CMMI從一開始就有公司級的概念，可按照不同的項目需要定義過程的裁剪。

另外一個對敏捷的誤解:

因為敏捷很多人在用，很多管理者以為敏捷就是一個萬用的良藥，什么都能幫上。在有效項目管理一書中(是ACP 的參考書） ，作者便詳細(xì)列出什么樣的項目適合什么樣的方法 - 從傳統(tǒng)(Traditional) 到 敏捷(Agile) 到極限(Extreme)。（詳見附件)

當(dāng)我做敏捷培訓(xùn)時，會多次強調(diào)不是所有項目都適用敏捷：

1.需要一個很有能力的團隊——成員要面面俱全，能夠兼顧很多方面，才能給客戶更多的價值，反之，如果成員是剛畢業(yè)、沒經(jīng)驗，沒有規(guī)范可循，反而一團糟，這就是有些團隊推敏捷幾個月就告吹的原因。

2.客戶需要頻繁參與整個開發(fā)。為什么團隊可以有價值，在每個沖刺后，一直收到產(chǎn)品經(jīng)理、業(yè)務(wù)部的反饋，如果沒有這樣，就達(dá)不到預(yù)計效果。

3.(與所有過程改進的必要條件一樣)需要領(lǐng)導(dǎo)的支持——領(lǐng)導(dǎo)要有讓團隊發(fā)揮自己大力量的胸懷，給他們獨立空間，盡量支持團隊做好，發(fā)揮大效果，而不是家長式管理。

解讀文中的一些誤解

1、

原文：......CMMI與DevOps是在不同的歷史條件和技術(shù)背景下產(chǎn)生的，代表兩種不同的開發(fā)文化，當(dāng)然CMMI經(jīng)歷幾十年的發(fā)展，被IT企業(yè)廣泛接收并廣泛應(yīng)用。CMMI其實ISO標(biāo)準(zhǔn)一脈相承，其本質(zhì)是軟件管理工程的一個部分......

解讀： CMMI 與 ISO （9000）的主要共同點是?過程改進，CMMI（ CMM） 是早源自軟件工程的過程改進，但I(xiàn)SO是為通用各行業(yè)設(shè)計 （后面再細(xì)分到個別行業(yè)，例如汽車、IT等）

2、

原文：CMMI...其核心是軟件過程改進，指導(dǎo)思想是：依賴一個嚴(yán)謹(jǐn)?shù)倪^程標(biāo)準(zhǔn)管理體系，并能有效執(zhí)行與過程控制，才能保證可持續(xù)地交付合格產(chǎn)品，且整個過程可重復(fù)、可度量、可審計。因此，CMMI的關(guān)注的重點是：軟件過程改進，提升軟件質(zhì)量......

解讀： 誤解CMMI是一套過程標(biāo)準(zhǔn)管理 - 不對。 它是一個框架，所以才可以都不同的項目需要，配上不同的過程 例如：需求不明確的項目應(yīng)用敏捷 管理； 需求明確的合同項目采用傳統(tǒng)瀑布式

3、

原文： 2000年左右，軟件行業(yè)的主要工作是交付客戶定制的軟件應(yīng)用，而軟件研發(fā)團隊被推薦使用像 CMM/CMMI、RUP這樣的大型方法論來組織生產(chǎn)，這些大型方法論效果并不理想，一方面甲乙雙方在需求變更上的扯皮不是影響交付日期就是交付后的產(chǎn)品不能真正解決客戶的問題，另一方面研發(fā)團隊又需要花費大量精力在準(zhǔn)備流程需要的文檔上面。人們越來越意識到傳統(tǒng)意義上的開發(fā)與運維之間存在脫節(jié)現(xiàn)象,從而導(dǎo)致沖突和低效,于是DevOps 應(yīng)運而生。

解讀： 作者可能把 DevOps 與 敏捷 (Agile) 混淆了。 因 DevOps 一詞 是 2009才出來（源自比利時一次以DevOpsDays 為名的會議） 以上說的應(yīng)是 2000 Agile Manifesto（在美國猶他州鹽湖城）的背景。

4、

原文：CMMI更多的是軟件工程管理框架，核心過程域包括：組織管理、項目管理、工程管理和支持管理過程，研發(fā)過程管理只是工程管理中的一部分。

解讀： 對CMMI理解有誤，研發(fā)過程管理不只是工程管理中的一部分。 例如，支持里的配置管理也是每個研發(fā)過程管理必備的一部分。

5、

原文：但企業(yè)實踐中還是以傳統(tǒng)為主，特別是對針對于規(guī)?；瘡?fù)雜業(yè)務(wù)、中后臺系統(tǒng)、對質(zhì)量要求高（缺陷零容忍）的核心系統(tǒng)、賬務(wù)類系統(tǒng)的開發(fā)，質(zhì)量的重要性遠(yuǎn)高于效率，主要以CMMI體系的強管控為主。DevOps成長在敏捷文化之下，其應(yīng)用場景以敏態(tài)為主。

解讀： 很多人還是把 CMMI等同與傳統(tǒng)瀑布式開發(fā)，這點CMMI幾年前（還是SEI時代）已經(jīng)說明 – CMMI是一個模型 框架 ，包括敏捷 / 或傳統(tǒng)瀑布式，按項目需要。

6

原文： DevOps模式下，更需要的是全能型團隊，需求的是能力互補的T型人才，有助于生產(chǎn)協(xié)作。

解讀： 這也是一般敏捷團隊的要求，卻正是這原因，不是每一個團隊都合適

用敏捷。

談?wù)劽艚蓍_發(fā)、SCRUM、DevOps及持續(xù)集成

（楊玉柱 汽車電子與軟件）

1.

敏捷開發(fā)

1.1什么是敏捷?

敏捷是用于描述軟件開發(fā)方法的術(shù)語，強調(diào)增量交付、團隊協(xié)作、持續(xù)規(guī)劃和持續(xù)學(xué)習(xí)。"敏捷"一詞源于2001年《敏捷宣言》。宣言旨在確立指導(dǎo)軟件開發(fā)更優(yōu)方法的原則。其核心是宣布代表敏捷運動基礎(chǔ)的4項價值觀：

個體和交互 勝過過程和工具

可以工作的軟件勝過 面面俱到的文檔

客戶合作 勝過合同談判

響應(yīng)變化 勝過遵循計劃

依據(jù)以上四條價值觀，衍生出來更具體的十二大原則，作為對敏捷宣言更具實操性的解釋，其具體原則內(nèi)容如下：1)重要的是通過盡早和不斷交付有價值的軟件滿足客戶需要。2)我們歡迎需求的變化，即使在開發(fā)后期。敏捷過程能夠駕馭變化，保持客戶的競爭優(yōu)勢。3)經(jīng)常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好。4)業(yè)務(wù)人員和開發(fā)者應(yīng)該在整個項目過程中始終朝夕在一起工作。5)圍繞斗志高昂的人進行軟件開發(fā)，給開發(fā)者提供適宜的環(huán)境，滿足他們的需要，并相信他們能夠完成任務(wù)。6)在開發(fā)小組中有效率也有效果的信息傳達(dá)方式是面對面的交談。7)可以工作的軟件是進度的主要度量標(biāo)準(zhǔn)。8)敏捷過程提倡可持續(xù)開發(fā)。出資人、開發(fā)人員和用戶應(yīng)該總是維持不變的節(jié)奏。9)對技術(shù)與良好設(shè)計的不斷追求將有助于提高敏捷性。10)簡單——盡可能減少工作量的藝術(shù)至關(guān)重要。11)的架構(gòu)、需求和設(shè)計都源自自我組織的團隊。12)每隔一定時間，團隊都要總結(jié)如何更有效率，然后相應(yīng)地調(diào)整自己的行為。

1.2敏捷開發(fā)概念與特點

敏捷開發(fā)是一種從1990年代開始逐漸引起廣泛關(guān)注的新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。它們的具體名稱、理念、過程、術(shù)語都不盡相同，相對于“非敏捷”，更強調(diào)程序員團隊與業(yè)務(wù)專家之間的緊密協(xié)作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應(yīng)需求變化的代碼編寫和團隊組織方法，也更注重軟件開發(fā)中人的作用。敏捷開發(fā)是用于描述迭代軟件開發(fā)的術(shù)語。敏捷開發(fā)通常與傳統(tǒng)或瀑布開發(fā)形成對比，在傳統(tǒng)或瀑布開發(fā)中，大型項目是按照該計劃進行規(guī)劃和執(zhí)行的。敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。迭代軟件開發(fā)縮短了軟件開發(fā)生命周期。