敏捷與CMMI

　　敏捷與CMMI，算起來，應該是流行了多年，並且至今仍在流行的詞彙。但是，到底什麼是敏捷，什麼是CMMI，到底都是幹什麼的？相信很多人仍然弄不明白。本文將盡可能地用通俗易懂的方式，闡明這幾個問題。

什麼是敏捷？

　　在日常的工作中，經常會聽到或者看到專案組的開發團隊哭著喊著想用敏捷，而管理團隊卻有種種顧慮，比如：文件少了的話，後期維護怎麼辦？我的人員個個都是獨一無二的，進行結對程式設計的話，效率降低了怎麼辦？程式碼任何人都可以修改的話，改亂了怎麼辦？等等各種問題。似乎敏捷更受開發團隊的歡迎而不是管理團隊。

　　那麼，到底什麼是敏捷？

　　從根源上來講，敏捷是軟體開發團隊在歷經各種各樣的折磨、反思之後形成的軟體開發方法，是乙方對怎樣才能更好地向客戶交付價值的反思，是對怎樣才能更好地規避軟體開發過程中的風險和消除軟體開發過程中的浪費的反思。較少的文件、結對程式設計等等，只是反思之後採用的應對措施，是敏捷的表現而不是根本。

什麼是CMMI？

　　對現在的軟體企業來說，CMMI3級是進入行業的敲門磚，很多企業都會為了這個證書做很多的表面工作，而在更多的軟體從業人員眼中，CMMI就是一堆的文件、一堆規範、一堆要求，沒有任何的實用價值，甚至在部分人的眼裡，CMMI還是會阻礙專案目標達成的障礙。

　　那麼，到底什麼是CMMI？

　　從根源上來講，CMMI是甲方在受夠了各種各樣不同水平的乙方的折磨之後，為了選擇合格的乙方而形成的模型，是對乙方能力和水平衡量的各種條條框框的集合。各種各樣的文件、規範、要求，只是為了讓甲方安心而出現的，是CMMI的表現。

什麼樣的情況下應該選擇敏捷，什麼樣的情況下應該選擇CMMI？

　　對甲方來講，使用CMMI的甲方，可以選擇一個可靠的第三方，通過各種各樣的過程證據，證明乙方確實按照要求履行了合同；使用敏捷的甲方，需要自己對完成專案有強烈的願望，願意投入人力與乙方一起把專案做好。對乙方來講，使用CMMI的乙方，精力不可避免地被各種文件的建立和維護、各種合規性的工作牽扯，需要在文件上投入較多的人力；使用敏捷的乙方，可以將主要精力集中在價值交付上，但文件及合規性等方面如果投入不夠的話，對組織資產的積累會有一定的影響。

　　所以，如果你是甲方，並且有強烈的願望想把專案做好，又能夠投入足夠人力的話，建議你用敏捷的方式，能夠快速的得到可用的軟體，並且可以逐步調整你的需求，做你真正想做的東西；如果你只是想完成上級領導的佈置的任務，且自己不想擔很大風險的話，建議你用CMMI的方式，請一個可靠的監理，做一個可以完成上級要求的東西。如果你是乙方，無論是在哪種甲方的情況下，都建議你儘可能的用敏捷的方式，爭取客戶參與，持續整合，經常把已經做出來的功能拿給客戶看一看，用一用，會在很大程度上降低驗收的風險。

　　總的來說，CMMI非常適合政府類經常聽上級命令列事，且參與專案的個人不願承擔太多風險的專案，而敏捷則適合於銀行、軍隊、自用軟體等如果專案做不好，會有非常大損失的專案。