폭포수개발방법론과 애자일개발방법론
폭포수모델 개발방법
애자일(Agile) 개발 방법론이 나오기 전, 대부분의 소프트웨어 개발은 폭포수모델 개발방법으로 진행되어 왔습니다. 폭포수모델 개발방법은 개발계획, 일정 및 설계 등을 체계적으로 세움으로써 효율적으로 프로젝트를 수행하기 위한 목적으로 사용되었습니다. 즉, 본격적인 프로젝트 돌입에 앞서, 완벽한 개발계획을 수립해야 한다는 신념을 가지고 처음 요구사항 및 계획수립단계에 큰 노력을 쏟는 방법입니다. 고객과의 인터뷰나 사이트 방문을 통해 요구사항을 수집하고 수집한 내용을 분석해 필요한 기능들을 식별합니다. 식별한 기능들을 요구사항으로 정리하고 검토 단계를 밟습니다. 요구사항 검토가 끝나면, 요구사항 기능 개발을 위한 프로젝트 업무분장과 소프트웨어 설계를 하고, 본격적인 개발(코딩)을 진행합니다. 개발이 완료되면, 고객의 요구사항대로 필요한 기능들이 모두 포함되었는지를 테스트하며 검증 단계를 거쳐 최종 배포를 하게 됩니다. 이러한 방식으로 진행하는 방식을 폭포수모델(Cascading Model) 개발방법이라 합니다.
애자일(Agile) 개발방법
이러한 폭포수모델 개발방법의 문제점을 개선하기 위해서는 폭포수모델의 장점을 수용하면서도 단점을 보완하는 개발방법론이 필요한데 그 배경으로 등장한 것이 바로 애자일 개발방법입니다. 애자일 개발방법은 소프트웨어 개발 프로세스에 유연함을 가져다주는 방법이라 할 수 있습니다.
애자일 연합(Agile Alliance)에 따르면, 애자일 프로세스를 도입하기 위해 필요한 전제조건으로 다음 3가지가 중요하다고 이야기하고 있습니다.
첫째, 팀 규모가 작아야 합니다.
둘째, 구성원의 물리적인 위치가 가까워야 합니다.
셋째, 구성원 간 엄격한 역할 구분이 없어야 합니다.
종합하자면 애자일을 잘 운영하기 위해서는 모든 구성원 간 고도의 협업이 필요함을 의미합니다. 예를 들어 한 팀원이 의문을 제기하면 모두가 모여 답을 찾기 위한 회의를 가지고, 아이디어가 나오는대로 문서나 승인 작업 없이 즉시 작업에 반영합니다. 반복 사이클을 돌아 임시 버전1에 해당하는 결과물이 나오면 클라이언트와 함께 작업 결과물을 보면서 의견을 주고 받습니다. 이 피드백 내용은 다음 임시버전 결과물에 반영됩니다. 이렇게 몇차례의 개발 반복 사이클을 돌아 몇 개의 임시 버전이 산출물로 나오며, 모든 개발 반복 사이클이 끝나면 최종릴리즈버전이 탄생하게 됩니다.
결과적으로, 애자일 접근법은 상세한 요구사항 정리 문서 작업이나 개발 문서에 치우치기 보다는, 프로젝트 구성원 간의 긴밀한 협업을 중시하는 특징을 갖고 있습니다. 또한 다양하고 복잡한 고객의 요구사항에 유연하게 빠르게 대처할 수 있다는 특징을 가집니다.
애자일 종류
애자일은 크게 2가지 방식으로 분류할 수 있습니다.
- SCRUM: 처음부터 끝까지 프로그램을 개발할 때 사용합니다.
- KANBAN: 유지보수 업무 혹은 간단한 Feature를 추가할 때 사용합니다.
애자일에 대한 오해
첫째, 애자일은 문서없이 코드로만 진행한다?
소스코드로만 이해하려면 클린 코드가 작성되어야 한다는 전제조건이 들어가게 됩니다. 또 코드는 계속해서 바뀌기 때문에 유지보수(리팩토링)를 지속적으로 진행해야 합니다. 코드 리뷰를 통해 코드의 품질을 관리해야 하는 등 상당한 노력과 시간을 필요로 합니다. 결국, 문서없이 코드로 빠르게 진행하려면, 2주 전에 짠 나의 코드가 읽혀지고, 어제 동료가 짠 코드가 이해되어야 합니다. 거기에 테스트 코드까지 완벽하다면 애자일의 완성이라고 할 수 있습니다. 따라서 완벽히 문서를 없애고 코드로 대체를 하기란 어려운 일이며, 충분한 시간과 노력을 들이지 않으면 적용하기가 쉽지 않습니다.
둘째, 애자일은 스프린트와 이터레이션이 전부다?
스프린트와 이터레이터는 애자일을 도와주는 하나의 도구에 불과합니다. 애자일의 핵심은 개별 구성원 간의 긴밀한 상호작용이므로, 어떻게 상호작용을 긴밀하게 해나갈 것인가를 고민하는 것이 핵심이라고 할 수 있습니다.
그외에 애자일을 제대로 정착하기 위한 필요한 노력
애자일을 제대로 정착시키기 위해서는 무엇보다도 회고를 잘해야 합니다. 매일매일 리뷰와 회고가 진행되어야 합니다. 리뷰는 지금까지 해온 일들을 단순히 훑어보는 것이고, 회고는 해온 일들 중 개선할 점을 찾는 것이라고 할 수 있습니다. 따라서 업무현황 및 문제점, 문제의 원인, 그리고 원인에 대한 해결책으로 이어지는 부분을 집중적으로 되짚어보아야 합니다. 회고를 잘하기 위한 2가지 방법을 마지막으로 소개하며 글을 마치도록 하겠습니다.
- Burn Down 차트와 코드양 그래프를 그려서 개선점을 찾습니다.
- 결합 그래프를 그려서, Close 그래프와 Open/Reopen 그래프 사이에 벌어지는 시점과 붙는 시점이 언제인지 알아야 합니다. 벌어지는 시점의 의미는 도구가 불안정적이라는 의미이며, 붙는 시점은 도구가 안정화되간다는 의미입니다.
이상으로 폭포수모델개발방법론과 애자일 개발방법론에 대한 포스팅을 마치도록 하겠습니다. 감사합니다.
애자일(Agile) 개발 방법론이 나오기 전, 대부분의 소프트웨어 개발은 폭포수모델 개발방법으로 진행되어 왔습니다. 폭포수모델 개발방법은 개발계획, 일정 및 설계 등을 체계적으로 세움으로써 효율적으로 프로젝트를 수행하기 위한 목적으로 사용되었습니다. 즉, 본격적인 프로젝트 돌입에 앞서, 완벽한 개발계획을 수립해야 한다는 신념을 가지고 처음 요구사항 및 계획수립단계에 큰 노력을 쏟는 방법입니다. 고객과의 인터뷰나 사이트 방문을 통해 요구사항을 수집하고 수집한 내용을 분석해 필요한 기능들을 식별합니다. 식별한 기능들을 요구사항으로 정리하고 검토 단계를 밟습니다. 요구사항 검토가 끝나면, 요구사항 기능 개발을 위한 프로젝트 업무분장과 소프트웨어 설계를 하고, 본격적인 개발(코딩)을 진행합니다. 개발이 완료되면, 고객의 요구사항대로 필요한 기능들이 모두 포함되었는지를 테스트하며 검증 단계를 거쳐 최종 배포를 하게 됩니다. 이러한 방식으로 진행하는 방식을 폭포수모델(Cascading Model) 개발방법이라 합니다.
<그림1> 폭포수모델 개발방법
이처럼 폭포수 모델 개발방법은 처음 요구사항과 설계 단계에 신경을 많이 쓰기 때문에, 일련의 프로세스와 계획에 따라 프로젝트를 진행할 수 있다는 장점이 있습니다. 하지만 단점도 있는데, 가장 큰 단점으로는 계획대로 프로젝트가 진행되지 않을 때 고객에게 소프트웨어 납기일을 못 맞출 가능성이 크다고 볼 수 있습니다. 작은 기능이면 그나마 낫지만 크고 복잡한 기능에 대해 요구사항과 설계가 변경되면, 기능을 바로 잡기 위해 소프트웨어 유지보수에 상당한 노력이 투입되게 됩니다. 즉, 변경을 가하지 않은 모듈은 기존대로 정상동작을 해야함과 동시에, 변경되는 모듈도 문제없이 돌아가도록 수정이 되야 하는 것입니다. 이런 부분은 경험이 많은 개발자들도 힘들 수 있는 부분이고, 결코 쉽지 않습니다. 결과적으로 빈번한 요구사항 변경과 설계수정은 적지 않은 개발비용을 초래하게 되어 원하는 목표를 달성하기가 어려워집니다.애자일(Agile) 개발방법
이러한 폭포수모델 개발방법의 문제점을 개선하기 위해서는 폭포수모델의 장점을 수용하면서도 단점을 보완하는 개발방법론이 필요한데 그 배경으로 등장한 것이 바로 애자일 개발방법입니다. 애자일 개발방법은 소프트웨어 개발 프로세스에 유연함을 가져다주는 방법이라 할 수 있습니다.
<그림2> 애자일(Agile) 개발방법
위 그림을 보면, 애자일 프로세스는 개발 반복 사이클을 여러 개로 나눕니다. 개발 반복 사이클이 완료될 때마다 즉시 승인을 하고, 모든 개발 반복 사이클이 완료될 때까지 수행합니다. 반복 사이클은 [요구사항수집-설계 및 디자인-구현-테스트]의 방식으로 이루어집니다. 개발 반복 사이클을 짧게 잡기 때문에 미쳐 고려하지 못한 설계부분이 있거나 잦은 요구사항이 발생하더라도 이를 유연하게 대처할 수 있습니다. 이러한 장점 덕분에, 최근에는 많은 개발팀에서 애자일을 적극적으로 도입하고 있습니다.애자일 연합(Agile Alliance)에 따르면, 애자일 프로세스를 도입하기 위해 필요한 전제조건으로 다음 3가지가 중요하다고 이야기하고 있습니다.
첫째, 팀 규모가 작아야 합니다.
둘째, 구성원의 물리적인 위치가 가까워야 합니다.
셋째, 구성원 간 엄격한 역할 구분이 없어야 합니다.
종합하자면 애자일을 잘 운영하기 위해서는 모든 구성원 간 고도의 협업이 필요함을 의미합니다. 예를 들어 한 팀원이 의문을 제기하면 모두가 모여 답을 찾기 위한 회의를 가지고, 아이디어가 나오는대로 문서나 승인 작업 없이 즉시 작업에 반영합니다. 반복 사이클을 돌아 임시 버전1에 해당하는 결과물이 나오면 클라이언트와 함께 작업 결과물을 보면서 의견을 주고 받습니다. 이 피드백 내용은 다음 임시버전 결과물에 반영됩니다. 이렇게 몇차례의 개발 반복 사이클을 돌아 몇 개의 임시 버전이 산출물로 나오며, 모든 개발 반복 사이클이 끝나면 최종릴리즈버전이 탄생하게 됩니다.
결과적으로, 애자일 접근법은 상세한 요구사항 정리 문서 작업이나 개발 문서에 치우치기 보다는, 프로젝트 구성원 간의 긴밀한 협업을 중시하는 특징을 갖고 있습니다. 또한 다양하고 복잡한 고객의 요구사항에 유연하게 빠르게 대처할 수 있다는 특징을 가집니다.
애자일 종류
애자일은 크게 2가지 방식으로 분류할 수 있습니다.
- SCRUM: 처음부터 끝까지 프로그램을 개발할 때 사용합니다.
- KANBAN: 유지보수 업무 혹은 간단한 Feature를 추가할 때 사용합니다.
애자일에 대한 오해
첫째, 애자일은 문서없이 코드로만 진행한다?
소스코드로만 이해하려면 클린 코드가 작성되어야 한다는 전제조건이 들어가게 됩니다. 또 코드는 계속해서 바뀌기 때문에 유지보수(리팩토링)를 지속적으로 진행해야 합니다. 코드 리뷰를 통해 코드의 품질을 관리해야 하는 등 상당한 노력과 시간을 필요로 합니다. 결국, 문서없이 코드로 빠르게 진행하려면, 2주 전에 짠 나의 코드가 읽혀지고, 어제 동료가 짠 코드가 이해되어야 합니다. 거기에 테스트 코드까지 완벽하다면 애자일의 완성이라고 할 수 있습니다. 따라서 완벽히 문서를 없애고 코드로 대체를 하기란 어려운 일이며, 충분한 시간과 노력을 들이지 않으면 적용하기가 쉽지 않습니다.
둘째, 애자일은 스프린트와 이터레이션이 전부다?
스프린트와 이터레이터는 애자일을 도와주는 하나의 도구에 불과합니다. 애자일의 핵심은 개별 구성원 간의 긴밀한 상호작용이므로, 어떻게 상호작용을 긴밀하게 해나갈 것인가를 고민하는 것이 핵심이라고 할 수 있습니다.
그외에 애자일을 제대로 정착하기 위한 필요한 노력
애자일을 제대로 정착시키기 위해서는 무엇보다도 회고를 잘해야 합니다. 매일매일 리뷰와 회고가 진행되어야 합니다. 리뷰는 지금까지 해온 일들을 단순히 훑어보는 것이고, 회고는 해온 일들 중 개선할 점을 찾는 것이라고 할 수 있습니다. 따라서 업무현황 및 문제점, 문제의 원인, 그리고 원인에 대한 해결책으로 이어지는 부분을 집중적으로 되짚어보아야 합니다. 회고를 잘하기 위한 2가지 방법을 마지막으로 소개하며 글을 마치도록 하겠습니다.
- Burn Down 차트와 코드양 그래프를 그려서 개선점을 찾습니다.
- 결합 그래프를 그려서, Close 그래프와 Open/Reopen 그래프 사이에 벌어지는 시점과 붙는 시점이 언제인지 알아야 합니다. 벌어지는 시점의 의미는 도구가 불안정적이라는 의미이며, 붙는 시점은 도구가 안정화되간다는 의미입니다.
이상으로 폭포수모델개발방법론과 애자일 개발방법론에 대한 포스팅을 마치도록 하겠습니다. 감사합니다.
Comments
Post a Comment