CMMI與敏捷開發
阿新 • • 發佈：2018-12-17
最近看了很多關於敏捷開發和CMMI比較的討論，結合我實施CMMI的經驗和對敏捷開發的研究，提出點薄見，還希望大家多多討論！
首先我現在很多公司盲目跟隨潮流使用敏捷開發過程，或CMMI標準過程，未完全確定自己公司的實際情況，保守的說一個企業開發過程未真正的達到CMMI3級的標準過程，那麼它的敏捷開發過程很難實現，只能是徒具一個敏捷開發外殼。
二十世紀初，17 位該方法的倡導者建立了敏捷聯盟（Agile Alliance），並將該軟體開發方法命名為敏捷軟體開發過程。敏捷聯盟成立之初總結了四條基本的價值原則：○人員交流重於過程與工具（Individuals and interactions over processes and tools） ○軟體產品重於長篇大論（Working software over comprehensive documentation） ○客戶協作重於合同談判（Customer collaboration over contract negotiation）○隨機應變重於循規蹈矩（Responding to change over following a plan）。
如果想採用敏捷開發，針對這四條規則應思考並解決四塊問題：○怎樣控制人員交流的效果？○通過開發，測試組成團隊技術能力能高效控制住軟體產品的開發過程麼？這樣是否會增加風險？○怎樣控制客戶和專案中共同協作的效率？是否會增加大量成本？○隨機應變度如何把握？這樣的過程對以後專案的開發過程可重複性和可以預測性有多大？
能力成熟度模型整合（CMMI）是一個過程改進方法，它通過過程域為組織提供了實現高效的過程所必需的基本元素。它將軟體開發的過程分為許多的過程域，通過這些過程域來指導一個專案、一個部門甚至整個組織的過程改進。CMMI能幫助我們整合以往“各人自掃門前雪，休管他人瓦上霜”的組織功能，建立起過程改進的目標與優先順序，指導我們進行過程和質量改進，通過實施過程中產生的眾多文件提供了評價現有過程和做出改進的參照項。這就是大家一提到CMMI，大多第一反應就是實施後文檔很多。所以在此我覺得有必要重申一個觀點：是真正在我們實施的過程中加強對專案控制和改進才產生相關文件，而不是為了達到相關文件數量而實施CMMI。
在80年代早期，在SEI的資助下美國空軍成立了一項研究來分析為什麼許多軟體合同都會超出工期和預算。他們的結論是：糟糕的過程，承包商認為無法按照預定的工期和預算完成合同的原因在於需求不斷變更。這是許多企業急切想解決的問題。但我們如何解決呢？下面給出了點個人的國內軟體情況分析和見解，希望對大家有所幫助。
很多人認為CMMI臃腫、枯燥，不夠靈活，難以適應需求的快速變更，敏捷開發對流程控制不夠，容易產生混亂。
中國現在的軟體環境面臨幾個問題：
1.中小型企業很多，真正能達到CMMI2級以上標準的不多。很多公司現在是達到了CMMI3級文件的要求但實際專案開發過程沒有產生CMMI3級所預期的效果。
2.軟體專案開發中的測試環節，很多公司的高層對此重視還不夠，中國現在達到敏捷開發所要求的測試技術素質還不足。不能夠簡單而高效得應對需求，開發的變化。
3.無論CMMI，還是敏捷開發都強調了團隊的配合度，然而現實國內軟體公司的軟體開發與測試的配合度（重點是開發和測試）很難在實施後達到CMMI和敏捷測試的效果。
4.公司領導層的重視不夠，很多領導層人員想實施但實施的決心和持久度還不夠。對實施風險有較大的憂慮。
5.公司缺少這兩個方面的專業人才。引進諮詢公司會很大程度增大資金投入，並且諮詢人員屬於空降部隊，說服力和職權都難以將過程實施下去。
6.很多公司過分注重個人能力，相信技術牛人，依靠這些技術牛人來保證軟體開發的質量。這會產生很大風險，並且對於WEB專案來說風險將會更大，造成很多專案是失敗的。然而很多公司有太注重流程，導致過程很複雜，效率低下也難以讓專案產生高的效益。這兩個方面的平衡點是公司實施思考的重點。
那我們軟體如何實施呢？是實施敏捷開發還是實施CMMI？什麼階段實施是合理的？兩者能夠結合使用麼？
針對這些問題我覺得應該明確一些問題和尋找一些切入點:
1.首先我們要明確軟體整體發展方向和環境，已經迫使我們要適應當今軟體發展而做出調整，軟體開發已經不是幾個人敲敲程式碼就能賺到錢的工作。面對日益激烈的軟體市場競爭，我們應該從各個方面提高自己的競爭了，而一個符合公司的專案過程就是現在很多公司要考慮的點。
2.不同的公司應對公司不同的情況適當選取一個模型作為基準點，如果一個小的公司得開發過程還沒有達到CMMI3級，甚至沒達到CMMI2級那麼不建議採用敏捷開發過程。如果對於一個專案過程達到CMMI3級要求的公司，可以考慮敏捷開發。對於達到CMMI3級要求的中型企業，並且開發測試人員配備完備，素質較高，那麼建議使用敏捷開發模型吧，這會提高專案的效率。對於大型企業來說，最好輕易不要改變自己已有的軟體專案過程模型，或採用CMMI5模型作為基石，選取部分專案靈活使用敏捷開發積累經驗。
3.作為一些小型軟體企業首先在保證自己企業能很好生存下去的前提下，可以現提高自己部分專案規範，如評審等，因為CMMI提出，在組織中必須建立開發過程，必須採用同行評審來提高質量，必須有版本控制系統。一個CMMI3級或更高的開發過程是一個很龐大的過程，企業不發展到一定地步很難適用，所以可選取其中部分開發過程適用。逐步規範自己的開發過程，然後不斷調整個人技術能力和專案開發過程對專案的影響平衡點，不斷提高自己專案效益。
4.當企業專案開發過程達到CMMI3級，實施敏捷可以獲得敏捷帶來的重要好處，還可以減少返工，並全面提高推行CMMI的積極性。如果實施的軟體開發過程既能遵循CMMI規範，又能符合敏捷原則，我們就可以真正獲得專案開發中的可重複性和成本、風險等可預測性的好處。但敏捷開發在不違反敏捷宣言所規定的主要目標的前提下，裁剪為遵循CMMI規範的軟體開發過程是我們要主要研究的問題。
5.實施敏捷開發或CMMI過程切忌急功近利，要認識到這只是推動公司發展，提高專案效益的一中手段，而非點石成金的魔棒。
6.實施敏捷開發或CMMI過程，應在公司專案輕鬆的時間段進行。
結論：
企業專案開發過程採用什麼模型應該根據自身情況決定，並且不應該硬搬模型，應根據自身情況對其進行裁剪使其適應公司使用。敏捷開發和CMMI在一定情況下可以結合使用，但暫時來看適應條件比較苛刻。具體如果想要結合無很多成功例子做參考，現仍處於討論階段。
希望大家能夠多多討論，推動國內軟體的發展！
首先我現在很多公司盲目跟隨潮流使用敏捷開發過程，或CMMI標準過程，未完全確定自己公司的實際情況，保守的說一個企業開發過程未真正的達到CMMI3級的標準過程，那麼它的敏捷開發過程很難實現，只能是徒具一個敏捷開發外殼。
二十世紀初，17 位該方法的倡導者建立了敏捷聯盟（Agile Alliance），並將該軟體開發方法命名為敏捷軟體開發過程。敏捷聯盟成立之初總結了四條基本的價值原則：○人員交流重於過程與工具（Individuals and interactions over processes and tools） ○軟體產品重於長篇大論（Working software over comprehensive documentation） ○客戶協作重於合同談判（Customer collaboration over contract negotiation）○隨機應變重於循規蹈矩（Responding to change over following a plan）。
如果想採用敏捷開發，針對這四條規則應思考並解決四塊問題：○怎樣控制人員交流的效果？○通過開發，測試組成團隊技術能力能高效控制住軟體產品的開發過程麼？這樣是否會增加風險？○怎樣控制客戶和專案中共同協作的效率？是否會增加大量成本？○隨機應變度如何把握？這樣的過程對以後專案的開發過程可重複性和可以預測性有多大？
能力成熟度模型整合（CMMI）是一個過程改進方法，它通過過程域為組織提供了實現高效的過程所必需的基本元素。它將軟體開發的過程分為許多的過程域，通過這些過程域來指導一個專案、一個部門甚至整個組織的過程改進。CMMI能幫助我們整合以往“各人自掃門前雪，休管他人瓦上霜”的組織功能，建立起過程改進的目標與優先順序，指導我們進行過程和質量改進，通過實施過程中產生的眾多文件提供了評價現有過程和做出改進的參照項。這就是大家一提到CMMI，大多第一反應就是實施後文檔很多。所以在此我覺得有必要重申一個觀點：是真正在我們實施的過程中加強對專案控制和改進才產生相關文件，而不是為了達到相關文件數量而實施CMMI。
在80年代早期，在SEI的資助下美國空軍成立了一項研究來分析為什麼許多軟體合同都會超出工期和預算。他們的結論是：糟糕的過程，承包商認為無法按照預定的工期和預算完成合同的原因在於需求不斷變更。這是許多企業急切想解決的問題。但我們如何解決呢？下面給出了點個人的國內軟體情況分析和見解，希望對大家有所幫助。
很多人認為CMMI臃腫、枯燥，不夠靈活，難以適應需求的快速變更，敏捷開發對流程控制不夠，容易產生混亂。
中國現在的軟體環境面臨幾個問題：
1.中小型企業很多，真正能達到CMMI2級以上標準的不多。很多公司現在是達到了CMMI3級文件的要求但實際專案開發過程沒有產生CMMI3級所預期的效果。
2.軟體專案開發中的測試環節，很多公司的高層對此重視還不夠，中國現在達到敏捷開發所要求的測試技術素質還不足。不能夠簡單而高效得應對需求，開發的變化。
3.無論CMMI，還是敏捷開發都強調了團隊的配合度，然而現實國內軟體公司的軟體開發與測試的配合度（重點是開發和測試）很難在實施後達到CMMI和敏捷測試的效果。
4.公司領導層的重視不夠，很多領導層人員想實施但實施的決心和持久度還不夠。對實施風險有較大的憂慮。
5.公司缺少這兩個方面的專業人才。引進諮詢公司會很大程度增大資金投入，並且諮詢人員屬於空降部隊，說服力和職權都難以將過程實施下去。
6.很多公司過分注重個人能力，相信技術牛人，依靠這些技術牛人來保證軟體開發的質量。這會產生很大風險，並且對於WEB專案來說風險將會更大，造成很多專案是失敗的。然而很多公司有太注重流程，導致過程很複雜，效率低下也難以讓專案產生高的效益。這兩個方面的平衡點是公司實施思考的重點。
那我們軟體如何實施呢？是實施敏捷開發還是實施CMMI？什麼階段實施是合理的？兩者能夠結合使用麼？
針對這些問題我覺得應該明確一些問題和尋找一些切入點:
1.首先我們要明確軟體整體發展方向和環境，已經迫使我們要適應當今軟體發展而做出調整，軟體開發已經不是幾個人敲敲程式碼就能賺到錢的工作。面對日益激烈的軟體市場競爭，我們應該從各個方面提高自己的競爭了，而一個符合公司的專案過程就是現在很多公司要考慮的點。
2.不同的公司應對公司不同的情況適當選取一個模型作為基準點，如果一個小的公司得開發過程還沒有達到CMMI3級，甚至沒達到CMMI2級那麼不建議採用敏捷開發過程。如果對於一個專案過程達到CMMI3級要求的公司，可以考慮敏捷開發。對於達到CMMI3級要求的中型企業，並且開發測試人員配備完備，素質較高，那麼建議使用敏捷開發模型吧，這會提高專案的效率。對於大型企業來說，最好輕易不要改變自己已有的軟體專案過程模型，或採用CMMI5模型作為基石，選取部分專案靈活使用敏捷開發積累經驗。
3.作為一些小型軟體企業首先在保證自己企業能很好生存下去的前提下，可以現提高自己部分專案規範，如評審等，因為CMMI提出，在組織中必須建立開發過程，必須採用同行評審來提高質量，必須有版本控制系統。一個CMMI3級或更高的開發過程是一個很龐大的過程，企業不發展到一定地步很難適用，所以可選取其中部分開發過程適用。逐步規範自己的開發過程，然後不斷調整個人技術能力和專案開發過程對專案的影響平衡點，不斷提高自己專案效益。
4.當企業專案開發過程達到CMMI3級，實施敏捷可以獲得敏捷帶來的重要好處，還可以減少返工，並全面提高推行CMMI的積極性。如果實施的軟體開發過程既能遵循CMMI規範，又能符合敏捷原則，我們就可以真正獲得專案開發中的可重複性和成本、風險等可預測性的好處。但敏捷開發在不違反敏捷宣言所規定的主要目標的前提下，裁剪為遵循CMMI規範的軟體開發過程是我們要主要研究的問題。
5.實施敏捷開發或CMMI過程切忌急功近利，要認識到這只是推動公司發展，提高專案效益的一中手段，而非點石成金的魔棒。
6.實施敏捷開發或CMMI過程，應在公司專案輕鬆的時間段進行。
結論：
企業專案開發過程採用什麼模型應該根據自身情況決定，並且不應該硬搬模型，應根據自身情況對其進行裁剪使其適應公司使用。敏捷開發和CMMI在一定情況下可以結合使用，但暫時來看適應條件比較苛刻。具體如果想要結合無很多成功例子做參考，現仍處於討論階段。
希望大家能夠多多討論，推動國內軟體的發展！