아직도 소프트웨어의 역량 성숙도 모델을 믿는 사람이 있나요?

Question

10년 전 처음 만났을 때 소프트웨어용 CMM 나는 많은 기업에서 특히 영웅에 대한 의존과 관련하여 소프트웨어 개발의 혼란스러운 "레벨 1" 상태를 얼마나 정확하게 설명하는지에 대해 많은 사람들처럼 놀랐다고 생각합니다.또한 조직이 프로세스 개선 수준을 높일 수 있도록 현실적인 지침을 제공하는 것처럼 보였습니다.

그러나 이것이 개선을 위한 좋은 모델과 현실적인 지침을 제공하는 것처럼 보였지만, CMM 준수가 제가 일했거나 함께 일했던 조직에 상당히 긍정적인 영향을 미치는 것을 실제로 목격한 적이 없습니다.저는 CMM 레벨 5(최고 레벨)를 주장하는 한 대형 소프트웨어 컨설팅 회사를 알고 있는데, 그 회사의 프로세스가 CMM이 아닌 다른 기업과 마찬가지로 혼란스럽고 소프트웨어 제품의 품질도 다양하다는 것을 직접 확인할 수 있었습니다.

그렇다면 CMM에 따른 프로세스 개선을 준수함으로써 실제적이고 실질적인 이점을 본 사람이 있는지 궁금합니다.

그리고 개선을 본 경우 개선이 특히 CMM에 기인했다고 생각하십니까, 아니면 대체 접근 방식(예: 식스 시그마) 동등하거나 더 유익했습니까?

아직도 믿는 사람이 있나요?

여담이지만, 아직 보지 못한 분들을 위해 이 재미있는 사실을 확인해보세요. 풍자적 개작 시문

Answer 1

일반적인 CMM 레벨 1 프로그래밍 작업장의 경우 레벨 2에 도달하기 위한 노력은 가치가 있습니다.이는 프로세스에 대해 생각하고 이를 기록해야 함을 의미합니다.당연히 이는 표준, 문서 및 테스트 사례로 인해 제한을 받는 카우보이 프로그래머의 저항에 부딪힐 것입니다.

레벨 2("프로세스가 있습니다")에서 레벨 3("모든 사람이 동일한 프로세스를 가짐")으로 이동하려는 노력은 일반적으로 부서 간 전쟁으로 인해 수렁에 빠지기 때문에 시작할 가치가 없을 것입니다.

Answer 2

나는 그것이 주로 계약 획득/유지 수단으로 사용된 부풀려진 문서 작업이라는 것을 알았습니다.계약을 맺은 다음에는 프로세스를 살펴보는 연습이었습니다.

개발자로서 나는 아무것도 얻지 못했지만 CMMI를 가지고 장난을 치다 몇 달 간의 직업 생활을 잃었습니다.

제가 "상자 속의 상식(Common Sense in a Box)"이라는 브랜드를 붙인 6시그마도 마찬가지입니다.프로세스의 문제가 무엇인지 파악하는 방법을 교육받을 필요는 없었습니다. 일반적으로 문제는 매우 분명했습니다.

나에게는 소규모 팀과 민첩한 메커니즘이 훨씬 더 잘 작동합니다.짧은 주기, 많은 의사소통.모든 환경에서 작동하지 않을 수도 있지만 내 환경에서는 확실히 작동합니다.

내 2센트.

Answer 3

문제의 핵심에는 CMM 지침 자체에 깔끔하게 설명된 이 문제가 있습니다.

“...CMM을 정확하고 통찰력 있게 사용하려면 건전한 판단이 필요합니다.지능, 경험 및 지식은 특정 환경에서 CMM을 적절하게 해석해야 합니다.그러한 해석은 조직과 프로젝트의 비즈니스 요구와 목표를 기반으로 해야 합니다.CMM을 암기하고 체크리스트 중심으로 적용하면 조직에 도움이 되기보다는 해를 끼칠 가능성이 있습니다.”

의 14페이지, 섹션 1.6에서 역량 성숙도 모델, 소프트웨어 프로세스 개선을 위한 지침 카네기 멜론 대학 소프트웨어 공학 연구소, ISBN 0-201-54664-7.

Answer 4

CMM 실행이 표시되면.그리고 빨리 달리세요.

Answer 5

CMM과 CMMI는 조직이 가르치려는 교훈을 진심으로 받아들이는 경우 몇 가지 이점을 제공합니다.문제는 더 높은 수준에 도달하는 것이 매우 어렵고 비용이 많이 든다는 것입니다. 조직이 노력을 기울이는 것을 제가 본 유일한 경우는 고객이 특정 수준에 도달할 때까지 계약에 입찰하는 것을 허용하지 않기 때문입니다.

이는 조직이 실제로 프로세스 개선에 신경 쓰지 않고 "숫자만 얻기" 위해 할 수 있는 모든 작업을 수행하는 효과를 가져옵니다.

Answer 6

더 높은 쪽?아니요.CMM-5 상점은 나에게 깊은 인상을 주지 않습니다.

하단?예.CMM-1 조직은 나를 놀라게 합니다.

CMM은 신규/초보 팀이 스스로를 측정하고 자체 개선 작업을 수행하도록 도울 수 있습니다.

Answer 7

CMMI는 실제로 소프트웨어를 개선하는 것이 아니라 수행한 작업을 문서화하는 것입니다.회사가 생산하는 문서의 무게를 보면 회사의 CMMI 수준을 거의 추정할 수 있습니다.

배경:저는 소프트웨어 엔지니어링 대학원 프로그램에서 CMMI를 공부했고 그 지침을 따르는 팀에서 일했습니다.

Answer 8

내 경험에 따르면 CMM은 너무 모호해서 이행하기가 매우 쉽습니다.또한 인증하러 오면 조직이 선택한 프로젝트를 살펴봅니다.제가 일했던 곳에서는 이 프로젝트는 실제 마감 기한도 없었고, 돈도 많았으며, 프로세스 구석구석에 소비할 시간도 많았습니다.다른 프로젝트 중 다수는 때때로 소프트웨어 버전 관리 없이 코드/디자인 검토가 거의 또는 전혀 없이 계속되었습니다.

CMM 인증을 강조하는 것은 안타까운 일이라고 생각합니다.회사는 시스템 작동 방법을 알고 있으며 실제로 수행합니다.그들은 수익에 부합하는 실제 프로세스 개선에 집중하는 대신 인증 획득 및 시스템 작동에 중점을 둡니다.나는 솔직히 대부분의 조직이 후자에 너무 많은 시간을 낭비하는 대신 전자에 시간을 할애할 것이라고 생각합니다.

정말로 중요한 것은 올바른 개발 결정을 내리고 싶어하며 그러한 결정을 내리는 데 도움이 필요하다는 것을 알고 있는 성실한 사람들이 있다는 것입니다.프로그래밍은 다른 사람과 마찬가지로 실수할 가능성이 있는 지속적인 그룹 활동이라는 것을 아는 우수한 프로그래머를 대신할 수 없습니다.

Answer 9

저는 반복 개발을 수행하는 소규모 팀에 대한 인터뷰를 많이 해왔습니다.개인적으로 이력서에서 CMM을 본다면 이는 결과보다 프로세스에 대한 관심을 나타내는 큰 위험 신호입니다.

Answer 10

서적/교육 과정/인증서를 판매하기 위한 모든 공식적인 방법이 존재하며 다른 이유는 없습니다.그래서 형식적인 방법이 너무 많습니다.이것을 깨닫고 나면 당신은 자유로워집니다 :-)

Answer 11

당신의 돈은 아직도 믿는다.하지만 그는 여전히 세상이 Y2K로 끝날 것이라고 믿을 수도 있습니다.

이것은 개인적으로 별로 믿거나 앞으로 멍에를 메고 싶은 것이 아닙니다.그러나 종종 우리는 이유를 추론하지 않습니다 ...

Answer 12

추신다소 주제에서 벗어난 부분이기는 하지만, 뇌물을 통해 취득한 실제 인증뿐만 아니라 위조된 CMMI 인증도 매우 흔하다는 점을 말씀드리고 싶습니다.

Answer 13

CMM은 실제로 소프트웨어의 품질을 말하는 것이 아니라 프로세스의 문서화 및 반복성에 더 중점을 둡니다.즉, 질서 있고 반복 가능한 개발 프로세스를 가지더라도 여전히 형편없는 소프트웨어를 만드는 것이 가능합니다.프로세스가 적절하게 문서화된다면 CMM 레벨 5를 달성하는 것이 가능합니다.

결국 CMM은 사용되거나 오용될 수 있는 또 다른 도구입니다.최종 목표가 소프트웨어 품질을 향상시키는 것이라면 CMM을 사용하여 개발 프로세스를 개선하고 소프트웨어 품질을 향상시킬 수 있습니다.특정 CMM 수준을 달성하는 것이 목표라면 소프트웨어 품질이 저하될 가능성이 높습니다.

Answer 14

모델은 신뢰성을 잃고 있습니다. 첫째, 회사가 성숙한 소프트웨어 개발 모델을 찾지 않고 CCMI 수준으로 평가되기 위해 모델을 채택하기 때문입니다.

그리고 신뢰성 상실로 이어지는 또 다른 문제는 계약자로서 CMMI 평가 공급업체가 판매하는 프로젝트가 모델 관행을 사용하여 개발될 것이라는 보장이 없다는 것입니다.CMMi 라벨에는 회사가 특정 CMMi 성숙도 수준을 준수하는 것으로 평가된 프로젝트를 한 번 개발했다는 ​​것만 명시되어 있습니다.

문제는 CMMi뿐만 아니라 해당 기업이 개발한 프로세스에도 있다.CMMi는 프로세스 자체를 설명하지 않고 프로세스가 수행해야 하는 작업만 설명합니다.PMBOK에도 동일한 문제가 있습니다.실제로 문제는 PMBOK뿐만 아니라, 주로 PMI 선언문을 따른다고 주장하는 나쁜 프로젝트 관리자가 문제입니다.

Answer 15

학교에서는 다음과 같이 배웠습니다.CMM은 좋은 아이디어이지만 인증이 부족하여(누구나 레벨 5/레벨 4라고 말할 수 있음) 결국 해외 상점을 위한 마케팅 도구가 됩니다.네, 그 아이디어는 타당합니다. 하지만 준수를 어떻게 증명합니까?

Answer 16

나는 그랬다.하지만 이제는 CMM과 CMMI가 애자일 접근 방식에 그다지 적합하지 않다는 것을 알게 되었습니다.

아, 물론 둥근 구멍에 사각형 말뚝을 박기 위해 물건을 쥐어짜낼 수는 있지만 밀어붙일 때에도 여전히 필요한 모든 것을 예측하고 직면하게 될 모든 것을 예상하는 능력에 접근 방식을 기반으로 하고 있습니다. 소프트웨어 시스템.

그리고 우리 모두는 그러한 접근 방식이 실제 생활에서 얼마나 잘 작동하는지 알고 있습니다!(-:

건배,

롭

Answer 17

Agile은 차세대 CMM이며 둘 다 취약합니다.프로세스 및 품질 컨설팅 분야는 모든 산업 분야에서 좋은 사업이며 엔지니어링 담당자와 마찬가지로 모든 사람은 돈의 흐름을 유지하기 위해 새로운 전문 용어가 필요합니다.

SEI에서 처음 나왔을 때 CMM은 탄탄한 학문적 작업을 기반으로 한 좋은 개념이었지만 곧 프로세스 컨설턴트에 의해 선택되었으며 현재는 대부분의 CIO가 자신을 보호하기 위해 사용하는 쓸모없는 인증입니다. CMM 레벨 5 업체 선정)

Agile은 곧 그 길을 따라갈 것이며 곧 지평선에서 다음 묘책을 볼 수 있을 것입니다. :)

Answer 18

상업용 비행 소프트웨어 작업을 할 때 CMM을 사용했고 프로세스가 개선되면서 완료 시간을 정확하게 예측하는 능력이 향상되었습니다.하지만 이는 번거로운 과정이므로 다른 접근 방식도 마찬가지로 작동할 것입니다.

Answer 19

소규모 프로젝트는 성공을 위해 프로세스에 덜 의존합니다.주요 지표는 영웅 대 방관자 비율입니다.HTBR이 0.2 미만인 프로젝트는 심각한 문제에 직면해 있습니다.

Answer 20

어떤 조직에서든 자신의 이익을 위해 쉽게 적용하고 채택할 수 있는 좋은 아이디어가 꽤 많이 있지만 모든 종류의 중복된 문서에 대한 요구 사항으로 인해 배지를 받는 것은 고통스럽습니다.

문제는 CMMi가 프로세스가 아니라 어떤 프로세스를 선택하든 그에 대한 가이드일 뿐이며 그 자체로 설익은 아이디어가 흘러나온다는 것입니다.

또 다른 요점은 마이그레이션을 시작할 때 정말 고통스러운 일이지만 다른 치아 문제와 똑같다는 것입니다.

Answer 21

CMMi의 가치를 이해하는 데 있어서 가장 중요한 문제는 CMMi 자체를 이해하는 것입니다.

CMMi는 소프트웨어 생산을 위한 지속적인 개선에 대한 문서화된 접근 방식입니다.

SPC를 통한 지속적인 개선을 이해하는 것은 제조 측면에서는 충분히 어렵지만 무형의 소프트웨어 제품을 추가하면 그 어려움은 기하급수적으로 커집니다.

CMMi를 처음 접하는 모든 사람이나 조직에 추천하고 싶습니다.현재 프로세스를 문서화한 다음 프로세스와 독립적으로 측정할 수 있는 결과(비용/이익)를 살펴보세요.이런 식으로 어떤 프로세스, 표준 절차가 변경되면 '더 나은' 결과를 얻을 수 있습니다.이 연습의 전제 조건은 '동일'을 비교하지 않기 때문에 임시 환경 내에서 변경의 이점을 측정하는 것이 불가능하기 때문에 문서화되고 안정적으로 반복 가능한 프로세스입니다.

처음에는 위의 개념에 집중함으로써 조직은 CMMi의 본질적인 가치를 이해하고 수용하기 시작할 것입니다.

Answer 22

전설에 따르면 많은 계약을 체결한 미국 국방부는 많은 프로젝트가 시간과 비용 초과에 직면했으며, 프로젝트가 인도되었을 때에도 주문한 것과 정확히 일치하지 않는다는 사실을 발견했습니다.

그래서 그들은 계약업체가 예산 내에서 요구 사항에 가깝게 제 시간에 납품할 수 있는지 확인할 수 있는 방법을 원했습니다.그리하여 역량 성숙 모델이 탄생했습니다.

논제는 사물이 기록되면 마모에도 살아남는다는 것입니다.하지만 다 적는다고 해서 부족하다면, 제대로 적었는지 확인해야 합니다.다른 것들 사이.

이 모든 과정에서 이 모든 작업을 수행하는 데 드는 비용을 고려하는 것은 결코 마음에 들지 않았습니다.왜냐면 국방부 입장에서 보면 1년 안에 뭔가를 얻기 위해 100만 달러짜리 프로젝트를 내놓고 결국 10년에 걸쳐 1000만 달러를 지불하고 원하는 것을 얻지 못했다면, 이제는 그 대신에 2년 안에 실제로 원했던 것을 얻기 위해 동일한 것에 500만 달러를 지불하더라도 그들은 여전히 ​​500만 달러를 절약하고 있으며 실제로 무언가를 얻고 있다는 것은 말할 것도 없습니다.

따라서 미국 DoD 또는 이와 유사한 계약자라면 계속해서 CMM을 구입하십시오. 왜냐하면 요구 사항이기 때문입니다.하지만 제한된 예산, 제한된 시간 등으로 프로젝트를 진행하기 위해 elance에서 수천 개의 소프트웨어 개발 업체와 경쟁하고 있다면...CMM은 좋은 선택이 아닙니다.

즉, CMMI Dev pdf(작성 당시 v 1.3)를 자유롭게 읽어보세요.좋은 점을 많이 만들어줍니다.그것은 조직을 아주 훌륭하게 해체합니다.그리고 당신이 '아하!나한테 이런 문제가 있어'라고 생각했다면, 그 지혜를 활용하여 문제를 해결하세요.우리의 경우, 우리가 한 작은 변화는 우리에게 요구 사항을 제공할 수 있는 모든 사람들의 목록을 만드는 것이었습니다.우리에게 요구 사항을 제공하도록 허용된 사람이 두 명 이상인 경우 한 소스에서 나오는 모든 요구 사항은 다른 소스로 전달되었으며 백로그에 추가하기 전에 그들은 '확인'이라고 대답해야 했습니다.이 작은 변화는 우리가 작업하고 재작업하는 양에 큰 변화를 가져왔습니다.

간단히 말해서 프로세스 영역을 살펴보고 이를 귀하의 고통 영역과 비교하고 CMM이 제공하는 제안을 받아들이십시오.구현하는 방법은 자신의 것입니다.그리고 시간이 너무 많이 걸리거나 비용이 많이 들지 않는 방식으로 언제든지 구현할 수 있습니다.하지만 관련 ISO/IEC 표준에도 동일하게 적용된다고 생각합니다.