[BAGETTT] 1차 프로젝트

LILO Ghim·2021년 12월 12일
0

바게트는 전국의 아티장 빵가게에서 인기있는 빵을 직접 골라 담아 정기구독 서비스를 제공합니다.

> 프로젝트 개요

  • 프로젝트 취지
    GETTT(https://www.gettt.com/)를 모티브로 한 프로젝트

  • Branding

    BAGETTT라는 brand naming으로 시작,
    GETTT의 rental business를 정기구독 서비스를 제공하는 website로 기획함

  • 프로젝트기간

    21년 11월 29일 ~ 21년12월 9일(약 11일간)

  • 프로젝트 팀 구성

    • 총 5인
    • front-end 강인웅, 김재호, 원소연
    • back-end 김은혜, 이재문

> 프로젝트 목표

"Front-end와 Back-end간의 원활한 communication을 기반으로
기한(21년 12월 9일 오후 6시)내 파트별 필수 구현 기능 및 배포까지 완성하는 것으로 함"


> 프로젝트 상세

  • 구현 기능

    1. sign-up
    validator로 값 검증을 통한 회원가입(name, email, password, contact, address)

    2. 로그인시 jwt token 발급

    3. package list page
    입점 브랜드 이름으로 필터링(중복 가능), 가격순으로 정렬(브랜드 이름과 중복 가능)

    4. product detail page
    구성 제품 상세 정보(썸네일 이미지, 제품 소개 및 정보, 가격, 수량, 옵션 선택)

    5. cart
    jwt token decorator로 인가 받은 사용자만 장바구니 담기, 수정, 삭제, 보기 가능
    제품 장바구니 담기, 장바구니 전체 삭제, 부분 삭제, 수량 변경 및 저장, 장바구니 보기

    6. order(추가)
    주문 완료 페이지_최근 주문에 대한 정보 보기

    7. AWS(RDS, EC2) 배포

  • 담당 파트

    • 김은혜
      • (공통)planning : 비즈니스 기획(branding), modeling

      • ERD 작성

      • API Document 작성 > Google spreadsheets

      • raw data 생성 및 db_uploader 작성

      • API 작성
        PackageListView code
        ProductsView code
        Cart code

      • 중간 보고
        notion 페이지를 활용하여, 기능별/팀원별 진행 상황 및 소요 시간 등을 효율적으로 파악 하고 추후 스케쥴링에 참고하도록 함

      • AWS(RDS, AWS) 배포 및 시연영상


      • Keynote 및 presentation

> 프로젝트 회고

1. 팀내 역할

  • back-end part leader
  • project process & schedule 관리
  • front-end communication 담당
  • raw data 생성
  • 필수 구현 기능 API 작성
  • AWS 배포
  • presentation 기획 및 발표

2. 성과

<협업에서 team member로써의 성과>

Part Leader

  • 프로젝트의 시작부터 마무리까지의 전 과정을 직접 리드하고 관리하여 프로젝트 전반을 파악 할 수 있었고, 초기 설정한 목표를 성공적으로 달성할 수 있었음

Communication_API Document 작성

  • front-end와 프로젝트 초기에 파트별 사용하는 기술에 대한 이해를 바탕으로 한 커뮤니케이션 세팅이 필수라고 판단, API Document를 직접 작성하여 이를 토대로 주고 받는 uri, data의 형식, 저장 방식, 용어 등 overall 한 개념을 파악하기 위한 미팅을 주도하였음.
    • 이는 front<>back 간의 통신에 있어 전반적인 flow를 이해하는 작업으로써, 이후 프로젝트 마무리까지 문제 없이 원활하게 진행할 수 있었음.
    • 또한 본인이 작성한 API Document를 해당 기수 전체에 공유 함으로써 모든 팀에서 공통으로 사용하게 되는 문서의 사례가 되었음

R&R 및 process 관리

  • 상대적으로 부족한 인원 및 팀원 간 수준 및 성향 차이 파악을 선행으로, 1주차 타이트한 스케쥴 관리 및 R&R을 통해 목표 달성하고자 함
    "how?"
    1) modeling부터 필수 기능 구현에 대한 1차 결과를 6일 이내 완성을 목표로 함 -> 2주차는 수정/보완/추가기능구현/배포시간으로 관리
    2) 멤버 간 빠르게 결과를 낼 수 있는 기능 구현으로 역할 분담

<기술적 성과>

AWS(RDS, EC2)

  • AWS 클라우드 서버를 통한 배포 성공

코드 리팩토링을 위한 새로운 개념 적용

  • [RESTfulAPI의 이해]
    • query parameter, path parameter -> Get.get / Get.getlist/ <int:id>의 사용
    • 기능별 GET/POST/DELETE/PATCH의 사용
  • [조건문] : __in, Q
  • [logic] : get_or_create

3. 문제 해결 > Scrum

  • 문제 해결의 목적
    소규모 프로젝트의 전과정을 팀원 모두가 이해하고 결과를 도출하는 것을 최우선으로, 이를 위해 프로세스를 단위화한 스케쥴링과 커뮤니케이션으로 프로젝트를 진행함에 있음
  • 초기 계획 :
    • 팀원 A : 상대적으로 난이도 낮은 필수 기능 구현 & 추가기능 support, 빠르게 결과를 낼 수 있는 기타 프로젝트 관련 작업
    • 팀원 B : 필수 기능 구현 및 추가 기능 구현 전담, 배포
  • 문제 :
    • 팀원 A : 필수 기능 구현 기간 초과, 기타 역할 동시 처리 불가능
    • 팀원 B : 프론트엔트 커뮤니케이션 및 통신 전담, 프로젝트 내 역할 및 기타 업무 과다, 기능 구현 delay
  • 해결 :
    • 팀원간 진행상황 수시 communication 및 구체적인 목표 기한 설정
      예) (전) cart API : 익일까지 > (후)cart API 내 부분 삭제 기능구현 금일 9시까지 목표 > 진행 상황 공유하여 일정 수정 및 역할 변경
    • 추가 기능 구현 담당 팀원 B > A 로 전환, 기타 프로젝트 관련 업무 팀원 B전담
      "why?"
      협업으로써의 프로젝트 목표달성(fornt<->back의 커뮤니케이션, 프로젝트 완성)과 개인적인 목표 달성(개인적 개발 역량 향상)을 동시에 실현하기 위해서 팀원 모두 결과에 만족하기 위함

profile
킴릴로

0개의 댓글