WaterFall & Agile

워터폴 방법론

• 요구사항 - 초기 단계에서 명확하게 파악
• 특징
  • 요구사항 분석 및 문서화에 시간이 오래 소요될 수 있음
  • 고객의 요구사항이나 피드백에 대한 대응이 느림
  • 적합한 경우
  • 요구사항이 매우 디테일하고 명확한 프로젝트
  • 변화가 적고 유동성이 낮은 프로젝트
  • 큰 규모의 제품 런칭, 메인 기능 개발 등에 적합
  • B2B 프로젝트 (ex. 은행권, POS, 키오스크 → 프로세스가 비교적 정확하고 요구사항 변동이 적은 프로젝트)

 

애자일 방법론

• 요구사항 - 지속적으로 요구사항을 반영
• 특징
  • 문제 해결을 위해 팀원들 간 소통과 협업 중요(문서화 X)
  • 적합한 경우
  • 사용자의 피드백을 수집하고, 빠르게 개선이 필요한 경우
  • 요구사항이 변경되거나 문제 발생이 잦은 프로젝트
  • 고객, 시장의 변화에 빠르게 대응해야 하는 기업
  • B2C 프로젝트 (ex. 게임, 배달 앱 서비스, 대부분의 앱 프로그램 → 서비스의 요구 사항이 빈번히 수정되고 반복적인 업데이트가 필요한 프로젝트)
• 장점
  • 프로젝트 계획에 걸리는 시간을 최소화
  • 반복적인 테스트로 잠정적인 버그를 쉽고 빠르게 개선 가능
  • 프로토타입 모델을 빠르게 출시
  • 비교적 빠르게 제품 출시 가능
• 단점
  • 반복적인 유지 보수 작업 → 번아웃
  • 고객의 요구 사항 및 계획이 크게 변경 될 경우 모델 자체가 무너질 수 있음
  • 공통 작업의 리소스 투입이 많음(회의, 로그)
  • 확정되지 않은 계획 → 개발 진행에 대한 정확한 이해 부족 발생 가능
• 최소 기능 제품 (MVP)
  • 최소 비용으로 빠르게 만드는 “핵심 기능” 만을 담은 제품
  • 수익성 판단을 위한 시간과 비용 절감
  • 사업 리스크의 최소화 → 실패해도 괜찮아
• 애자일에서의 Sprint
  • 팀이 일정량의 작업을 완료하기 위해 정해진 짧은 기간(주기)
  • 기업에서 보통 2주 정도의 기간
  • 스프린트 계획 회의 : 스프린트 기간 동안 해야할 일들을 정리하고 달성하기 위한 방법 회의
• 스크럼 (Scrum)
  • 제품 백로그 작성 : 고객 및 프로젝트 이해관계자들의 의견을 취합하고 업무의 우선순위를 매기는 작업
  • 스프린트 백로그 작성 : 스프린트 내에 각 팀원들이 해야 할 업무의 리스트를 만드는 작업
  • 데일리 스크럼 미팅 : 만들어진 리스트를 바탕으로 매일 진행한 업무를 보고하고 공유하는 작업
  • 개발 및 테스트 : 팀원들이 실제 맡은 영역을 개발, 테스트 하는 작업
  • 스프린트 리뷰 및 회고 : 스프린트 내에 만들어진 결과물을 통해 장, 단점을 분석하고 더 나은 방향으로 개선하는 작업
• 테스트 주도적 개발 (Test Driven Development)
  • 모든 개발이 아닌 테스트 주도적 개발
  • 모든 것을 만들고 예측하기에는 시간이 부족
  • 실제 필요한 기능만 만들고 그 기능이 제대로 동작하는지 코드 기반으로 테스트 잘 동작하는 것이 확인되면 코드 리팩토링 및 모듈화
• 데브옵스 (Dev + ops)
  • 개발 + 운영
  • 새로운 소프트웨어 기능 개선, 버그 수정 시 바로 배포함으로서 빠른 피드백 가능
  • 지속적 통합 및 연속 배포(CI / CD) 구축

 

정리

• 애자일 방법론은 Sprint 단위로 디자인 → 개발 → 테스트를 반복하는 작업
• 폭포수 개발론과 애자일 개발론은 각자 적용되는 프로젝트의 상황과 성격이 다를 수 있으며 정답은 없다.
• 애자일 방법론은 고객의 피드백에 효과적이고 유연하게 대응할 수 있지만, 반복적인 유지 보수 작업으로 인해 번아웃 현상이 나타날 수 있다.
• 애자일 프레임 워크에는 MVP, Sprint, Scrum, TDD, DevOps, CI / CD 등이 있으며 이들을 바탕으로 애자일 작업이 이루어진다.