[F-Lab] 공동 구매 프로젝트 스프린트 회고 ( 1회차 )

개요

'올웨이즈' 라는 공동구매 앱을 벤치마킹하여 만드는 팀 프로젝트에 대한 내용입니다.

F-Lab 이라는 개발자 멘토링 기관에서 진행하는 내용입니다.

 

요구사항 정리

유저 서비스 ( USER-SERVICE )

1️⃣ 회원가입이 가능해야 한다.

• 회원가입에 필요한 유저 정보는 아래 서비스에 따라 변경사항이 있을 수 있다.

2️⃣ 로그인이 가능해야 하며, 이 인증은 API-GATEWAY 의 프록싱을 통해 진행한다.

상품 등록 ( ITEM-COMMAND-SERVICE )

1️⃣ 상품 정보는 재고, 가격을 필수로 가져간다.

2️⃣  상품은 카테고리가 존재하며, 카테고리는 대분류만 존재한다.

3️⃣ 판매자(가게? 기업?) 가 존재한다.

상품 조회 ( ITEM-QUERY-SERVICE )

1️⃣ 인기순 상품 조회를 전체 및 카테고리별로 제공한다.

• 기준
  • 단위 시간별(24시간 ~ 일주일) 주문 성사 수

2️⃣ 낮은•높은 가격순 상품 조회를 전체 및 카테고리별로 제공한다.

주문 조회 ( ORDER-QUERY-SERVICE )

1️⃣ 나의 주문 내역을 확인 할 수 있다. 이 때 주문 성사 여부와는 상관 없다.

2️⃣ 현재 공동 구매가 열려있는 주문을 조회할 수 있어야 한다.

• 전체 및 카테고리 별로 조회 가능하도록 한다.

주문 하기 ( ORDER-COMMAND-SERVICE )

주문은 5가지 단계로 나뉘어 진다.

1️⃣ 공동 구매 진행 중

• 결제는 공동 구매 참여를 위해 필수적으로 진행된다.
• 공동 구매 실패 시 결제된 금액은 환불처리 되어야 한다.
• 한 번에 진행될 수 있는 주문 수는 모든 주문이 성공으로 끝나도 해당 상품의 재고를 넘지 않는 선으로 함.
• 공동 구매 기준이 달성 했을 때 배송 준비 중으로 상태가 전환된다.

2️⃣ 배송 준비 중

• 주문 성사 시 사장님에게 알람을 전송한다.
• 배송 준비 중인 상태에서 단위 시간동안 송장 등록이 진행되지 않을 때 주문을 자동으로 취소 되고 해당 냉용이 기록된다.
• 사장님의 송장 등록을 기준으로 배송 시작 상태로 변경된다.
  • 송장 등록 시 배송 시작 상태가 된다.

3️⃣ 배송 시작

• 배송 완료 시 외부 API 통신이 될 것을 가정한다.
• 배송 완료 시각을 기록한다.
• 이 때 외부 API 는 MOCK 으로 대체한다.

4️⃣ 배송 완료

• 구매자의 구매 확정시 구매 확정 상태로 넘어간다.
• 단위 시간이 지나게 되면 환불 불가하게 되며 자동으로 구매 확정이 된다.
• 환불 정책은 추후 결정한다.

5️⃣ 구매 확정

알림 서비스 (NOTIFICATION-COMMAND-SERVICE)

1️⃣ 공동 구매 성사 시

• 각 구매자 에게 구매 성공을 알린다.
• 판매자에게 팀 구매 성사 여부를 알린다.

2️⃣ 배송 시작

• 배송 시작시 각 구매자에게 배송 시작 여부를 알린다.

3️⃣ 배송 완료

• 배송 완료 시 각 구매자에게 배송 완료 여부를 알리고 이 때 구매확정 역시 요청하도록 한다.

4️⃣ 추후 상황에 따라 기획 추가

알림 조회 서비스 (NOTIFICATION-QUERY-SERVICE)

1️⃣ 내 알림 내역을 조회할 수 있다.

2️⃣ 내 알림 내역을 통해 주문 내역에 접속 가능 해야한다.

 

 

 

소프트웨어 구조

 

현재 F-Lab 이라고 불리는 멘토링 기관에서 멘토리을 받기 시작한지 3개월이 흘렀다. 해당 과정은 Java 백엔드를 바탕으로 개발자 성장을 초점으로 하고 다양한 기술 및 마인드에 멘토링을 진행해 왔다.

 

스프린트 KPT 회고

Keep

최근 해당 멘토링 과정의 일환으로 팀원과의 공동 프로젝트를 시작했다.

다른 파트와의 협업은 계속해서 해오고 있지만 같은 파트별 협업은 처음이었다. 둘 모두 회사 생황을 하고 있다보니 리모트로 다른 시간대에 진행하는 협업이다 보니 의사소통 방법에 대한 고민이 많았다.

뿐만 아니라 최대한 실무에 환경을 이식해서 현실에 가까운 경험을 가지고 싶었다.

그래서 프로젝트 내용을 아카이빙하고 팀원과의 의사소통 방법을 위해 회사에서 사용하던 노션을 활용한 프로젝트 보드를 사용하기로 했다. 요청 및 고정 내용에 더해 One-Board One-Issue One-Branch 방식으로 프로젝트 관리를 진행하기로 했다.

 

 

 

각 보드는 이슈별로 관리되고 그 하단에는 공통된 네비게이션을 통해 정돈된 문서관리가 가능하도록 노력하였다.

해당 문서 관리방법은 회사에 최근에 새로 입사하신 기획자분께서 시도하신 내용이 좋아보여 이식하였다.

작업 내용은 작업 과정에서 생긴 이슈를 정리하는 방식으로 진행한다. 개발 자체를 마이크로 서비스로 진행하기 때문에 Roting URI 규칙이나 Local Port 등을 공유한다.

 

 

 

 

최근 회사에 업무과정에서 이전 근무자가 작성한 코드의 의도파악이 모호하여 요구사항에 대한 아카이빙이 얼마나 중요한지를 느끼고 있다. 해당 내용을 사이드 프로젝트에서도 녹여낼 수 있도록 하였다. 추후의 프로젝트 진행과정에서도 해당 방식을 유지할 예정이다.

Problem

2주간의 스프린트 과정에서 생각보다 작업 진행량이 나오지 않았다. 작업 과정이 프로젝트 진행과 학습이 병렬적으로 진행될 때 무게를 프로젝트 보다는 학습에 두었던 느낌이다. 어쩌면 빠르게 작업하고 모르는 부분을 모아 중간 중간 휴식하는 주에 학습후 보충하는 방식이 적절했을거라는 생각이든다.

Try

작업 진행량의 문제는 사실 해당 프로젝트에 집중하지 않았던 것이 커보인다. 진행량을 키우기 위해서는 심리적 제약을 걸고 그 제약에 맞는 작업을 이어나가야 할 것으로 보인다. 추후 회차에서는 이슈별로 마감일을 설정하고 마감일에 맞추도록 하는 방식으로 작업을 진행해 나가야 할 필요가 있어보인다.현재 F-Lab 이라고 불리는 멘토링 기관에서 멘토리을 받기 시작한지 3개월이 흘렀다. 해당 과정은 Java 백엔드를 바탕으로 개발자 성장을 초점으로 하고 다양한 기술 및 마인드에 멘토링을 진행해 왔다.