[SW개발 방법] 애자일(Agile) 방법론과 프로토타입의 등장

Agile : 기민한, 재빠른, 민첩한

 

애자일(Agile) 소프트웨어 개발 선언문에 따른 애자일(Agile)의 사전적 정의는 소프트웨어를 개발하는 프로젝트 과정에서 '협력과 피드백'을 더 자주 더 일찍하는 방법론을 말합니다.

 

과거에 많이 사용하던 폭포수(Waterfall) 방법론은 소프트웨어 개발을 순차적으로 진행하는 방법을 말하는데 요구사항 분석에서 시작하여 설계, 구현, 시험, 통합, 유지보수 단계까지의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 순차적인 방법입니다. 

하지만, 많은 사람들이 프로젝트를 진행하면서 대부분 겪는 고충은 프로젝트를 처음 설계할 때, 요구사항을 정확히 정의내리기 힘들 뿐더러 요구사항은 항상 변한다는 점입니다. 소프트웨어 개발 시작은 고객의 Needs에 의해 시작되는데 소프트웨어가 만들어지는 과정이나 어려움, 시간적 비용등에 대해 잘 알지 못하는 고객은 요구사항을 정확히 표현하지 못하는 것이 대다수이며 막상 개발된 소프트웨어를 보고 요구사항을 변경하는 일이 비일비재하게 발생하게 됩니다.

 

그래서 등장하게 된 애자일 방법론은 개발 프로세스는 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능 하다는 전제를 가지고 그 전제 아래에서 합리적인 답을 내도록 하는 개발 프로세스 입니다.

 

 

 

폭포수(Waterfall)모델 [출처 : slidehunter.com]

 

 

에자일(Agile)모델 [출처 : slidehunter.com]

 

 

 

 

 

애자일 소프트웨어 개발 선언

 

- 공정과 도구보다 개인과 상호작용을

- 포괄적인 문서보다 작동하는 소프트웨어를

- 계약 협상보다 고객과의 협력을

- 계획을 따르기보다 변화에 대응하기를

 

 

 

 

 

애자일(Agile) 방법론의 종류

 

XP(eXtreme Programming) 

: 개발 방법론 혹은 개발 기법 중심의 기법이며 반복형 모델의 개발주기를 극단적으로 짧게 하여 개발자가 설계, 구현, 테스트 활동을 전체 소프트웨어 개발 기간에 조금씩 자주 실시하도록 하여 소프트웨어 변경의 비용을 최소화 한다.

 

SCRUM 

: 많이 사용하는 방법 중 하나로 프로젝트 관리 방법론 중심의 기법이며 비지니스 요구를 충족시키는 소프트웨어를 개발하는데 초점을 맞추기 위해 복잡함을 제거하는 관리 및 제어 프로세스이다. 협업에 매우 좋은 기법이고 복잡하고 정교한 제품을 생산할 수 있게 해준다.

 

RUP 

: 반복, 점진적인 개발 방법론

 

LSD(Lean SW Development) 

 

DSDM(Dynamic System Development Method) 

 

FDD(Feature-Driven Development) : 기능주도 개발 기법

 

 

 

 

프로토타입(Prototype)

 

프로토타입(Prototype)은 소프트웨어가 만들어 지기 전 가상으로 만들어 놓은 미완성 버전, 시스템의 초기모델을 뜻합니다. 시스템을 실제 설계하려면 시간과 비용이 많이 발생하기 때문에 빨리 가상으로 만들어 문제점을 즉시 알아차려 수정하고 고객이 요구사항을 시스템을 실제로 구현 하기 전 변경할 수 있도록 도와주며 프로토타입을 수정하는 과정을 사용자가 만족할 때까지 반복하면서 시스템을 개선시킬 수 있습니다.

프로토타입이란 것은 마치 무대 전 리허설 같은 느낌인데요. 실제로 쓰이는 시스템이 갖추어야 할 입력, 처리, 출력 기능등을 제대로 갖고 있지 않고 처리과정도 효율적이지 못하지만 최종사용자가 초기모델을 사용하면서 평가할 수 있고 지속적인 변화를 반영 할 수 있다는 것에 큰 의의가 있습니다.

 

 

 

 

 

 

소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비지니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니다. 그보다 변화를 극복하지 못하는 우리의 무능력이 문제다.

 

-익스트림 프로그래밍 저자 켄벡트

 

 

애자일 방법론은 변화무쌍한 소프트웨어 개발 프로젝트 설계 과정에 적용시키기 이상적인 모델이라는 생각이 들지만 실제로 적용 할 때 너무 개발자 중심의 방법론이며 너무 수정이 많고 그에 따른 관리비용이 많이 발생하는 부작용도 많이 있다고 합니다. 

모호함에 대체하기 위해 생긴 방법이 또 다시 모호함을 낳아 오히려 역효과가 날 수 있다는 말인데,

애자일 방법이라고 해서 너무 설계를 배제하지 않고 많은 수정 사항들을 잘 설계해서 변화를 반영하는 부분이 시너지를 발휘 할 수 있도록 애자일을 적용하는 것이 중요하다는 생각이 듭니다.