커스텀 케이크 제작 의뢰 서비스
프로젝트 선정 이유
- 베이커리 시장이 점점 확대됨에 따라 규모가 1.5조까지 성장하였다.
- 베이커리 시장이 성장함에 따라 맞춤 제작 케이크 시장의 폭팔적이 성장이 이루어졌다.
- 성장하는 시장 규모와는 다르게 케이크를 맞춤제작 하기 위해서 구매자가 발품을 팔아야 하는 불편함이 존재했다.
- 현재 구매 시스템을 하나로 통합하여 제공한다면 어떨까?
개발 기간 및 인원
개발 기간
23.02.16~23.03.15
개발 인원
프론트엔드 3인, 백엔드 4인
프로젝트 진행 방식
파트 분배
저번 프로젝트에서 도메인별로 파트를 분배한게 아쉬웠다.
도메인이 섞이도록 파트분배.
스프린트
스프린트를 주 2회씩 굉장히 짧게 가져갔다.
하나의 스프린트에 하나의 목표 선정하고 해결하는 방식
매일 두번의 통합 스크럼을 통해 진행상황과 이슈를 공유했다.
fe, be 회고는 주에 한번씩, be회고는 스프린트당 한번씩 했다.
협업 도구
github proejct를 통해 이슈관리를 했다.
이슈관리와 형상관리를 같은 플랫폼에서 관리하니 편리했다.
fe, be는 다른 레포지토리에서 진행한다. -> ver2에선 모노레포로 변경 예정
내가 맡은 파트
인프라 구축, 도메인 설계, MVP모델 도출은 페어프로그래밍으로 진행
주문 확정 API
주문, 제안 삭제 API
회원, 업주별 내 주문 내역 조회 API
KPT
KEEP
- 의사결정 시 그냥 넘기거나 정하는 것 없이 나름의 근거를 가지고 정했다.
- 어떤 의견이든 타박하지 않고, 더 좋은 아이디어를 위한 토론하고 받아들였다.
- 문제가 생기면 계획을 바꾸거나 유연하게 대응했다.
- 주어진 기간보다 일찍 mvp를 완성하고 유저 경험을 조사해 사용자 경험을 개선했다.
PROBLEM
- 당장 결론이 나지 않는 주제에 토론하느라 많은 시간을 사용했다.
- 개발 중간까지 프론트엔드와 소통이 매우 적었다.
- 회고가 매번 이뤄지지 않았다.(전체 회고 또한 한번 이뤄짐)
- 초반 인프라의 에러 또는 애매한 분업으로 인해 병목지점이 발생했다.
TRY
- 다같이 무언가를 만들 때, 의견이 묻히는 경우가 있는데 귀기울여 듣자.
- fe, be구분 없이 맡은 파트가 있으면 옆에서 같이 진행해보고 싶다.
- 회고 정리를 잘하자.
마무리
첫 배포를 하고 200명이 넘는 사용자들이 사용하며 찾아낸 에러와 피드백을 통해 어플리케이션의 퀄리티를 높일수 있었다. 책임감이 매우 샘솟는 기회였고, 동시에 재밌었다.
fe를 너무 몰랐다. api 명세만 있으면 개발이 가능할거라 생각했는데 아니었다. 이걸 안 뒤로 테스트 코드를 포기하더라도 테스트서버 배포에 집중했는데, 좋은 결정이었다고 생각한다. 다음에는 mock api를 사용해보자.
개발 뿐만 아니라 기획적인 관점과 유저의 관점에서 생각하는 방법을 배웠다.
봄은 영어로 스프링