CMMI,Capability Maturity Model Integration，偏向於組織級協作的過程框架，強調組織內所有項目應該遵從的相關協定和標準。而底層工作人員很少感覺到CMMI的存在，是因爲這些CMMI的規則與約定是駕凌於單個項目管理與實現之上的，在執行具體項目的時候容易（常）被模糊稀釋化（這裏不論效果好壞或是管理責任的問題）。
RUP，Ratianal Unified Process，統一軟件開發過程，是面向對象分析設計的軟件工程方法論，邏輯上可以理解爲一個貫穿軟件項目生命週期的過程框架。個人認爲它相對與組織級別的CMMI，RUP更偏向於項目級。書上把CMMI和RUP做爲並列關係看待的兩種重型軟件工程方法，但個人認爲RUP更聚焦，聚焦於具體開發項目，例如執行哪種開發流程模型是RUP的討論點，而CMMI則默認瀑布模型。
Agile，敏捷開發,其實是一個過程家族（方法集合），而FDD、XP、Scrum等等則是敏捷家族的具體方法論和過程子集。
所以說，CMMI和Agile不是一個層面的事物，拿CMMI和RUP會更有可比性。另外說明，它們擁有一點重要而相同的地方在於它們的核心思想都是演進evolution，即持續改進。
CMMI更注重流程管理，比如訂立的里程碑，評審點等等，是一個很流程化的東西，需要項目計劃，質量保證計劃，按照軟件瀑布式展開，也就是，需求，設計，研發，測試，上線的這種流程。每個流程都會產出文檔，會有評審會。也就是說，是一步一步的走。實際中CMMI這種流程控制的，都是大項目，有明確的時間週期，而且週期較長，有明確的需求，分析的夠透徹，需求不隨意變更。也就是有
CMMI以完善流程爲主要手段，敏捷完善個人，改善文化爲主要手段
-CMMI以管理，流程爲本，敏捷以人爲本
-CMMI實施，執行及其不靈活，難度大；敏捷輕量級，靈活適應，需要有經驗的輔導
-CMMI被老闆喜歡；敏捷被一線的工程技術人員喜歡
CMMI和敏捷是兩種流派，CMMI注重過程和文檔，敏捷注重代碼本身、程序員的能力和團隊溝通協作。
CMMI比較適合於軟件外包，起源於美國國防部給軟件公司下訂單時，爲了保證交付質量和進度，需要對軟件公司進行一個摸底評估，因此卡梅隆大學就做了一個CMM用來評估軟件公司的成熟度模型，後來演化爲CMMI。在國內，因爲軟件外包的興起，有些外包採購方也要求軟件公司過CMMI，所以國內軟件公司興起了一股過CMMI的高潮。有些大型軟件公司也通過CMMI來衡量自己的軟件開發能力。
而敏捷起源於一些國外黑客和NB程序員羣體，在2001年這些牛人們搞了一個聚會，發佈了有名的四句敏捷宣言。除了敏捷宣言，還有11條敏捷實踐原則。
CMMI的開發模型，一般以瀑布爲主，也有螺旋和快速原型等經典的軟件工程開發模式。敏捷開發模型基本都是迭代，迭代週期一般從1周到1個月。不是迭代，你都不好意思說你用的是敏捷開發。
工具方面，CMMI和敏捷的工具很多是共通的，不過敏捷相對更“極端”一點（參考極限編程，XP，這是敏捷主要的技術實踐基礎）。比如CMMI有同行評審，而敏捷提倡結對編程，實際上是時刻都在做同行評審。CMMI有版本配置管理，敏捷提倡持續集成，即每一次代碼checkin都會引發一次構建、代碼檢查、自動測試、看板更新、郵件推送甚至是版本自動部署。CMMI有版本發佈里程碑，而敏捷提倡持續交付，即每時每刻，在服務器上的版本都是可交付的。
從應用範圍來說，CMMI適合於外包和大規模團隊的分工協作，是一種重量級的過程，屬於集團軍作戰；敏捷適合一個完整的小團隊，屬於特種部隊作戰。現在國內外互聯網公司採用敏捷開發模式很多，因爲用戶需求變更頻繁，版本更新換代快，必須快速響應。有很多大型軟件公司也嘗試使用敏捷開發方式，畢竟現在都在搞項目化運作，大公司小團隊是趨勢。
CMMI是得到明確定義的，最新版本是V1.3，包括了開發、服務和採購三大部分。
Agile並沒有得到明確定義，可以從理念、思想層面來看待Agile，比如擁抱變化，注重溝通；也可以從具體實踐來看待敏捷，比如計劃撲克，迭代計劃，持續集成；也可以從流派來看Agile，比如Scrum，XP，DSDM，FDD，ASD，Agile Crystal，還可以從團隊管理角度來看Agile，還有其它方面。
Agile是豐富多彩的。
所以兩者不能簡單比較。需要明確在那個層面上來看待這些問題。
CMMI是一個最佳實踐集，它提供一個框架。而敏捷可看做實踐掛到CMMI框架中
Agile宣言:
- 項目成員及交互勝過流程和工具。
- 與客戶的協作勝過協約談判。
- 交付的工作軟件勝過文檔。
- 響應改變勝過按部就班。
建議把Scrum分成兩部分，1是Scrum流程，比如計劃會議、每日會議、燃盡圖、回顧、用戶故事、撲克估算等等，2是Scrum團隊，三個典型的角色
我來分享點拙見。分別在通信行業和互聯網行業實踐過幾年的Scrum，有一些體會。
首先，敏捷被很多人和團隊視爲對傳統項目管理的否決，視爲不要流程，不要規則的依據。項目管理本身是一門高深的，非常有價值的學問。不懂項目管理的人做敏捷常常做成野雞流程。
Scrum的精華有兩點，第一是短迭代，第二是自組織。
短迭代讓團隊可以形成節奏感，並在每個迭代後有機會進行迴歸，並在下一個迭代中提高。相比傳統的瀑布流程，因爲缺乏這樣的反饋機制，團隊的改進相對困難。
自組織的目的是讓團隊對目標進行自我承諾，激發團隊最大的能量以達成目標。這是在公司這種權威組織中實行的小規模民主激勵。對於自尊心較強的工程師團隊，相當有效。不過也有缺點，那就是團隊自我意識可能過強，導致跨團隊合作出現問題。
但如果僅僅實現這兩點，Scrum的結果可能是非常糟糕的。特別是短迭代造成兩個負面後果：
第一，短迭代傾向於產生短期設計，在將來的迭代中需要經常重寫。
第二，短迭代導致沒有時間進行全面的迴歸測試，導致bug數量上升。
爲了有效的解決這兩個問題，Scrum必須伴隨一些關鍵的工程實踐。
第一，最重要的，是測試自動化。無論是單元測試還是功能測試，都是在短迭代下保證質量的重要，甚至是唯一手段。
第二，重構。有了自動化測試，敏捷團隊應該勇敢的不斷重構代碼，消除技術債務
第三，持續集成。有了自動化測試，持續集成可以在最短的時間內報告問題，並要求團隊將CI的錯誤作爲最高優先級立即處理。
所以可以看出來，自動化測試是scrum最重要的實踐之一。一個沒有自動化測試的組織，採用scrum雖然也可以受益，但達不到“高績效團隊”的水準。
來源：https://blog.csdn.net/joeyon1985/article/details/42268583
結構化方法包括結構化分析(Structured Analysis，簡稱SA)、結構化設計(Structured Design，簡稱SD)和結構化程序設計(Structured Program Design，簡稱SP)三部分內容。相應地，面向對象方法包括面向對象分析(Object-Oriented Analysis，簡稱OOA)、面向對象設計(Object—Oriented Design，簡稱OOD)和麪向對象程序語言(Object-Oriented Program Design，簡稱OOP)。兩種軟件開發方法從起源、思想、分析、設計，到程序設計、擴展重用、應用等各個方面有着許多的聯繫和區別，下文我將對於本期的這塊學習做一點總結也作爲我複習的一種方式吧。
（一）從分析上看
建立模型是爲了更好地理解要模擬的現實世界，是軟件開發方法的核心問題。在結構化方法中，使用SA構建系統的環境模型和邏輯模型，實現模型的主要工具有數據字典(DD)、ER圖和數據流圖(DFD)。數據字典是一個包含所有系統數據元素定義的倉庫；ER圖描述了數據之間的屬性及聯繫；數據流圖是描述信息流和數據從輸入到輸出變換，並展示系統和外部的接口、數據的輸入和輸出以及數據的存儲的應用圖形技術[1]。SA的前提條件是需求分析，建模過程是迭代分解需求、不斷細化應用的過程，即數據流圖的分解從頂層圖開始，按照每個加工對應一個子圖的分解原則，逐層分解爲0層圖、1層圖等。
面向對象方法使用OOA定義類，對現實世界建模。OOA的主要任務是要在問題域上構建具有主題層、對象層、結構層、屬性層和服務層的OOA模型，實現模型的主要工具有用例圖(Use-Case)和類圖(Class Diagram)。用例圖從用戶角度描述系統功能，並指出各功能的操作者，是對需求分析的整理；類圖定義了類的組成（屬性和服務）、類的結構和類間的關係，確定並劃分系統中的類。經過OOA，系統的靜態模型建立起來。
相對於結構化方法使用DD、ER圖和DFD分別描述數據和功能（儘管二者存在相互參考），面向對象方法中，無論是用例圖還是類圖，數據和功能的描述總是並行的。
（二）從設計上看
在結構化方法中，使用SD構建系統的行爲和功能模型，實現模型的主要工具有模塊結構圖(SC)和程序流程圖。模塊結構圖說明了系統的模塊的劃分、模塊的功能、模塊間的數據傳遞及調用關係。根據數據流圖，我們能夠映射出相應的軟件的上層模塊結構；結合數據流圖，我們可以逐步分解上層模塊，設計出中、下層模塊；對於得到的全部模塊，我們需要設計模塊基本的內部結構和外部接口及對模塊結構進行優化。進一步，則是針對每一個模塊設計程序流程圖，整理優化，歸納算法。SD依然是對項目系統的進一步分解求精的過程，把模型從邏輯級，細化到模塊級，再細化到程序級。
而OOD不只是對OOA的細化，更主要的，構建了系統的動態模型，實現模型的主要工具有交互圖(Sequence Diagram)、狀態圖(State Diagram)、活動圖(Activity Diagram)。和模塊相比，對象最大的不同是具有“活性”，突出表現在對象具有狀態和對象間能夠通訊。交互圖描述對象間的交互關係，顯示對象之間的動態合作關係，強調對象之間消息發送的時間順序；狀態圖描述對象的所有可能狀態，以及事件發生時狀態的轉移條件；活動圖描述爲滿足用例要求所進行的活動以及活動間的約束關係，用於識別並行活動，以提高系統效率[2]。
從設計方面，我們可以比較明顯地看出結構化和麪向對象的區別。結構化方法的核心是程序，從分析到設計，其實是從抽象到具體，從模糊到清晰地實現程序的過程；而面向對象方法的核心是功能，分析的是對象，設計的是行爲，程序設計和系統設計相對分離。
結構化方法和麪向對象方法的比較
見另一篇文章