실무에서 사용되는 폭포수, 애자일 개발

학부생 시절 소프트웨어공학을 공부하거나

 

아니면 정보처리기사, 정보처리산업기사를 공부하던 중 소프트웨어 개발방법론을 봤을것이다.

 

가장 대표적인 폭포수와 애자일

 

폭포수는 설계를 완벽하게 하고 진행을 한다는 개념이며

 

애자일은 제품을 대충 빨리 만들어내고 고객에게 보여주고 피드백을 받고 다시 개발을 진행한다는 개념이다.

 

한국의 경우에는 대부분의 폭포수 모델로 개발을 한다고 알려져있다.

 

나도 경험이 많지는 않지만 애자일로 개발한 적은 아직 없고 

 

폭포수로만 개발을 했다.

 

 

 

폭포수를 가장한 애자일?  or 애자일을 가장한 폭포수?

폭포수로 개발을 진행하다보면 어느 시점에 가면 서서히 제품의 완성본이 눈에 보이기 시작하는데

 

이때부터 폭포수의 본질을 벗어나기 시작한다.

 

제품을 고객과 협의한대로 구현해내기 시작하고 완성본이 드러나기 시작 할 때쯤이면

 

고객측에서 불만사항이 나오기 시작한다.

 

"이거는 별로에요", "이거는 빼주세요", "이런게 더 있었으면 좋겠어요" 등등

 

분명히 협의한대로 구현을 했지만 나중에 가면 말을 바꾸기 시작한다.

 

고객 본인도 제품이 나오기 전까지는 뭐를 원했는지 정확히 모르기 때문이다.

 

그러다가 보면 폭포수로 진행하여 개발하던 방식에서 점점 애자일 방식으로 움직이게 된다.

 

고객쪽에서 바꿔달라고 한 부분을 바꿔주고 보여주고 또 불만사항을 이야기하면 또 다르게 수정해주게된다.

 

심지어는 몇달간의 협의를 거쳐 만들어진 표준도 무시하게 된다.

 

"저희는 표준 필요없으니까 저희파트는 저희가 해달라고하는대로 해주세요"라고...

 

앞에서 분석을 위해 투자했던 시간이 의미가 없어지게 된다.

 

 

 

뛰어난 개발자를 선도개발시켜야한다.

프로젝트의 각 팀마다 실력이 뛰어난 개발자들이 있다.

 

내 생각에는 이러한 개발자들 몇명을 뽑아서 선도개발을 시킨뒤 

 

애자일방식으로 대충 제품을 만들어서 보여주고 고객의 피드백을 받은 뒤에

 

폭포수 모델로 개발을 진행하거나 표준을 잡는 등의 작업이 필요한 것 같다.

 

처음부터 폭포수 모델로 개발을 진행하다보면 고객도 본인들이 무엇을 원하는지 제대로 알지 못한 상태로

 

설계에 들어가기 때문에 프로젝트에 효율성이 떨어지는 것 같다.

 

물론 대형 프로젝트의 PM, PL들은 개발에 대한 경험은 거이 없고

 

프로젝트 일정표만 보며 숫자놀이만 하고 있기 때문에

 

이러한 부분의 중요성에 대해서는 알지 못 할 것이다.