IT 프로젝트의 방법론

흔히 IT 프로젝트를 한다고 하면 SI(Systems integrator)를 말한다.

그런데 이 SI란, 정확하게 시스템 통합을 의미한다.

모든 IT 개발프로젝트가 다 시스템통합을 하는건 아닌데...

 

아무튼 우리는 요즘 Software 솔루션, Hardware 구축, 그리고 SI.. 이렇게 구분지어 말들을 한다.

 

 

 

 

컴퓨터가 개발되고, 그 안에 각종 요지경 세상이 돌아가는건

 

어쩌면 그동안 크고작은 무수한 IT 프로젝트가 진행되었다는 얘기일터.

 

이는 바꿔말하면 그만큼 무수히 많은 실패한 IT 프로젝트가 있었다는 얘기이다.

 

반응형

본디 프로젝트의 성공률은 그리 높지 않아서 누군가는 50%를 넘지 않는다고도 하는데,

IT 쪽은 그야말로 항상 무에서 뭔가를 뽑아내는 것들인만큼 성공률이 그리 높지 않다.

 

그래서 사람들은 프로젝트의 실패율을 줄이기 위해 이렇게 저렇게 무진장 노력을 했다.

(성공율을 높이려라기 보다는 실패율을 줄이기 위해서라는게 보다 더 정확하다. 본디 프로젝트라는게 그러하지 않은가)

 

 

그리고 이런 노력의 산물로 여러 방법론이 발표되고, 많은 모험가(?)들이 이런 방법론을 적용하여 

성공과 실패를 반복하며 다듬어나가 현재는 몇 개의 대표적인 프로젝트 방법론이 남아있다.

 

그나마 제일 유명한 이론들을 꼽아보면 다음과 같다.

(오해하는 경우가 있는데 프로젝트 방법론은 정확하게는 프로젝트 관리 방법론이다. 진짜 개발론과는 구분되어야 한다)

 

• 워터폴(Waterfall)
• 애자일(Agile)
• 하이브리드(Hybrid)
• 임계 경로법(Critical Path Method)
• 린 개발 (Lean Development, LD)
• 스크럼(Scrum)
• 칸반(Kanban)
• 스크럼반(Scrumban)
• 이벤트 체인 방법론 (Event Chain Methodology, ECM)
• 기능주도 개발(Feature-Driven Development, FDD)
• 동적 시스템 개발 모델 (Dynamic System Development Model, DSDM)
• 고속 애플리케이션 개발 (Rapid Application Development, RAD)

 

가장 유명하고 지금도 대형 프로젝트에서 방법론으로 채택하고 있는 개발방법론은 역시 워터폴(폭포) 이론이다.

폭포가 강을 거슬러 올라갈 수 없는것처럼 단계별로 확고하게 매듭을 지어 다음단계로 나아가야 한다.

 

그런데 집을 짓다가도 설계를 무수히 변경하는게 우리네 세상산데... 

 

그래서 이론적으로는 나무랄데 없을지 몰라도 무수히 많은 실패사례를 양산하고 만다.

 

특징적으로 초반에 분석에 집중하여 요건과 필요자원을 보다 정확히 산출하고 그에 따른 정확한 설계로

구축단계에 손실을 배재하는 것을 목적으로 한다.

 

특히나 유연성이 요구되는 프로젝트에는 채용할 수 없기도 하다. 

이에 속도와 유연성에 방점을 찍고 개발된 방법론이 바로 애자일이론이다.

 

 

애자일(agile)은 사전적으로도 '민첩한' 이라는 뜻이니만큼 그 목적이 분명한 이론이다.

그래서 흔히 워터폴과 반대되는 개념이라고 생각하기도 한다.

 

실재로도 애자일 방법론은 '자발적으로 구성된 팀원 또는 팀 간의 통제력을 감소하고 실시간 소통을 주요 과제로 삼는다.

이를 위해 sprint 라는 개념을 도입하여 단위를 잘게 쪼개서 개별 분석, 설계, 구축과 피드백에 해당사자들이 직접 참여하고 실시간 소통을 통해 프로젝트를 진행하게 된다.

 

재미있는건 최근 실시하는 자잘한 사내 프로젝트는 거의 다 '애자일' 방법론을 채택하고 있다는 것이다.

그런데 실상 그 속을 들여다보면 일부 IT 개발자와 선발된 담당자 몇 명이 TFT를 구성하고 독자적으로 진행하는 것이 태반이다. (이건 애자일이 아니다)

728x90

 

워터폴이냐... 애자일이냐... 고민하다 이도 저도 아닌 방향으로 나간게 하이브리드 방법론이다.

이름에서도 알 수 있듯이 워터폴과 애자일 방법론의 장점을 따서 만든 이론이다.

계획 및 요건 단계는 워터폴 접근방식에 따라 이루어지고 디자인, 개발, 이행, 평가 단계는 애자일 방법론을 따르는 식이다.

 

 

어쩌면 지금 우리 주변에서 이루어지고 있는 대부분의 SI 프로젝트가 이렇게 흘러가는지도 모르겠다.

고객은 언제나 실시간으로 프로그램을 테스트해보길 원하기 때문이다.

 

다만... 일찍 오픈하면 할 수록 그만큼 요구사항의 변경과 추가 요구사항이 많아진다는것을 너무나도 잘 아는 개발자는

하루라도 늦게 오픈하려고 한다나 머라나...