CMM은 메타 모델로 무엇을 해야 하는지에 대한 WHAT을 정의하지 어떻게 해야 하는지에 대한 HOW는 구체적으로 제시하지 않는다. 따라서 조직에서 WHAT을 달성하는 방법은 다양할 수 있다. 다만 필요 이상의 형식적이고 이상적인 요구사항을 조직에 기계적으로 적용을 하다보면 실제 개발과는 단절된 것처럼 느껴지게 된다.

WHAT을 어떻게든 달성해야 하는데 HOW를 모르니, 조직에 맞지 않는 선진 사례를 그대로 베겨버리거나 형식적으로 혹은 결과만 조작하는 경우도 있다. 이것이 개선 모델에만 있는 문제점일까? 실제 무엇과 어떻게를 따로 분리하는 경우, 즉 이론과 실천간에 연계가 없는 경우 지식(베스트 프랙티스)은 고립될 수 밖에 없다. 무엇을 "안다"는 것은 이것을 이해하고 경험하는 과정을 필요로 한다.

단순히 CMM 매뉴얼을 번역하여 전달하고 이를 달성하도록 명령하고 통제하고 점검을 하는 방식으로 프로세스 개선은 이루어지기 어렵다. 개인이나 팀의 독창성이 무시된다면 이들의 참여와 협력을 얻을 수 없다. 개인과 개인, 집단 내 조직 간의 상호작용 과정에서 나오는 협창성(協創性)을 충분히 활용할 수 있어야 한다. 새로운 모델에 따라 모든 것을 버리고 새로 시작하는 것이 아니라 기존의 경험과 지식에 새로운 모델을 융합해 이전의 조직에서 만들지 못했던 가치를 창출하는 활동이다. 

프로세스 개선 과정은 표준화와 개선이라는 지속적 개선(Continuous Improvement)을 활용한다. <Optimization paradox 내의 그림 참조> 개선에는 조직원들의 창의력이 필요하며 조직은 창의력이 발현될 수 있는 제도와 문화, 환경을 만들어 줄 필요가 있다. 많은 조직들이 프로세스 개선에 실패하는 원인이 이러한 협창적 환경이 구성되지 못하여 개선에 대한 조직원의 열정이 식어버리는 것이다. 프로세스 개선에는 기존의 것을 새롭게 볼 수 있는 창의력과 이를 달성하려고 하는 열정이 요구된다.

Best Kept Secrets of Peer Code Review

개발을 마치고 바로 테스트를 진행하는 것보다 코드 리뷰(동료 검토)를 수행한 뒤 테스트를 수행하는 경우가 결함수정 비용이 절감되는 것을 볼 수 있다. 이러한 결함수정 비용의 절감이 의미하는 것은 개발 이후 테스트 과정이 빨리 안정화되면서 전체 기간도 줄어 들 수 있다는 점이다. 

                             자료 출처 : Fagan, M. “Advances in Software Inspections”, IEEE Transaction on SE, July 1986