如何解決敏捷開發與CMMI的衝突？

01-26

大概說說我現在的看法，不一定對

CMMI更注重流程管理，比如訂立的里程碑，評審點等等，是一個很流程化的東西，需要項目計劃，質量保證計劃，按照軟體瀑布式展開，也就是，需求，設計，研發，測試，上線的這種流程。每個流程都會產出文檔，會有評審會。也就是說，是一步一步的走。實際中CMMI這種流程式控制制的，都是大項目，有明確的時間周期，而且周期較長，有明確的需求，分析的夠透徹，需求不隨意變更。也就是有些很完美的，而且足夠時間的完成項目的狀態。

敏捷開放更注重隨時解決問題，可能都不能產出文檔，站立式會議，然後就是改進，改進，改進。強調的更多的是持續有效溝通和行動力。敏捷也會產出文檔，但是經常會變更，應該說會有總體的大文檔分塊產生出來吧。而且在敏捷開始的時候，更多的可能需要項目經理的把控了。敏捷需要的就是及時溝通，及時修改，效率做項目的方法。

大部分互聯網項目已經不考慮CMMI

對於傳統軟體項目，我的建議是在你能做好CMMI的時候再來做敏捷，否則你很難理解敏捷的意義。

衝突就意味著做錯了。要麼CMMI被過度解釋了，要麼敏捷被過度簡化了

首先，說「CMMI和敏捷沒衝突不需要解決」或者「有衝突就做錯了」的同學，你確定你工作中真的遇到了這兩種管理模式？

其次，關於樓主說的「衝突」到底是什麼？學過敏捷的人應該都知道，敏捷並不標榜「萬能」、「通用」，應該知道Stacey矩陣吧？如下圖：

需求明確，技術明確的簡單項目，用傳統模式管理，套用CMMI模型，成熟、沒大毛病，而且效率還會更高一些。

部分複雜和複雜的可以使用敏捷，擁抱變更，需求邊做邊湧現，於是改進改進改進，會比使用傳統項目管理更靈活一些，變更成本和風險都會降低。

那麼一個項目開始時應該可以確定要如何去管理吧？確定用一種模式去管，衝突從何而來呢？

所以我想，樓主應該遇到的問題是：當項目實際情況必須使用敏捷管理，但公司或甲方又要求套用CMMI模型的時候，尤其是當QA追著你要一堆堆文檔的時候，想殺人的心都有了。你的根本問題應該是敏捷沒有得到來自上級的支持。你所謂的「衝突」應該在這裡。

既然這樣，在不清楚問問題的人在公司中能發揮能量大小的情況下，解決辦法列了如下幾條，僅供參考：

1、如果你是項目管理者而且能量大：去和上級溝通，跟他講什麼是敏捷項目管理，得到他的支持。把你自己的工作規範定義好，讓上級可以有監控你工作的依據，讓他知道敏捷不是放羊。如果有甲方合同里要求的文檔，協調不成的話，還得去寫，但是可以去考慮和商務部門建議更新合同模板，下次開發敏捷項目時避免類似衝突。

2、如果你是項目管理者但能量不大：就是做不通上級領導工作，我聽說過很多這樣的事情，他們就是搞兩套唄，自己管理的時候用敏捷的的一套，表面上的CMMI那套還要花時間精力去做。如果你不爽，跳槽好了。但是也要反思一下自己的溝通能力，或者上級領導不支持你的真實原因。

3、如果你不是項目管理者，只是參與者：多學一些多想一些還是有好處的，把看到的問題可以想明白，但是要真正明白還是要動手去管項目，如果有興趣就去系統的學習一下，然後跳槽，去做你想做的事情。

樓主，你的這個問題很大很泛，令我無法回答

能否請你說說具體什麼樣的情景？有什麼樣的衝突？

看到這個問題我在想，為什麼要解決這個衝突？