안녕!
우아한테크코스 5기 [스탬프크러쉬]팀 깃짱이라고 합니다.
이번 포스팅에서는 1차 데모데이까지 기획을 하고, 이후에 본격적인 개발을 시작하며 처음으로 해봤던 일정 추정에 대해 기록해보려고 합니다.
💋 우리팀의 소프트웨어 개발 문화 만들기
✔ 스프린트 방식 채택
우리 팀은 개발 방식으로 스프린트 방식을 채택했다.
우테코 데모데이가 2주를 단위로 진행되기도 하고, 소프트웨어 개발은 수시로 요구사항이 변경되기 때문에 매 스프린트마다 새로운 계획을 세울 일이 많다고 생각했기 때문이다.
따라서 아래와 같은 규칙을 정했다.
✔ 스프린트 방식에 따른 구체적인 규칙 정하기
이 방식을 완벽한 스프린트 방식이라고 하기 어려울 수도 있지만, 방식에 얽매이지는 않으면서도 최대한 필수적인 절차들은 강제하기로 했다. 예를 들면, 데일리 스크럼에서 오늘 할 일과 어제 한 일에 대해서 각자 이야기하고, 언제까지 어떤 작업을 완료할 지에 대해서 정했다.
두 번째 스프린트가 시작한 지 하루 지난 7/11 화요일 저녁에 첫 스프린트 플래닝 미팅을 했다.
1차 데모데이에서 우리 팀이 2차 데모데이까지 개발하겠다고 발표했던 내용을 정리하고, 각자 얼마나 시간이 걸릴 지에 대해서 논의했다.
💋 일정 추정
✔ 할 일에 대해서 데드라인 정하기
처음으로 일정을 추산하는 거라서, 좀 까다롭긴 했는데 일단은 조금 빡빡하게 말하고 최대한 하는게 목표였다.
위에 적은 API 명세, 엔티티 설계는 결국 해냈다.
✔ 칭찬: N빵을 현명하게 잘했다.
엔티티 설계가 금요일에 끝난 바람에 금방 주말이 와버렸다.
다른 팀들은 인수테스트 작성이나, 처음에 좀 패키지 정리나 계층의 뼈대라도 잡힌 뒤에 찢어져서 각자 개발하는 경우가 많았던 것 같은데 우리 백엔드 4인방은 간단히 정해놓은 코드 컨벤션만 갖고 주말을 맞이했다.
우리 서비스는 쿠폰, 카페, 사장님, 고객, 쿠폰의 정책과 디자인 등등 도메인에 엄청나게 많은 개념이 들어있다.
따라서 테이블이 약 20개 정도 나왔는데... (아래 사진 참고, 다 읽지는 않아도 됨)
무튼 그래서 백엔드간 할 일을 나눠 가질 때 최대한 merge conflict를 방지하기 위해서 각 요구사항이 구현 시에 건드릴 테이블을 생각하면서, 최대한 겹치지 않도록 요구사항을 분배했다.
아래는 어떻게 요구사항을 분배했는지에 대해서!
1 제나
전화번호로 고객 조회
customer *
임시 가입 고객 생성
customer, temporary_customer
2 하디
사장님 카페 조회 / 등록 (중상)
owner → cafe → cafe_policy, cafe_coupon_design + cafe_coupon_coordinates
고객의 리워드 조회
reward
리워드 사용
reward
3 깃짱
카페의 쿠폰 디자인 및 정책 수정 → 기존 디자인 및 정책 soft delete 걸어야함 (상)
owner, cafe, cafe_policy, cafe_coupon_design + cafe_coupon_coordinates
스탬프 개수별로 샘플 이미지 조회 (최하)
sample *
4 레오
고객의 현재 카페의 스탬프 쌓고 있는 쿠폰 있는지 조회, 쿠폰을 카페 아이디로 필터링
customer *, coupon
사장의 고객 목록 조회
customer *, coupon
월요일에 다같이
고객에게 쿠폰 신규 발급 A → 나중에 페어로
coupon, coupon_policy, coupon_design, coupon_stamp_coordinates
스탬프 적립 A → 나중에 페어로
스탬프 적립하고 그냥 끝
스탬프 적립하다가 딱 리워드 발급만 된 경우
스탬프 적립하다가 리워드 발급 기준을 초과해서 리워드 발급되고 나머지 스탬프는 새로운 쿠폰에 찍어줘야 하는 경우
stamp, coupon, reward
기타 업무
CI, CD 설정
더미데이터 생성 ⇒ 일단 local에서만
인수테스트 작성
💋 1차 데모데이의 피드백 검토
우리 팀의 피드백은... 실제 사용자를 어떻게 모을 것이냐였다.
카페 사장님이 필요한 서비스기도 하고... 발표에서 일단 패기있게 카페 30곳에 사용자 450명이라고 발표하긴 했지만,
당시에는 진지하게 생각하지 않았는데 예상 사용자 수에 따라서 소프트웨어 개발이 달라질 수 있다는 피드백을 받았다.
ㄹㅇ 생각도 못했던 포인트...
조금 꺾었다. 일단 기능 구현에 집중해야 할 것 같다고 생각했다.
그리고 좀 더 우리의 기획에 대해서 구체화했다.
페인 포인트가 뭔지에 대해서 좀 더 구체적으로 정리했다.
페인포인트 정리는 아래로!
💋 2차 데모데이 일정 추정에 대한 나의 피드백
✔ 칭찬
다른 팀들의 경우에 4인페어로 어느정도 패지키 정리나, 메서드 클래스 네이밍 등등을 미리 만들고 각자 구현에 들어간 경우가 많았는데, 우리 팀은 시간 관계상 주말에 각자 구현을 시작했다.
정해진 테스트 템플릿도 없어서 약간 막막한 기분이 들었는데, 그래도 백엔드 4인 모두가 계획된 시간 안에 각자 API를 구현해와서 매우매우 칭찬한다.
✔ 개선점
아무래도..ㅋㅋ 스프린트 전체의 요구사항을 너무 크게 잡았던 것 같다.
변명을 해보자면, 1차 데모데이 전까지 했던 기획이 주로 사용자 관점의 서비스로 일어나서, 편하게 빨리 보기 위해서 피그마로 사용자 페이지 정도를 시각화해서 각자 생각하는 점을 동기화했었다.
그러다보니 요구사항도 페이지를 기준으로 나오게 되고, 프론트엔드 기준으로 요구사항이 만들어졌었다.
그걸 기준으로 앞으로 남은 기간 중 1/3의 기간이므로 1/3만을 하겠다고 발표를 했었다.
나중에 발표한 내용을 보면서 백엔드의 할 일을 정리해 봤더니, 어떤 느낌이었냐면...
전체 테이블에 대한 연관관계를 모두 구현해 놓고, 각 도메인의 CRUD 중 CR만 뚫어 놓은 느낌..?
어쨌든 전부 다 만들어야 했던 것이었다.
백엔드가 좀만 더 빠르게 도메인과 연관관계를 정리했더라면 더 현실적인 전체 목표를 정할 수 있었을 것 같다.
이번에는 잘 모르는 상태로 일단 하겠다고 말해버려서 주말에 아주 바쁘게 무리스럽게 했었는데, 앞으로 일정 추산으로는 우리가 어느 정도를 할 수 있을 지에 대해서 좀 생각해보게 되었다.
