어떤 프로젝트에서 애자일 소프트웨어 개발 방법론을 사용해야 하며,
어떤 프로젝트에서 워터폴 소프트웨어 개발 방법론을 사용해야 할까?

이것에 대해서 글을 써 보고자 한다.

그 전에 먼저 워터폴과 애자일 방법론에 대해서 간단하게 알아보겠다.

Waterfall

순차적으로
1. 요구사항 정의
2. 디자인
3. 개발
4. 테스트
5. 배포
프로세스를 진행하는 방식

Agile

빠르게 변하는 고객의 요구에 대응하기 위하여 속도/변화에 취약한 waterfall 방법론의 대안으로 생겨났다.

일정한 주기를 가지고 제품을 빠르게 출시하여 고객의 요구사항 및 변화된 환경에 맞게 요구를 더하고 수정하는 프로덕트 방법론이다.

여기서 일정한 주기를 Sprint(스프린트)라고 한다.
주로 1~4주를 한 개 스프린트 단위로 고정한다.

한 개의 스프린트별로
1. 디자인
2. 개발
3. 테스트
를 진행한다.

여러 스프린트를 지날 때, 배포 / 피드백 / 유지보수를

Up-Front 설계를 지향하는 기존 방법론 대비 Just-in-time 설계를 지향하고
경량 프로세스
문서화보다는 코드를 강조한다.
전체 팀워크를 중요시한다.

애자일의 종류?

• Scrum (스크럼)
• Kanban
• XP (eXtreme Programming)

그래서 나는 어떤 방법론을 선호하는가?

원래는 애자일
지금은 폭포수?

바로 이전의 프로젝트에서 나는 애자일한 방법론을 사용했다.
기획을 정말 빠르게 마무리 한 후 (그러지 말았어야 했다)
2주 간격으로 애자일하게 스프린트를 진행했다.

1차 개발을 마친 후 우리는 1차 기획이 뭔가 대단히 잘못되었다는 것을 깨닫고 각자 팀원들이 한 일을 하나하나 되짚어 보았다.

데이터 수집 부분에서 API를 이용하여 받아야 할 정보를 크롤링해서 받아왔다는 것을 알게 되었고,
이 사실이 큰 문제는 아니었지만
문제는 데이터의 가공 과정에서 데이터의 의미를 퇴색시켰다는 것이었다.

한 작업을 한 사람에게 일임하니 잘못된 작업이 논의되지 않고 개인의 생각 후 임의로 발생된 것이다.

해당 사항을 발견한 후 작업을 다시 수행하였다

처음부터 차근 차근 단계를 밟고, 다른 팀원들의 피드백을 받아가며 해당 작업이 수행되었다.

각설하고 애자일과 폭포수 모델을 비교하자면,
내가 이번 프로젝트를 통해 배운 것은 다음과 같다.

작은 프로젝트에는 시간적으로 부족하기 때문에 모든 과정을 반복적으로 수행하는 폭포수 모델이 좋고

큰 프로젝트에서는 추가되는 고객의 니즈에 따라 요구사항이 바뀔 수 있기 때문에 애자일하게 작은 단위를 마무리한 후, 다음 단계를 수행하는 것이 낫다..

는 것이다.

앞으로 소프트웨어 개발 방법론적인 요소들도 고려하면서 프로젝트를 구성해야 할 듯 같다.