애자일
개발을 하는 사람이라면, 또는 스타트업에 종사하는 사람이라면 애자일 방법론을 한 번쯤은 들어봤을 것이다.
나도 스타트업에서 일할 때 많이 들었던 개념이고, 언젠가 내가 PO가 된다면 학습하고 적용해보고 싶었다. 개발 프로젝트에선 거의 필수적으로 활용하는 개념이라고 하기에, 우리의 프로젝트에도 적절한 방식으로 적용해보고 싶었다.
우리 팀만의 애자일
- 이튿날에는 구체적으로 MVP(Minimum Viable Product)를 만들기 위해 구현해야 할 기능을 리스트업 하고 스프린트를 어느 간격으로 어떤 목표로 할 것 인지 논의했다.
MVP 리스트업
- 페이지 단위로 기능을 세분화했다.
1. 회원가입
2. 로그인
3. 메인페이지
4. 상품 목록 페이지(전체 상품 보여주기, 카테고리 별 상품 보여주기)
5. 상품 상세 페이지(상품 정보, 결제 버튼, 수량 조절, 장바구니)
6. 장바구니 페이지(수량 조절, 상품 삭제(전체/선택), 결제하기)
7. 결제 페이지
8. 마이페이지 (사용자 정보 조회/수정/삭제, 주문 내역 조회/취소)
9. 어드민 페이지(상품 조회/추가/수정/삭제, 사용 주문 내역 조회/취소) - 그리고 세분화된 페이지를 기능군 단위로 재조합하여 스프린트 목표를 설정했다.
5/24-5/26 1차 스프린트
- 주어진 시간이 2주이기 때문에 스프린트를 짧은 단위로 할 수 밖에 없었다. 3일 단위의 스프린트를 계획했고 1차 스프린트는 5/24-5/26로 설정했다.
- 이전 포스트에서 언급한 목적형 셀은 기능군 단위로 찢어지게 된다.
셀 1(프론트A 백엔드A) > 사용자 기능 관련 구현
셀 2(프론트B 백엔드B> 상품 관련 기능 구현
셀 3(프론트C 백엔드 B > 장바구니 관련 기능 구현
- 내가 담당한 파트는 상품 관련 기능이다.
목적 조직의 단점
- 목적 조직에도 단점이 있다. 각자 담당한 서비스만 위주로 프로그래밍하기 때문에 다른 사람의 코드를 이해하기 어려울 수 있고, 또 결국은 셀 단위로 각자 맡은 일만 하다가 프로젝트가 끝나버리는 불상사가 발생할 수 있다.
- 이를 방지하기 위해 체크인 체크아웃이라는 장치를 심어놓았고, 계속해서 커뮤니케이션이 발생하면서 자연스럽게 각자가 처한 문제점, 진행상황을 쉽게 체크할 수 있다. 정말 프로젝트를 하면서 또 느끼는 거지만, 많은 시간을 뺏기지 않는다면 오버커뮤니케이션은 나쁠게 전혀 없다.
프론트엔드 개발자