[ Project 01 ] WCF SHOP Sprint 2 회고

✌️ 웹사이트 시연 영상
😼 Github

2주간의 프로젝트를 마무리하며 첫 번째 프로젝트, WCF SHOP의 Sprint2 회고를 적어본다. Sprint1에서 가지고 있었던 문제들을 개선하려고 노력했던 시간이었다.

🎯 목차

• Planning Meeting
• API개발
• 프로젝트 마무리
• 회고록
• 느낀점

---

Sprint 02 : 남은 기한과 지금까지 진행한 작업을 바탕으로 최종 목표 조율 하기

Planning Meeting 2

우선 Trello를 보면서 Sprint1에 계획했던 업무들의 진행 척도를 확인했다. 이를 통해 발견한 팀 전체의 문제는 Trello에 있는 모든 업무 티켓을 In-Progress로 옮겨두고, Complete한 업무가 없었다는 점이었다. (한 마디로 업무를 찍먹했다)

멘토님께서 업무를 진행할 때는 1) 하나의 티켓이 Complete하게 되는 것을 목표로 진행하고, 그 이후 다음 업무를 시작하는 것 그리고 2) Trello의 티켓을 세분화 해서 사용하는 것이 옳은 방법이라는 조언을 주셨다.

이를 바탕으로 Sprint 2의 목표를 세웠다.

• 필수적으로 구현해야하는 기능들을 중심으로 업무를 진행하기
• Trello의 모든 티켓을 Done으로 옮기기
• 수요일 : 주요 기능들 완수하기
• 목요일 : 프론트-백엔드 통신 및 발표 준비

---

API 개발

Sprint2에서 개별로 작업했던 API는 상품 리스트 GET 그리고 상품 상세조회 GET 였다. 아래 내용은 각 API를 만들 때 어려웠던 점들을 어떻게 해결했는지 작성해보려고 한다.

💡 Sprint1 과 비교해서 달라진 점이 있다면! 
개인 업무 진행한 내용도 기록해두는 습관이 생겼다. 

상품 리스트 API 📚

상품 리스트 API의 기능

• 사용자에게 상품에 대한 간략한 정보 (이미지, 브랜드 명, 가격 등)를 제공 한다.
• 상품 리스트 필터링 (브랜드, 사이즈, 가격)
• 상품 리스트 정렬기능 (신상순, 높은 가격순, 낮은 가격순)

업무 기록 남기기

프론트와 소통을 통해 API를 만들기 위해 필요한 Data가 무엇인지, 상세 기능에 필요한 것은 무엇인지, 진행 사항등을 기록 했다.

기본 기능들을 구현하고 고도화된 필터링 기능이 필요하다는 것을 발견했다. 필터링과 정렬의 기준이 다양하고 중복을 허용해야 해서 경우의 수가 많았다..(어려웠다)
하지만, 필요한 기능등을 list up하며 하나씩 차근 차근 해결했다.

결과물

상품 상세 조회 API 👚

상품 상세 조회 API의 기능

• 특정 상품에 대한 정보(사이즈, 가격, 상품 이미지, 할인 정보 등) 제공

업무 기록 남기기

상품에 대한 모든 정보를 제공하는 기능이라 하나의 API로 정보를 어떻게 전달하면 좋을까? 고민을 많이 했었던 것 같다. 그 답안으로 sub-query를 사용해서 SQL구문을 작성해 API를 완성할 수 있었다.

API 완성 후 상품별 다양한 이미지를 제공할 수 있도록, 팀원들에게 미션을 제공하며 데이터 수집을 풍성하게 할 수 있었다✌️

결과물

보완: 이미지 렌더링 시간 단축하기 ⏰

프론트와 중간 통신을 통해 이미지를 렌더링하는데 시간이 오래 걸린다는 것을 발견했다. 구글 드라이브 및 이미지 별 url 생성등의 노력을 했지만 번번히 실패했다. 이후 찾은 방법이 AWS의 S3 서비스 였다. S3에 이미지를 저장하고, 제공되는 이미지 url을 활용했더니 렌더링 시간을 단축할 수 있었다!

---

프론트와 통신

프로젝트의 하이라이트이자 마무리 단계인 통신! 우리 팀은 마지막에 최종 TEST하기 전에 규칙 아닌 규칙을 만들었다. 해당 과정이 있었기에 통신에 있어 큰 어려움이 없었던 것 같다.

WCF팀의 규칙📌

• 필요한 Data는 프-백 담당자가 미리 협의 해두기
• 백엔드 API와 프론트 담당자의 레이아웃 및 기능이 완성 되면 중간 통신을 통해 필요한 부분을 조율하기
• 백엔드는 상시적으로 API Documentation을 작성 및 수정해서 프론트와 공유하기

---

KPT 회고

💡 Sprint1과 비교해서 달라진 점, KPT 회고 방식을 도입했다. 

팀원들과 1차 프로젝트를 마무리하며, KPT(Keep, Problem, Try)방식으로 회고를 진행했다.

• Keep : 잘하고 있는 점, 계속 했으면 좋겠다 싶은점
• Problem :뭔가 문제가 있다 싶은점, 변화가 필요한 점
• Try : 잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들

WCF Team 👨‍👩‍👧‍👧

• Keep

  1. 노션 정리를 통해 미팅이 수월하게 진행 됐다.
  2. 공유 자료들을 보고 논의하며 프론트와 백엔드의 소통이 잘 이루어 졌다 (ERD, API Documentation)
  3. 팀원들끼리 서로 존중하며 의견 수렴 및 협의가 원만하게 진행 됐다.

• Problem

  1. 팀 내 코로나 확진 및 건강 관리가 부족했다. (체력)
  2. 프로젝트 초반 Sprint에 대한 이해도가 부족해서, 다양한 업무를 한꺼번에 진행해서 업무 추진도가 더뎠다.

• Try

  1. 개인 체력 관리하기 (운동)
  2. Trello 카드 세분화 하기, 한 업무를 끝내고 다음 업무를 진행함으로 업무 추진도 높이기

개인 회고 🙆🏻‍♀️

• Keep

  1. 주도적으로 팀 노션을 만들고, 회의록등을 정리해 팀내 원활한 소통을 할 수 있도록 도움을 줬다.
  2. 프론트에게 ERD(Data Modeling)을 설명하고, API Documentation을 적극적으로 공유하며 통신에 있어 어려움을 줄일 수 있도록 노력했다.

• Problem

  1. 백엔드 팀원이 재택근무를 진행하면서 진행 상황 등에 대한 공유가 부족했다.
  2. 팀 전체의 흐름 보다는 내 역할에 조금 더 몰두 했다.

• Try

  1. 팀 전체 Daily StanUp Meeting과 백엔드 팀 미팅 진행하기, 재택근무와 같은 상황이 다시 발생하게 되면 잘 구비된 Tool(TeamViewer, Zoom)등을 적극 활용해 소통의 질을 높이기
  2. Trello를 꾸준히 확인해서 팀 전체 흐름을 파악하며 프로젝트를 진행하기

---

느낀점

1. API를 개발하면서 비즈니스 로직은 단순히 개발 하는 것이 아닌 유저의 입장에서 생각하고 기능을 구현하는 시각이 필요하다는 것을 느끼게 됐다.
2. 프론트와 백의 통신에 있어 소통의 중요성을 느끼게 됐고, 전체적인 흐름을 이해하는 자세도 필요함을 깨닫게 됐다.
3. 내가 아는 것을 남에게 잘 설명하는 개발자가 되고 싶다는 생각이 들었다.

🔥 WCF TEAM 너무 고생 많았어요 🔥