워터폴 방식 vs 애자일 방식 (스프린트, 스크럼)

프로덕트를 개발할 때, 대표적인 두 가지 방식. 가장 기본적인 내용이지만, 워낙 설명도 방대하고 헷갈려 다시 명확하게 정리하고 실무에 적용 하고자 다시 개념정리차 작성해보는 게시글이다. 

 

워터폴 방식

기획 - 디자인 - 개발 - QA 순으로 하나씩 순차적으로 진행되는 방법

쉽게 말하면, 기획 끝내고 디자인, 디자인 끝내고 개발, 개발 끝내고 QA 진행한다.

서비스 기획자, 디자이너, 개발자 이렇게 서로 빈번한 커뮤니케이션 없이 자기 맡은 일만 깔끔하게 잘 하면 되는 방식.

 

예를 들어, 상품을 등록, 수정, 삭제할 수 있는 백오피스를 개발한다는 프로젝트일 때,

등록, 수정, 삭제에 대한 모든 기획이 끝난 이후에 디자인, 개발하여 백오피스를 최종 완성한다는 개념이다.

 

하나의 단계가 끝난 결과물을 바탕으로 다음 작업이 진행되기 때문에,

중간중간 수정이 어려우며 최대한 꼼꼼하게 기획서를 작성하는 것이 가장 키포인트가 된다.

디자인이 한창 진행되고 있는 와중에 기획 변경 사항을 전달하면, 원칙을 깨고 진행하는 방식이 되는 셈이다.

 

스타트업에서 워낙에 '애자일하게~ 애자일하게~' 라고 하기 때문에, 살짝 전통적인 느낌인가 싶을 때도 있는데,

요구사항이 명확하고, 변동이 적은 프로젝트는 오히려 워터폴 방식이 유용하다. (ex. 백오피스 개발)

 

애자일 방식

기획 - 디자인 - 개발 - QA를 작은 기능 단위로 쪼개서 반복적으로 실행하는 방법 

예를 들어, 신규 회원가입율을 높이기 위한 프로젝트를 진행하며, 

이를 위해 배너 구좌, 신규 온보딩 페이지, 리퍼럴 기능을 기획한다고 까지 아이데이션이 되었다고 가정해보자.

 

워터폴 방식은 이 모든 기능에 대해서 하나하나 요구사항 정의, 화면 설계를 마치고, 디자인-개발을 거쳐 신규 회원가입 증진 프로젝트으 ㅣ최종 배포가 되는 반면, 애자일 방식은 배너 구좌 먼저 기획-디자인-개발- 배포를 진행하고, 유저 반응을 보고 그 이후 신규 온보딩 기획을 진행할지 결정한다던지, 3번의 스프린트를 걸쳐 온보딩페이지 고도화를 진행한다던지의 방식을 취한다.

 

기획 - 디자인 - 개발 - QA를 작은 기능 단위로 쪼개서 반복적으로 실행하기 때문에,

신규 온보딩 페이지에 대한 디자인 작업이 진행되고 있을때, 리퍼럴 기능에 대한 기획이 언제든지 바뀔 수 있다는 점이다.

따라서 요구사항이 자주 바뀌거나 변동이 많은 프로젝트에 적합하며, 이에 대응하는 속도와 유연성이 중요하다.

 

 

 

이 애자일 방식을 취할 때, 핵심적인 관리법이 바로 스크럼 - 스프린트인 것이다.

 

스프린트 관리

애자일 방식에서 짧은 호흡의 기획-배포 과정을 동시다발적으로 진행하기 때문에, 이를 체계적으로 관리하는 시스템이다.

스프린트 진행 과정은 다음과 같다.

 

 

백로그 작성 및 요구사항 정의

• 이해관계자들로 부터 개발할 기능 또는 제품에 대한 요구사항을 우선순위로 정렬.
• 제품의 개발 방향을 작성해야하는 관점을 작성하는 것 (회사 매출 / 제품의 가치 등 그때그때 적용해야할 내용 반영)

 

계획 (플래닝) 

• '우리는 왜 이번 스프린트를 진행하는가?'에 대한 한마디 답을 내리는 과정.
• PO가 스프린트 목표 제안, 각 팀은 협의하여 결정 
• 백로그에서 스프린트에 포함할 항목을 정함.
• 항목을 테스크 단위로 세분화, 작업을 수행할 방법과 순서를 계획
• 스프린트 플래닝 미팅 목표
  • 하나의 스프린트 목표
  • 팀원의 목록
  • 스프린트 백로그 관리
  • 확정된 스프린트 데모일
  • 확정된 일일스크럼을 위한 시간과 장소

 

PRD 작성, 요구사항 정의 등 문서작업

 

PRD란, Product Requirements Documents로, 프로덕트에 대한 요구사항을 정리하여 출시하기 위한 가이드 문서다. 기존 기획서와 달리 세부 기능에 대한 정의보다, 목적과 방향에 대해 정의하여 자율성을 보장하는 것이 가장 큰 차이점이다.

 

플래닝 미팅 때 나눴던 이야기를 바탕으로, 구체적인 요구사항 및 스콥 때에 따라 와이어프레임 작성을 문서화하여 팀원들에게 공유한다.

그사이 디자이너, 개발자와 구현 가능한 대략적인 일정에 대해 픽스를 받는다. (희망 일정을 먼저 전달하고, 같이 확인하는 방식으로)

 

구체적인 작성법에 대해서는 추가 게시글을 업로드하여 보충하겠다. 

 

 

 

개발 (데일리 스크럼)

• 매일매일 데일리 스크럼으로 진행사항 파악 및 세부 이슈 공유
• PRD 문서에 따른 디자인-개발 진행

 

 

 회고

• 스프린트 프로젝트의 방법에 대해서 개선점 파악