組織級在技術平臺和開發模式不統一的情況下，在過程定義上一定要避免一刀切的標準軟件開發過程。需要根據項目本身的特點和人員情況在滿足項目目標的情況下進行適當的裁剪。
軟件是人開發出來的，過程重要但是人更加重要，兩者必須要考慮結合起來，任何強調和夸大一方面的都不合適。對于小型敏捷團隊我們更加強調人的重要性，對于大型軟件項目可能更加強調規范和過程的重要性，這必須要結合項目特點和實際情況。
所有認證和培訓的市場，到中國就變味的原因，還是在于管理層的急功近利和不務實的態度，結果過了CMMI只是完成了一個形象工程和招標談判的籌碼。如果CMMI過程改進沒有為組織真正帶來質量提升和效率的提高，那么就很難長久。
CMMI提供了對多次迭代和快速原型的支持，但是實際上很多的PA，很多的評估師給出的建議仍然是基于瀑布模型的。而在實際的軟件開發中，特別是交付周期只有2-3個月或更短的項目，很難基于瀑布模型進行開發。
全部遵循了CMMI的過程規范和要求，項目是否就一定能夠成功？在這里答案仍然是不一定，關鍵的問題還是CMMI基于了太多的假設，比如組織能夠提供技能合格的人員，需求基本上都能夠保證是穩定的，而這些假設往往本身就無法滿足。CMMI給我們一個基于很多假設的理想模型，而實際情況就是如果這些假設都能夠很好的滿足的話，可能你并不需要CMMI也可以很好保證項目成功。
CMMI強調證據，數據，過程和文檔。CMMI告訴你需要做什么，你需要有證據來說明你確實做了，因此準備數據和文檔過程是一個要耗費很大成本的過程，在前期我們本身還不成熟的時候更關心的是一項工作投入成本做了以后帶來的實際效益即投入產出比。比如需求追蹤會被我們經常認為是性價比不高的工作。
一個成熟的敏捷團隊（例如ThoughtWorks）自然就具備CMM5級的成熟度，因為我們在面對項目時解決問題的過程是清晰的、可重復的、可度量的、可管理的、自我優化的。如果在軟件過程改進中沒有達到這些目標，就沒有達到真正的改進效果。
文檔不能完全代替溝通，但是不能夠否認文檔和代碼的重要性。當我們注重開發過程的管理和規范的時候，軟件項目和團隊會走向成熟，而過程成熟的一個好處就是整個項目和團隊不會完全依賴一兩個牛人。項目在不斷執行過程中的先進經驗和教訓能夠真正的固化到過程中，形成組織和項目重要的資產。
CMMI每個PA需要做的事情，CMMI不會告訴你怎么去做，但是你必須要首先搞清楚的是為什么要做這件事情，其意義何在？我們在進行軟件過程改進的過程中必須是目標和問題驅動的，這樣才能夠有批判的主動去改進。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
