ITIL 또는 CMMI가 개발에 미치는 영향은 무엇입니까? [닫은

Question

나는 소프트웨어 개발에서 어떤 관행이 잘 작동하는지에 대한 많은 책을 읽었습니다. 그리고 개발 분야의 웹 캐스트 나 책이나 블로그에서 ITIL 또는 CMMI와 같은 Methodoly에 대해 들어 본 적이 없습니다.

나는 학교에서 이러한 방법론에 대해 들었고, 그것은 관료적 관행 인 것 같습니다.

그러나 내가 읽은 개발에 관한 모든 책은 공동 작업이나 문서를 통한 사람들에 대해 이야기합니다. (예, 많은 민첩한 책)

제 질문은 다음과 같습니다. ITIL 또는 CMMI와 같은 방법론은 개발자의 개발 또는 일상 생활에 영향을 미치거나 관계를 맺고 있습니까? 그리고 개발 팀에서 사용할 수있는이 메트로 지하에서 좋은 아이디어에 대해 이야기하는 훌륭한 책이나 블로그가 있습니까?

Answer 1

ITIL은 개발이 아닌 인프라 및 지원 측면에 더 중점을 두므로 ITIL에 대한 논의는 아마도 개발중인 StackOverFlow의 "IT"버전에 더 적합 할 것입니다. 제쳐두고, 나는 대부분의 기업에서 인프라, 지원 및 개발을 포함하기 때문에 다른 사이트 "IT"를 호출하는 것을 제외하고는 예외입니다.

저는 Watts Humphrey 제품과 Carnegie Mellon Software Engineering Institute의 제품인 CMMI 및 TEAM 소프트웨어 프로세스 (TSP)와 함께 일했습니다. 지속적인 개선에 최선을 다하고 측정이 지속적인 개선의 핵심이라고 믿는다면 CMMI에서 가치를 찾을 수 있습니다.

CMMI (및 TSP)를 잘못하거나 개발자를 소외시키고 궁극적으로 창 드레싱 또는 인증 더미에서 잘 보이는 방식으로 끝나는 방식으로 매우 쉽습니다. 인도의 개발 공급 업체를 살펴보십시오 ... 기적적으로 모든 CMMI 수준 5. 그들이 말하지 않는 것은 인증을 받기 위해 열심히 노력한 조직에서 거의 항상 하나의 작은 프로젝트 나 팀 이었지만 반복 가능한 관행입니다. 조직의 95%가 단순히 존재하지 않습니다.

시간 추적 (시계 펀칭), 결함 추적 (버그 할당량), 코드 라인 (너무 기울어 진 경우 "게임"의 많은 방법)에 중점을두고 프로세스를 반복 가능하게 만드는 데 중점을 둡니다. 혁신의 자유) 많은 개발자를 끄십시오. <-괄호 안에 지친 반 학습에 주목하십시오.

사실은 개발자의 90% (StackoverFlow 또는 기술 블로그/웹 사이트를 읽은 것 중 소수)가 엉덩이에서 촬영하고 개선 기회가 어디에 있는지에 대한 자기 인식이 부족하다는 사실이 여전히 남아 있습니다. 그들에게 반복과 측정이 촉진되는 자기 인식을 통해 품질이 점진적으로 개선 될 수있는 프로세스와 기회는 CMMI의 귀중한 구성 요소입니다.

올바르게 완료하면 Scrum과 같은 민첩한 방법에서 동일한 이점을 얻을 수 있습니다. 여기서 다시 반복 가능한 반복에 중점을두고, 각 반복에서 학습하고, 목표를 개선/좁히는 데 중점을 둡니다. 애자일 방법이나 CMMI를 채택하고 전체 가치를 얻는 데 팀을 이끌려면 많은 성숙과 경험이 필요합니다.

Agile은 섹시하고 CMMI는 당신이 얻을 수있는만큼 섹시하지 않기 때문에 많이 듣지 못합니다.

Answer 2

민첩한 입양은 상향식 경향이 있습니다. 기술자들은 그것을 우연히 발견하여 경영진에게 추천합니다.

ITIL/CMMI는 하향식 경향이 있습니다. 경영진은 그것에 걸려 넘어져 기술자에게 밀어 넣습니다.

그것은 하나를 선하고 다른 나쁘게 만드는 것은 아닙니다. 대부분은 각 접근법을 설명하는 데 사용되는 언어에 영향을 미칩니다. 그리고 CMMI를 적용하는 데 능숙한 트렌치에서 경험이있는 사람들과 민첩한 관리자들.

"Agile Cmmi"의 Google은 많은 히트를 얻을 수 있습니다. 나는 특히 논쟁의 여지가 있기 때문에 특히 하나를 추천하지 않는 것을 선호합니다 (즉,이 사람들 중 일부는 틀렸다).

내 생각에, 개념 프로세스 일상적인 소프트웨어 개발 작업을 분석 할 때 유용한 아이디어입니다. 반복되는 활동이 있으며 이러한 활동이 종종 비슷한 순서로 구성되어 있다는 생각은 개선으로 이어지는 질문을하는 좋은 진입 점입니다. 당신은 또한 무엇이 무엇인지 물어 보면서 약간의 마일리지를 얻을 수 있습니다. 반복 가능 그리고 어떤 조건에서 활동을 호출 할 수 있습니다 관리.

마법의 사고가 시작될 때 오류와 과잉은 다음과 같이 시작될 때 시작됩니다. "우리가 단지 (종이에) 완벽한 프로세스를 설명하고 정확하게 문서화하면 사람들이 그것을 따라갈 것이며 완벽한 소프트웨어를 얻을 것입니다." 그런 식으로 작동하지 않습니다.