在公司順利通過CMMI level 3的評估之後，我負責組織的稽覈工作並幫助進行流程改善，但在公司推行實踐的過程中，總感到有些壓力和力不從心，不過畢竟，改變原有習慣，強調Process Control，CMMI究竟是輕量級還是重量級的使用等等，都是需要一個持續改進的過程的。我們既不能不論公司的實際情況，將CMMI僅當成了一種實施手冊和準則，好像削足適履那樣，也不能評估過後，連CMMI的思想概念精髓也隨之拋棄腦後。CMMI並沒有錯，CMMI要求寫一大堆文檔的初衷很好目的也很明確，具體到項目中自然有執行上的限制和區別，但它的核心價值是不可抹煞的。我們不能提到CMM就只在文檔上打轉，而毫無利用其中的資源。我們所需要的正是CMM所提倡的Identify it, Control it的思想。或許1~2人的小項目根本沒必要用CMMI,但如果我們沒有將CMMI的概念刻在腦裏，同樣保證不了項目最後的成功。
CMMI的觀點能保證項目在正確軌道上運行，更能保證一個軟件公司持久地有條理地運作。我們有時候總是說，AXDC的項目類型太多，太雜，基本每個項目都不一樣，所以我們做積累，做measurement好像都毫無用處，但其實恰恰相反，每個項目都有它的特點，也有共性，在管理層次，它們的共性提供了跨項目的衡量標準的連續性。這些數據是珍貴的，是一個從來沒有執行過類似規範的小公司不可能擁有的。從文檔上看，已有成功項目的模板確實很重要，因爲很多後繼項目很快就能上路了，一定程度上就得益於這些模板的幫助。
今天偶爾看到了幾篇關於CMMI與敏捷的幾篇文章，感到有些共鳴，因而將其觀點敘述等摘錄如下，算是讀書筆記吧。
CMMI與敏捷
最近在看bob大叔的敏捷軟件開發，結合以前公司採用CMMI軟件過程體系記錄一下自己現在的認識：
CMMI相當於古代的對陣沙場，只需要有主將，其他的有幾個輔佐的將軍，剩下的就是各種軍種，兩軍對壘的時候套路都是一樣的，先出什麼兵種（弓箭兵壓住陣腳），除了主帥和將軍，其他的並不需要英雄，只是遵守紀律的作戰士兵，保持的是整體如一。
敏捷就像現在戰爭中的小分隊，或者古代戰爭中的偵查兵，或者電影中的殺手，他們只有目的，沒有具體的一個過程，因爲過程是瞬息萬變的，需要隨機而變，他們每個單兵都需要有非常高的職業操守和職業技能，需要迅速的對當前的變化作出反應，改變自己的策略。
我理想的開放體系是裁減CMMI衆多的過程，項目初期引入敏捷建立原型。
對於稍微上規模的國內公司來說，敏捷基本是不可取的，因爲他太依靠極個別的牛人了，過內地開發環境如此的浮躁，人的流動如此的頻繁，把公司的基礎建立在幾個人身上，是非常危險的，需要考慮到公司的資產能夠文檔化的保存，因此CMMI是很多公司的管理層推崇的。對於開發人員來說，CMMI太過於沉重，需要大量的文檔化，認爲文檔是沒有技術含量的，就跟寫報表一樣。其實寫出一份好的文檔，才能見到真正的功力，首先要有清晰的邏輯，然後能夠有好的思路整理成文，能夠讓新加入到人一看就懂。報表也一樣，報表是給用戶中的領導看的，是非常重要的，畢竟每個公司的領導纔是拍板的人。
敏捷對於人的要求太高，而國內更多的是一批又一批的新人進入項目做開發，稍微有點經驗的都去管理了，所以敏捷至少在目前的環境下是不適合國內的國情的，真正的過程還是做了大量裁減後的CMMI開發體系。當國內的開發人員不再浮躁，敏捷才有可能在開發中伸展拳腳
CMMI和敏捷的一些對比
1. 組織關注焦點
CMMI - 關注組織級過程能力，所有的項目和團隊的產品或服務的開發都將從組織過程能力提高後受益。
Agile - 焦點是項目和團隊，即使組織不成熟，項目和團隊仍然可以成功。
2.管理
CMMI - 系統化的管理思想和模型應用，特別是集成了各種計劃的項目管理，包括風險管理。
Agile - 管理更多起的是教練作用以消除壁壘，敏捷的這種方法也可以延伸到大項目管理中。
3.信任
CMMI - 一些CMMI的實踐和方法制定的目的是假設了一種低信任環境存在的可能性。
Agile - 敏捷團隊中成員在組建新項目前已經合作的很好，敏捷團隊是一種高信任的環境。
4.計劃
CMMI - 計劃在是組織標準定義上加上項目目標的自定義過程，強調完整詳細計劃，雖然不否認可以迭代。
Agile - 強調計劃是分層次的，包括產品計劃，項目計劃和每次開發迭代計劃，每次迭代版本的計劃一般會在迭代前做的很細化，而且敏捷強調看板式進度可視化，弱化網絡圖和關鍵路徑等方法。
5.市場和用戶假設
CMMI - 在已經穩定和成熟的市場將發揮最大作用。如標準的軟件外包等。
Agile - 在已經緊急臨時或不成熟的市場和需求變化較頻繁的情況下將發揮更大作用。
6.設計假設
CMMI － 強調產品架構已經確定和創建，處於一種穩定的狀態以減少估算不確定性。
Agile - 架構往往會在敏捷開發過程中根據需要進行靈活的裁剪。
7.學習
CMMI - 學習無處不在，包括組織級和項目級，包括計劃，需求，開發，評審，覆盤等各種活動。
Agile - 發生在項目級，典型的是由底向上的問題驅動性學習，雖然有效但是並不系統。
8.願景
CMMI - 期待的是組織和項目長期的過程改進和能力提升，而不是一個項目或版本的改進。
Agile - 更多關注的是當前項目的成功。
9.人力資源
CMMI - 關注重點是組織級和項目級，CMMI提倡非英雄主義，過程成熟的時候無英雄項目也應該成功。
Agile - 強調人的重要性，強調僅僅僱用優秀的人，強調工作和生活平衡的高效團隊。
10.失敗成本
CMMI - 系統工程學的方法，類似航天，飛機和醫藥等高失敗成本的項目更加強調採用。
Agile - 即使項目失敗，擔負的失敗成本會比較低。
敏捷與CMMI：雙劍合璧，更具威力！
許多人認爲敏捷與CMMI是極端對立的，彼此抵消對方的成效。在傳統方式與敏捷框架之間一直持續的論戰中，各自的支持者紛紛列舉出與對方水火不容的觀點。但是這種對抗的態度不但毫無道理，也會對我們的工作-在儘可能短的時間內開發出高質量的軟件-產生妨礙。想要獲得最好的投資收益，最好是創建一組混合模型和方法，選擇合適的技術來應對特定的挑戰。
CMMI回顧
能力成熟度模型集成（CMMI）是一個過程改進方法，它爲組織提供了實現高效的過程所必需的基本元素。它可以用來指導一個項目、一個部門甚至整個組織的過程改進。CMMI能幫助我們整合以往各自爲政的組織功能，建立過程改進的目標與優先級，指導我們進行質量改進，還提供了評價現有過程的參照點。
有趣的是，創建CMMI的初衷是爲了應付一些軟件開發相關的問題，而提出敏捷實踐也是爲了解決這些問題。
對新一代的敏捷實踐者來說，CMMI似乎太臃腫、太枯燥、太缺乏創造性了。有人批評CMMI太官僚，過於關注過程而不是問題本身，削弱了應付日益嚴峻的需求變更的能力。同樣，也有人批評敏捷對開發過程控制不力，導致隱性的變更和混亂。
CMMI提出，在組織中必須建立開發過程，必須採用同行評審來提高質量，必須有版本控制系統。如果我們發現一個跨國公司至今仍缺乏這些基本的“常識性”的控制手段，肯定不只我一個人會感到震驚和失望。如果能合理地應用兩種方法中的原則、方法及技術，我們不至於陷入兩難的境地。然而，要在現有的成熟度級別上同時應用敏捷，以及爲敏捷團隊找到最佳的成熟度級別都會是挑戰。
實施敏捷的最佳時機
一項敏捷實踐應該經過裁剪以適應組織實際的成熟度級別；特別是，如果組織的成熟度處於CMMI第3級，實施敏捷不但可以獲得敏捷帶來的重要好處，還可以減少返工，並全面提高推行CMMI的積極性。如果實施的軟件開發過程既能遵循CMMI規範，又能符合敏捷原則，我們就可以真正獲得CMMI提出的可重複性和可預測性的好處。敏捷特意設計得非常靈活，因此它可以在不違反敏捷宣言所規定的主要目標的前提下，裁剪爲遵循CMMI規範的軟件開發過程。
當成熟度處於CMMI第3級，組織應該已經選定了適合團隊及環境的過程，這些過程主要關注如何交付可正常運行的軟件。此外，針對特定的項目，還要從組織的標準過程集中裁剪出相應的標準、過程描述及流程。因此，實施敏捷的主要工作就是爲集成敏捷實踐而修改那些標準過程。實施敏捷的風險集中在管理開銷上，因爲組織的管理模式可能會限制團隊的自主決策權及靈活性。
在CMMI第3級上實施敏捷的挑戰
如果成熟度未達CMMi第3級，說明組織缺乏穩定的項目管理、需求分析及配置管理相關的過程。正因爲企業各個方面都缺乏訓練，要實施敏捷還得提供缺失的軟件開發過程。如果組織的成熟度未達CMMI第2級，過程常常會因爲人爲原因或外來事件而被迫改變。在這樣的環境中，敏捷項目可能會成功，但成功的經驗不見得能重用。如果組織沒有一種穩定的環境，可能是因爲組織還不清楚建立這樣的環境需要哪些東西。這導致成功依賴於個人的專業知識、能力及英雄主義，而這些成效卻可能被團隊的其它因素抵消。
如果組織的成熟度高於第3級，流程已經基本可以在組織內通用了。這種情況下除非大幅改動那些在CMMI第4級中必需的成文的流程，否則敏捷所帶來的靈活性將非常有限。其實，管理層希望能迅速找到合適的度量來控制項目的成本、進度與範圍，而敏捷項目的進度已經是可視的，這與管理層的意圖已經非常吻合了。此外，成熟度第3級與第4級之間的一個重大差別就是採用某組過程後的效果的可預測性：對於後者來說，過程的效果是通過統計及其它量化技術來控制的，可定量地預測。所以現在我還沒興趣在成熟度已達CMMI第4級的組織中推行敏捷。
結論
至此已經寫了夠多的內容來講明CMM與敏捷實踐之間的關係和協作效果。爲了取得最好的效果，學習CMMI的各個過程域、各個成熟度級別並掌握如何在敏捷與CMMI之間過渡的能力非常重要。
Lydia
