“Agile 방법론?
과거 방법론의 위험 및 실패요소를 바탕으로 더 효과적인 프로젝트를 수행하기 위해 만들어졌는데 여기서 말하는 Agile이란 기본적으로 소프트웨어를 빨리 개발하여 비즈니스에 적용한다는 것.
등장 배경
전통적인 개발 방식인 폭포모델은 프로젝트는 정해진 순서를 따르게 된다. 각 단계의 끝에서 프로젝트 팀은 최종 점검까지 모두 끝낸 후 고객의 승인을 받게 되고, 고객이 만족하지 않는 한 다음 단계로 넘어가지 않는다.
이 때문에 소프트웨어의 구현 및 테스트 단계에 이를 때까지 잠재적인 문제들과의 대면을 미루게 되며 요구 사항, 디자인, 코딩에 숨어있는 모든 문제들이 프로젝트가 끝나기 직전에 갑자기 부상되어 고통스러운 현실을 만들어 버리는 경우가 발생하곤 한다.
폭포모델의 문제점
1.각 단계를 진행하는 중에 주기적으로 요구사항을 조율할 수 있는 체계적인 방법이 없으며 사용자들은 시스템이 동작되는 것을 보기 전에 자신이 원하는 것을 정확히 알지 못한다.
2.하나의 단계를 완결하고 다음 단계로 진행하는 방식이기 때문에 요구사항 단계를 지나 새롭게 추가되는 요구사항을 반영하려면 프로젝트 일정에 상당한 부담을 주게 된다.
3.개발자들이 각자 개발한 모듈들은 테스트 단계에까지 가야 서로 연동시켜 볼 수 있는데 이러한 모듈 사이의 인터페이스에 문제가 발생할 수 있다. 대부분의 중대한 시스템 결점은 프로젝트 막바지에 발견되며 이를 처리하는 것은 매우 힘든 작업이 된다.
4.추가적인 요구사항을 반영하기에 절대적으로 시간이 부족하기 때문에 버전에 따라 산출물들의 관계와 정보들을 체계적이고 독립적으로 관리하기 힘들어 유지보수에 큰 부담을 주며 반영시킨 요구사항에 대한 프로그램의 품질 역시 떨어지게 된다.전통적인 개발 방식은 소프트웨어 개발주기가 길며 사용자의 요구사항을 효과적으로 반영하기가 어렵다. 더욱이 기업에서는 최소의 소프트웨어 개발 투자를 통해 극대화된 효과를 원하기 때문에 새로운 개발 방식을 찾게 하는 동기를 제공하게 되었다.
Agile 방법론
Agile방법론은 프로젝트에 해를 끼칠 수 있는 것들에 대해 미리 대처할 수 있고,지속적으로 발생하는 변화에 대하여 적절하게 대처할 수 있다는 점에서 출발한다.
Agile 방법론은 소프트웨어 개발을 수행하는 개념적인 프레임워크라 할 수 있다. 대부분의 Agile 방법론에서는 짧은 개발 주기를 반복(iteration)하고, 의도된 방향으로 프로젝트가 진행되는지 수시로 확인하여 위험요소를 최소화 시키고 있다. 반복은 계획수립, 요구사항 분석, 디자인, 개발, 테스트, 문서작업 등의 모든 태스크(task)를 포함한 작은 단위의 프로젝트 개념이다. 이러한 반복은 요구사항을 다 반영하지 못하더라도 릴리즈(release)하는 경향이 있는데 이것은 각 반복 주기마다 구현된 기능들을 확인하고 새로운 요구사항을 받아들이기 위함이다.
또한, Agile 방법론은 실시간 커뮤니케이션과 고객과의 밀착된 개발 분위기를 강조하며 다른 방법론과 비교하여 문서화 작업에 큰 비중을 두지 않는다.실시간 기업(Real Time Enterprise)의 중요성이 더욱 커지고 있는 IT 환경 하에서 애플리케이션 개발팀에게는 짧은 시간에 저렴한 비용을 통해 모든 요구사항을 만족시키며, 효과적으로 비즈니스 수행을 가능하게 해주는 애플리케이션 개발에 대한 압력이 더욱 커지고 있다. 이러한 압력에 효과적으로 대응하기 위한 여러 방법들 중 하나로 Agile 소프트웨어 개발에 대한 관심이 더욱 증가하고 있다.
Agile 방법론의 종류
1.RUP (Rational Unified Process) - 미리 정의된 단 하나의 프로세스가 아니라 개발조직이나 프로젝트 팀에서 각자 필요에 의해 프로세스의 요소를 선별해서 사용할 수 있는 프로세스 프레임워크를 제공한다.
2.XP(Extreme Programming) - 다른 개발방법론과 달리 개발자가 지켜야 할 프로세스를 하나하나 지정하지는 않는다. 정규화된 프로세스 대신 기본 철학을 정의하고 있는데, 그래서 수동적인 프로세스보다 능동적인 의지로 개발에 참여할 수 있게 한다. 이러한 기본 철학은 의사소통, 단순성, 피드백, 용기로 구성되어 있다.
3.SCRUM - 작은 개발 팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 산출하는 것에 초점을 맞추고 있다. SCRUM 프로젝트는 하나 이상의 스프린트(Sprint)로 나누어지는데, 스프린트는 통상적으로 4~6주 정도의 기간을 가지는 잘 정의된 개발 주기를 의미한다. 초기 프로젝트 계획 수립이 완료된 후 고객과 개발 팀이 공동으로 첫 번째 스프린트에 해당하는 산출물을 결정한 후 개발팀은 스프린트를 시작하는데 모든 다른 작업을 제쳐놓고 여기에 집중한다.
급변하는 환경에 대응방법으로는 짧은 개발기간과 유지보수의 용이성을 들 수 있다. 대응방안의 하나로 등장한 Agile 방법론은 비즈니스 요구사항에 대하여 업무에 빠르게 적용될 수 있도록 신속하게 소프트웨어를 개발하며, 이렇게 전달되는 소프트웨어의 품질을 향상시키고, 비즈니스 관련자와의 협업 및 관계를 강화시켜주는 역할을 한다.
감리수행 시 개발방법론의 선정과 적용을 다른 각도에도 볼 필요가 있다.
“ |
