TestCrunch

정말 어려운 번역이었다. 이 저자의 글 스타일을 보아 하니, CMM의 Text 또한 무지 어려울 것으로 예상(?) 된다. ^^

오역이나 잘못된 틀린 맞춤법은 당연히 모두 원저자의 잘못이 아닌, 번역자의 잘못이다! ^^

--------------------------------------------------------------------------------------------------------

Essence of CMM

Judy Bamberger, Solutions

나는 소프트웨어 개발 역학의 학생으로써, CMM에 당황했다. 나는 그것이 진심으로 소프트웨어 프로세스 문제를 지나치게 단순화하고 있으며, 소프트웨어 개발을 이해하고 있는 사람에게는 쓸모가 적고, 그렇지 않은 사람에게는 위험한 제안을 하는 것이라 생각했다. 이것이 왜 내가 Judy Bamberger에게 매혹되었는지에 대한 이유이다. Judy는 단순한 프로세스주의자가 아니다. 그녀는 열정적이며 독창적인 사상가이다. 지금까지 그녀는 CMM을 적용하고 있으며, 심지어 그것을 길들이고, 어려움을 헤쳐가며 그것을 만들어 낸다. (She makes it jump through hoops of fire.) 그녀는 CMM의 원문에는 어디에도 존재하지 않는 CMM의 지혜를 이끌어내었으며, 지혜를 제공하지 않는 원문은 어떤 것이라도 무시한다. 나는 그녀의 접근법에서 수많은 현실성을 느꼈으며, 그것이 더 나은 것이라고 믿고 싶다. - James Bach

얼마전에 나는 주요 상용패키지 소프트웨어 벤더의 사장과 얘기중이었다. 그는 자신의 회사가 개발한 아주 잘 적용되는 어떤 새로운 컨셉을 설명했다. 나는 그가 그것을 버그 위원회라 불렀던 것으로 기억한다. 그것은 알려진 잔존 결함을 리뷰하고, 변경 요청에 대해 정기적으로 미팅하며, 그것들의 충격을 논의하고, 무엇을 추가하고 수정할지 또는 그대로 둘 것인지 주요 기능 부서가 참여해 결정을 내리는 것이다.

나는 웃으며 물었다. "우리가 형상제어위원회(configuration control board)라 부르는 것을 빼고는, 우리가 당신이 '발견한' 바로 그것과 동일한 프로세스를 15년 동안 사용하고 있었다고 말한다면 당신은 어떻게 반응하겠어요?"
"오!" "나는 아마도 바로 당신을 무시했을 거요!" 그가 말했다.
나는 다시 한 번 배움의 열망을 가지고, 도움을 줄 준비를 하고 물었다. "어떻게하면 나의 15년의 경험을 당신과 공유해서, 당신의 조직이 나머지 업계부터 배우고, 이러한 것들을 스스로 개발하는 것보다 더 빠르게 이익을 얻을 수 있을까요?"
대답은 힘이 없었다. "나도 모르겠소." 하면서 허공을 응시했다.
그리고 나서 내가 마지막으로 물었다. "당신은 소프트웨어 CMM이나 어떤 추가적인 관점을 제공하는 다른 소프트웨어 개발 가이드라인을 알고 있나요?"
"예, 하지만 그것들중 어떤 것도 우리에게 적용되지 않아요. 우리는 매우 다르거든요." 그가 말했다.

상황 안에서의 CMM

나는 CMM의 주요 작성자였으며, V1.0에 대단히 많이 기여했으며, 모든 리뷰에 참석했다. 1991년 8월에 CMM 1.0이 릴리즈되고 난 후, 나는 CMM에 대한 심각하게 다양한 잘못된 오해들을 다루어야만 했다. 나는 CMM이 현존하는 기술 문헌중에 가장 잘못오해된 것중 하나라는 사실을 발견했다.

CMM (수많은 IEEE 표준과 가이드라인 역시도)은 소프트웨어 개발 산업의 제한된 부분에서 최고의 지혜들을 모으려고 시도했다. 하지만, 나는 그 자체의 크기와 표현의 밀집성 때문에, 많은 사람들이 CMM을 이해하는데 어려움을 겪는다는 사실을 발견했다.

나는 당신들과 마찬가지로 CMM이 거대하며, 우주항공산업이나 계약-발주 소프트웨어의 개발환경을 반영하고 있으며, 최초에는 그것들을 다루기 위한 목적이었다는 점에 동의한다 (도메인이나 기술적인 부분, 시스템 그리고 "사람 이슈"는 커버되지 않는다). 그리고 나 또한 당신들과 마찬가지로 그 (사용된) 언어가 이해하기 쉽지 않음에 동의한다 (영어도 있고 "CMM 식의 말투"도 있다).

이것들이 내가 자신들의 개발 프로세스를 개선하기 위한 한 가지 도구로 CMM을 선택한 조직과 함께 일하면서 겪은 어려움들이다.

내가 배운것은 CMM의 모든 것이, 이해하기에 얼마나 쉬운지는 고려되지 않았다는 점이다. 즉, 받아들이는 입장에 따라 제공된 순수한 의미의 텍스트가 과도하게 다른 의미(해석)가 되기 쉽다는 것이다.  또한 나는 이러한 의미들이 CMM을 읽는 이들의 감정을 얼마나 깊게 건드리는지도 바로 배웠다. 받아들이는 사람이 느끼는 중요성과 그 의미는, 오늘날까지 여전히 존재하는 수많은 CMM 단어를 리뷰하고 작성하던 시절에는 상상도 하지 못했던 것이었다.

CMM은 소프트웨어 개발의 훌륭한 사례들의 극히 작은 부분만을 다룬다.

이것은 나를 퍼즐로 인도했다. 만일 CMM이 실제로 거대하고, 우주항공산업이나 계약-발주 소프트웨어 개발환경을 반영하게 작성되었다면, CMM을 개정하고, 다른 사람들이 접근할 수 있도록한 저자로써의 나의 책임을 무엇일까?  내가 나의 고객들과 일할 때, 학생들을 가르칠 때, 커뮤니티와 공개된 장소에서 이야기할 때 나의 책임은 무엇일까? 최초의 커뮤니티가 아닌 CMM을 읽는 사람들의 책임은 무엇인가? 이 모든 것안에서 CMM "작성자(owners)"의 책임은 무엇일까?

나는 내가 통제할 수 있는 퍼즐의 한 부분은 (결국) 내가 어떻게 CMM을 다루는가 라는 결론내렸다. 따라서 나는 항상 고객 (또는 학생)이 어디에서 오는지 이해하려고 시도했다. 왜냐하면, 그들이 참고한 체계나 문제를 가지고 오기 때문이다. 나는 그들의 단어를 사용해서 그들의 세계에 CMM을 가져와서 CMM을 바로알리려 노력했다. 나는 내가 이러한 일을 아주 성공적으로 했었다고 말할 수 있다. 왜냐하면, 고객(또는 학생)들이 수행하고, 이해해야하는 책임이 있다는 것을 증명했기 때문이다.

내가 고객들과 일할 때, 우리는 CMM의 핵심(essence)과 그것을 가져옴으로써 얻을 수 있는 이득을 추구했다. 종종 이렇게 함으로써, 나는 성숙도 레벨이나 등급을 무시하곤 했다. 왜냐하면, 자주 우리는 그것들이 유용하기 보다는 해롭다는 것을 발견했기 때문이다. CMM의 여러 부분들이 고객이 가진 실제적인 문제를 처리할 것으로 생각되기 때문에, 고객들이 극도의 이익을 발견할 수 있는 CMM의 여러 부분들이 존재한다.

반복적인 레벨: 프로젝트의 안정화

나는 그들의 소프트웨어 개발이 "제어되지 않는다"고 믿는 수많은 팀, 프로젝트, 조직으로 부터 이야기를 들었다. 다음의 것들이 고객들이 가장 재난의 근원이 된다고 말하는 이슈들이다.

* 각 파일의 어떤 버전이 "공식적인" 것인지 알려지지 않음
* 한 사람의 수정사항이 다른 사람의 수정사항을 지워버림
* 한 버전의 기능이 이후 버전에 유지되지 않음
* 구현되어야 할 기능에 대해 마케팅부서의 관점과 개발부서의 관점이 다름 (종종 엔드 유저의 필요를 진정으로 이해하지 못함)
* 마지막 순간까지 기능이 변경되고, 외견상 임의적인 방식으로 변경 요청됨
* 개발 공약을 달성할 수 없고, 개발자들이 요구한 공약을 달성할 수 없다고 믿을 때 (공약의) "철회"가 불가능함
* 공약을 맞추기 위해서 완료해야 할 작업이 얼마나 되는지에 대한 통찰력이 부족함
* 각 개발자가 생산한 작업 산출물 간에 현저한 차이가 있고, 재작업이나 통합 동안에 매우 많은 혼란을 야기함
* 신규 개발과 재작업에 쏟아붓는 시간의 양이 증가하고 있음

그리고 감정적인 결과가 있다. 좌절, 동기감소, 애증, 기력소진 그리고 두려움이다 (솔직해 지는 것에 대한, 늦게 릴리즈하는 것에 대한).

나는 사람들이 직면한 이슈들을 이해하려고 시도하면서 시작했다. 나는 듣고, 관찰하고, 반영하고, 승인했다. 나는 사실들과 감정들로 이루어진 그들의 이슈를 청취했다. 그리고 이런 걱정들은 내가 알았던 것이고, 소프트웨어 산업의 많은 영역에서 나타나는 것이다.

이것이 반복적인 레벨에서 CMM이 요구하는 것이다. 개발자들은 그들이 고용된 목적, 즉 소프트웨어를 개발하기위해 통제하에 어떤 규칙들을 정의해야 한다. 이것이 반복적인 레벨에서의 CMM의 핵심이다.

* 릴리즈되는 제품에 통제를 확보하고, 개발중인 제품 파트의 통제를 확보하라. (CMM의 소프트웨어 형상관리 핵심 프로세스 영역)
* 기능 집합을 정의해서, 유저가 원하는 것이 마케팅이나 개발이 원하는 것인지 확실히 하고, 변경의 영향이 완전히 이해되도록 기능을 통제하라 (요구사항 관리 핵심 프로세스 영역).
* 기능 집합을 작업 추정에 사용하라 (약속된 모든 기능이 제공될 수 있도록 하기 위해). 그리고 일정과 다른 계획들을 만드는 데 추정을 사용하라. 가능한 한 많은 과거의 경험과 지식을 활용해라 (소프트웨어 프로젝트 계획 핵심 프로세스 영역).
* 일정과 계획을 가시화 하라. 그렇게 해서, 모든 사람들이 자신들의 목표와 그것을 달성하지 못한 경우 무슨일이 발생하는지 알게한다. 진행상황을 추적하고, 성공을 가늠하고, 일정을 뒤처지거나 기능 이 변경될 때의 영향력을 더 깊게 이해하라. 관리자들이 상태, 리스크 그리고 문제들을 알게 하라. 따라서, 그들이 도울 수 있다. 기본적인 가정들이 변경되면 일정과 계획들을 변경한다 (소프트웨어 프로젝트 추적과 감독 핵심 프로세스 영역).
* 계획이 무엇을 할 것인지, 개정하거나 따라야 할 표준과 관례가 무엇인지 명확히 언급하여 개발팀을 도와라. 그리고 불일치가 발생하는 곳을 확인하고 수정하라 (소프트웨어 품질 보증 핵심 프로세스 영역).

이 모든 것이 개발자, 관리자, 테스터, 마케팅부서등 모두가 기본적인 안정성과 가시성을 확립하는데 도움이 된다. 이러한 것들이 모든 사람에게, 직접적이든 간접적이든 가시적이되면, 더 많은 성공, 즐거움 그리고, 가치를 증진시키는 활동을 하는데 더 많은 시간을 사용할 수 있도록 한다.

그리고 무엇이 진정으로 내게 가치가 있는지는 이러한 컨셉이 나와 개인에 적용될 뿐만 아니라, 내가 코드를 작성하든지 개발 교육이나 제안서를 쓰든지, 다른 어떤 컨설팅 활동의 대부분을 하는데 있어 적용된다는 것이다.

무엇이 CMM이며, 무엇이 CMM이 아닌가?

CMM 의 저작자로서 나는 당신이 사람들과 함께 일하기 전에 어떤 CMM 레벨이 "되어야"한다고 또, y 년까지는 레벨 x를 달성해야 한다는 방식을 의도하지도, 디자인되지도 않았다고 믿는다. 나는 유일한 방법만이 있거나 그것이 CMM이라고 하거나, 또는 점점 더 유명해지는 것처럼 보이는 (필수) 요구사항이나 기타 다른 슬로건은 아니라고 믿는다.

CMM은 만인을 위한 모든 것이거나 시스템이나 소프트웨어 개발의 모든 가능한 측면을 커버하려고 의도되지 않았다. CMM 저작자, 기여자, 리뷰어로써 다년간의 작업을 통해 나로부터 가이드된 관점은, CMM은 소프트웨어 개발 프로젝트나, 시간이 지나면서 개선을 가능하게 하는 가이드라인의 모음을 제공하려는 의도였다. 이러한 가이드라인의 모음은 베스트 프랙티스, 소프트웨어 엔지니어링 교육과정, 실제 세계에서의 경험, 다른 산업에서 온 개념보완에 근거하고 있다. 그리고, 가장 중요한 것은, 이러한 가이드라인 모음은 단지 "반드시 해야하는" 아이템이나 요구사항이 아닌, 가이드라인이라는 점이다. 가이드라인은 해석되고, 맞춤되고 문화와 각각의 고유한 조직의 특성안에서 적용되어야 한다.

CMM에 대한 더 많은 정보는, http://www.sei.cmu.edu/products 를 보라.

공통적인 특징들: 마법은 없다

나는 한 번도 반복적인 레벨의 핵심(essence)이 마법과같이 나타나는 것을 본 적이 없다. 심지어 팀, 프로젝트 또는 조직이 반복적인 레벨의 활동을 수행하는데서 실재적인 이득을 얻었다고 인식해도 말이다. 여기에 다시 한 번, 질문하고 듣고, 관찰하고, 반영하고, 승인하도록 요청한다. 다음과 같은 질문을 요청한다.

    * 어떻게하면 당신이 훌륭한 프랙티스들을 발생하게 할 수 있나? 그리고
    * 당신이 그러한 프랙티스들을 행했는지 어떻게 평가할 수 있나?

이것이 CMM의 공통적인 특징의 핵심이다. 그러한 동인자(enabler)와 평가자(evaluator)는 사람들이 원하는것, 사실상 완료되는 것과 처음에 또는 언제라도 올바르게 행해지는 것을 확실히 하는데 도움이 된다. 훌륭한 동인과 평가 프랙티스는 개발자가 그들이 올바르게잘 일하고 있는지, 결과 산출물이 그들로 부터 충분한 가치를 얻어낼수 있는지 알도록 해준다.

동인자(Enablers)

동인에 대한 내 질문에서 (어떻게 당신은 훌륭한 프랙티스를 공유하고 추출해낼 수 있나? 어떻게하면 새로운 사람이 그것들의 속도를 따라갈 수 있나?), 나는 종종 다음과 같이 대답한다. 우리는 누군가에 책임을 할당한다. 우리는 훈련과 도구를 받는다. 우리는 체크리스트와 템플릿을 만든다.

동인에는 정책과 절차 또한 포함된다. 이제, 어떤 경우 내가 정책과 절차를 말하면, 사람들의 5인치두께의 바인더를 생각하는 것처럼 눈이 풀려버린다. (항상 5인치의 먼지를 커버한다!) 하지만, 정책과 절차에 대해 내가 의미하는 것은 주어진 크기, 경험 그리고 조직의 안정화등으로 이해될 수 있는 것이면 어떤 것이든 상관없다.

나는 종종 "노란색 접착 메모지의 형상관리 정책과 절차"의 진실을 얘기한다. 몇년 전에, 8비트 PC 밖에는 없었고, 윈도우 같은 것도 없었고, PC환경에서 아무런 형상관리 도구조차 없었다. 3명의 아주 영리한 사람이 4개의 서로 다른 시스템에 대해 거대한 소프트웨어 제품을 (아주 빠르게) 개발했다.

그들은 매우 영리했으므로, 서로간의 작업을 단순히 어떻게 하면 손쉽게 지울 수 있는지 발견해 냈다. 따라서, 그들은 다음과 같은 약속을 정의했고 지켰다. "만일 당신이 베이스라인으로 설정된 파일을 변경하고 싶다면, 베이스라인을 유지하는 머신으로 가야한다. 만일 당신이 노란 접착 메모지에서 파일의 이름을 발견하지 못한다면, 당신은 체크 아웃 할 수 있다. 하지만, 당신은 그 파일의 이름을 노란 접착 메모지에 적어놓은 이후라야 한다. 파일의 작업을 완료한 이후에 노란 접착 메모지를 제거한다. 어떤 파일도 당신의 환경에서 테스트될 때까지는 작업을 완료해서는 안 된다. 어떤 인터페이스나 공통 파일도 전체 모두의 사전 협의가 없이 변경되어서는 안 된다."

CMM에서 동인은 체크리스트, 템플릿, 훈련, 도구, 자금, 정책, 절차 같은 것을 포함한다. 이런 모든 아이템들은 사람들에게 일을 첫번에 또는 언제라도 제대로 할 수 있는 지식, 기술 도구를 제공한다. CMM의 용어로는 이것은 수행에 집중 그리고 공통 기능들을 수행할 능력이 있다.

CMM이 진정으로 가치있는 것은 그 컨셉이 내 비즈니스와 나에게 적용된다는 점이다.

평가자(Evaluators)

평가자에 대한 내 질문에서(당신이 어디에 있는지 어떻게 아는가? 당신의 프랙티스들이 당신이 보기에 잘 작동하는지 어떻게 아는가? 사람들이 자신들이 내려야 하는 결정을 내리는데 충분한 정보를 가지고 있는지 당신이 어떻게 알 수 있는가?), 나는 종종 다음과 같이 대답한다. 우리는 마일스톤을 체크한다. 리뷰를 유지하고 있으며, 프로젝트 관리자에게 상태 리포트나 또 다른 정보를 제공한다. 우리는 진행이나 품질 지표들을 게시하므로 모든 사람들이 볼 수 있다.

내가 지표(metric)에 대해 얘기할 때, 사람들은 종종 두려워한다. 왜냐하면, 그들은 지표에 얻기위해 사용하는 측정에 두려움이 있기 때문이다. 따라서, 나는 그들과 함께 작업할 때 이해할 수 있는 지표를 정의한다. 그리고, 그것은 그들이 원하는 것을 달성했는지 여부를 알도록 해준다. 내 고객에 적절한 지표를 끌어내기 위해 나는 3가지 질문을 사용한다.

    * 지금 우리가 어디에 있나?
    * 어디로 가고 싶은가?
    * 우리가 그곳에 도착했는지를 어떻게 알 수 있나?

내 고객들과 나는 이 질문에 대한 답을 얻기 위해 지표에 관한 브레인스토밍을 한다. 그런다음, 우리는 그들이 원하는 것을 어떻게 하면 잘 얻을 수 있는지를 결정하는, 측정하기 원하는 아이템들을 놓고 협상을 한다.

CMM 에서 평가자에는 어떤 것의 완성, 그 상태, 그 품질, 그 효과성의 여부를 알게 해주는 것들이 포함된다. 개발자, 프로젝트 관리자, 상급 관리자 같은 그것을 알기 원하는 사람에의해 정보가 사용되어, 그들이 시의적절하고 효과적인 방식으로 행동을 취하게 하는 것을 말한다. CMM의 용어로는 측정과 분석, 공통 기능의 구현 확인이 있다.

이 모든 것이, 함께 어우러져서, "여기서 우리가 어떻게 해야 하는가"에 대한 문화와 기억을 형성하는데 도움이 된다. 이것은 배움, 시의적절한 액션, 잘 전파된 방식, 시간이 지나면서의 (이루는) 개선의 근간이 된다.

그리고 내게 진정으로 가치가 있는 것은 이러한 컨셉이 내개, 개인에게 뿐만 아니라 어떤 활동, 내가 내 비즈니스를 수행할 때 효과적이 되도록 하는 노력에 적용되기 때문이다.

이것이 CMM이나 최소한 그 일부분의 핵심에 관한 나의 관점이다. 이제 당신의 차례이다. 다음을 시도해 보라.

1. 당신의 소프트웨어 개발 프로세스중에 어려움이 있거나, 개선을 위해 준비가 된 영역을 찾아보라.
2. 그러한 영역을 처리하는 몇가지 옵션들을 찾아보라.
3. 그러한 옵션들과 가까운 것으로 보이는 CMM 내의 핵심 프로세스 영역을 찾아라.
4. 핵심 프로세스 영역의 목적을 읽고, "이러한 목적으로 내가 얻을 수 있는 것은 무엇인지?" 질문하라.
5. 만일 목적들과 당신이 옵션으로 확인한 것들 간에 관계가 있다면, 핵심 프랙티스와 공통 기능을 좀더 심화해서 탐색하라.
6. 열린 사고를 유지하라. 당신이 배우는 만큼 보게되며, CMM의 단어 뒤에 숨은 핵심을 찾아라. 당신의 참조의 틀에서 그것을 찾아내고, 그것을 당신이 직면한 이슈를 처리하는데 주의깊게 사용하라.
7. 그러면 CMM의 핵심으로서 당신이 발견한 것을 내게 알려라. {끝}

Judy Bamberger는 소프트웨어 개발, 팀 리딩, 프로세스 개선 수행 그리고 교육에 20년의 경험이 있다. 또한 독립 컨설턴트인 그녀는 수많은 품질 도구들을 자신들의 핵심부분에 적용하여 최고로 선정된 클래스를 가르쳤으며, 자신들의 실제 팀과, 프로젝트 그리고 조직 상황에 그 내용을 적용한 학생들을 두고 있다.