[팜팜 프로젝트 회고]

팜팜 프로젝트 회고

2022.12.12 ~ 2023.01.11.

한 달의 시간 동안 6명의 팀원이 만든 파이널 프로젝트입니다. 소비자와 생산자를 연결하여 더욱 건강하고 신선한 먹거리를 제공 및 농작물을 기르는 데 필요한 정보와 물품 판매와 커뮤니티를 통해 소비자와 생산자가 소통하여 정보를 공유하는 플랫폼을 만들어보자해서 만들게 되었습니다. 팜팜 프로젝트를 진행하면서 좋았던 점, 아쉬웠던 점에 대한 회고입니다.

🌱 한 살 터울 팀의 탄생!

세미 프로젝트가 끝나고 팀원들과 이야기해 파이널 프로젝트도 같이 진행하기로 했습니다. 그러던 중 파이널 프로젝트에서 같이 하고 싶었던 언니들이 있었습니다. 이미 다른 분과 팀을 이룬거 같아서 포기하고 있던 차에 강사님의 ‘OO씨 뺏어와요!’ 라는 말을 듣고 파이널 프로젝트도 같이 진행하게 되었습니다.

그렇게 총 6명이 팀을 이루게 되었고 서로 자기소개를 하면서 모두 한 살 차이가 나는걸 알게되어 저희 팀명을 ‘한 살 터울’로 정하게 되었습니다.

✅ 팀 규칙 정하기

1. 탈주하는 사람 없이 끝까지 같이 하기
   마지막 프로젝트인만큼 각자 맡은 역할을 포기 없이 끝까지 잘 마무리 하자는 생각으로 정한 첫 번째 규칙이었습니다.

2. 컨디션 조절 잘해서 결석 없이 프로젝트 준비하기

3. 깃허브의 메인 머지 받고 내 파일 머지하기
   새로 들어온 언니들 조에서 세미 프로젝트 시 깃허브 이슈가 터진 적이 있었습니다. 그 때 깃허브의 중요성을 더 느끼게 되서 내 커밋을 머지하기 전에 메인 머지를 꼭 받자는 규칙을 정했습니다.

4. 내가 작업한 파일 백업 잘 해두기

5. 이름 규칙, 명명 규칙 정해서 잘 지키기

6. 각자 프로젝트 진행 중 에러 모아서 정리해두기
   각자 프로젝트 시 발생한 에러가 다른 팀원들에게서도 일어날 수 있으니 에러들을 깃허브의 discussion에 정리하자는 이야기가 나왔습니다. 실제로 제가 적었던 오류가 다른 팀원에게 도움이 되었다는 이야기를 들어 기뻤었습니다.

7. 지각하면 샘플 데이터 10개 넣기
   지각하지 말자는 의미에서 지각하면 샘플 데이터 10개 넣기 규칙을 정했습니다.

   
   

🌱 주제 선정

1. 주말농장을 주제로 하자!주말 농장을 주제로 서로 기능 분배를 하던 중 각자 파이널 프로젝트 시 구현해보고 싶은 기능이 주말 농장의 주제로는 한정적이라 주제를 바꾸게 되었습니다.
   이번 파이널 프로젝트 시 open api를 사용해보자는 의견이 있었습니다. 그래서 저희는 여러 api를 보다가 주말 농장을 하시는 분들의 잉여 생산물들을 판매할 수 있는 플랫폼을 만들어보자는 이야기가 나왔습니다.

2. 주제 다시 선정해보자!
   open api를 보면서 각자 주제를 다시 선정 해보자 해서 다시 찾아보았습니다. 서로의 주제 중 좋은 주제와 기존의 주말 농장을 포함한 주제들을 투표해보았으나 주말 농장이 다시 선정이 되었습니다. 각자 기능을 분배하고 그에 맡는 DB를 설계 후 강사님께 DB 설계의 피드백을 받던 중 결제기능에 대한 의문을 가지시게 되어 주제를 쇼핑몰로 바꾸게 되었습니다.

3. 팜팜의 탄생!쇼핑몰로 하게 되면서 각자 구현해보고 싶은 기능들인 결제, 장바구니, 채팅, 알림을 할 수 있게 되었고 각자 다시 파트를 분배하였습니다.
   이에 맞는 저희는 유스케이스 다이어그램, Figma를 이용한 와이어프레임을 만들고 명명 규칙과 매핑 주소를 정했습니다.
   기존의 농산물 거래를 바탕으로 한 쇼핑몰을 구현하기로 농사, 식물, 농장 등 이에 관련한 단어들을 이야기해보면서 팜팜(farmfarm)이라는 이름이 탄생하게 되었습니다.

✅ ERD Colud

ERD Colud를 이용해서 DB를 설계했습니다. 각자 테이블과 컬럼명을 정해서 설계했습니다. 각자 테이블을 만들고 다른 팀원의 테이블을 보면서 오타나 Type을 수정해주었습니다.

✅ 유스케이스 다이어그램

✅ 와이어 프레임 - Figma

피그마를 이용해 와이어 프레임을 짰습니다. 각자 맡을 기능에 대한 화면을 구상하고 완료 후 팀원들에게 자신의 화면을 보여주면서 설명하며 피드백을 받고 수정했습니다.

와이어 프레임을 짜면서 화면 크기를 통일 시켜주기 위해서 width의 크기를 1,000으로 고정해서 만들기로 했습니다.

✅ 명명 규칙, 매핑 주소 정하기

명명 규칙을 정해 통일성을 주었습니다.

매핑 주소를 정해서 매핑 주소의 중복으로 인한 오류를 없앴습니다.

주소에 어떠한 파라미터 값을 넣어서 전달할 지, 어떤 단어를 사용할지 등 같이 이야기하면서 정해주었습니다.

🌱 일정 관리

✅ WBS 사용하기

WBS를 작성해서 마감기한을 정해서 진행했습니다.

또한 WBS로 서로 어떤 기능을 구현 중인지 알 수 있었고 프로젝트 마감까지 남은 기한을 한 눈에 볼 수 있어서 좋았습니다.

✅ 트렐로 이용하기

트렐로를 만들어서 할 일, 일정 관리, 공지 사항, 각자 기능 등에 관한 것들을 관리했습니다.

각 카드 별로 라벨을 설정해주어서 어떤 사항에 대한 카드인지, 각자 cover 색상을 정해 본인의 카드를 구분하기 쉽게 해주었습니다.

프로젝트 끝날 때 까지 트렐로를 잘 이용해서 모든 기능들을 구현할 수 있었습니다.

🌱 디자인 및 개발을 해봅시다!

피그마에서 만든 화면을 바탕으로 화면을 만들기 시작했습니다. 미리 와이어 프레임을 만들어서 화면을 만들 때 힘들지 않았습니다.

통일되면 좋을 듯한 CSS의 root.style과 모달 창을 만들어준 팀원 덕에 디자인의 통일성 있게 구현할 수 있었습니다.

프로젝트 중 코드 리뷰를 하면서 하다가 잘 안되는 기능들은 모두와 같이 상의해볼 수 있었고, ajax를 사용해서 비동기로 구현한 기능들을 axios를 사용할 수도 있고 ajax보다 axios를 사용하는 추세라는 것도 알게 되었습니다.

하다가 잘 안되는 기능들은 팀원들과 이야기하면서 다시 작성해보고 비슷한 기능들은 다른 팀원의 코드도 공부해보면서 작성해보기도 했습니다. 그러면서 주석의 중요성도 알게 되었습니다. 주석을 단 코드들은 어떤 코드인지 다른 사람이 보아도 빨리 파악할 수 있지만 주석이 달리지 않은 기능들은 내가 작성한 코드라도 다시 봐야 했습니다.

저는 제 기능을 끝내고 다른 팀원들이 구현해둔 기능들을 실행해보면서 오류나 수정해야 하는 부분들을 알려주었었습니다. 그렇게 발견한 문제점들을 트렐로의 각자 카드를 만들어서 적어서 알려주었습니다.

체크리스트에 직접 적어주기도 하고 댓글로 알려주면서 서로의 오류를 수정할 수 있도록 했습니다.

후에 발표가 끝나고 팀원들이 이러한 점들을 미리 발견해서 수정한 덕분에 발표를 오류 없이 무사히 끝마칠 수 있었다고 이야기를 해주어서 뿌듯했던 기억이 있습니다.

🌱 느낀점 (KPT)

• Keep

  • 구현하고자 하는 기능들을 구현
    • 제가 초반 구상의 기능들을 다 구현하고 시간이 남아서 비밀 댓글 기능도 추가했습니다.
  • 트렐로를 이용해서 할 일 정리
    • 트렐로를 이용해 서로 구현해야 하는 기능들을 적어 놓고, 수정하거나 추가하면 좋겠다는 기능들을 적어 알려주기도 하며 각자 기능에 대한 체크 리스트를 만들어 관리할 수 있었습니다.
  • 회의 기록, 규칙 등 문서 남기기
    • 제가 서기를 맡아 회의 시 회의 기록을 남기는 역할을 하였습니다. 또한 명명 규칙 및 매핑 주소를 정하거나, 트렐로를 이용하는 등 문서로 남겨두어 나중에 필요 시 찾아 볼 수 있었던 점이 좋았습니다.
  • 팀원들과 원활한 소통
    • 팀원들과의 소통이 잘 돼서 개발 과정이 좀 힘들었을지 몰라도 재밌게 마무리할 수 있었습니다. 어떠한 기능에 대한 문제가 발생하거나 어려움이 닥쳤을 때 이야기하면서 해결해나갈 수 있었습니다.
  • 오류 찾아내기
    • 제 기능을 완성 후 다른 팀원들의 기능들을 직접 해보면서 수정하면 좋을 것들, 오류들을 찾아서 알려주었었습니다.

• Problem

  • 트러블 슈팅의 기록
  • 커뮤니티의 디자인이 아쉬움

• Try

  • 트러블 슈팅
  • RESTful API로 개발
  • 단순히 GET, POST 매핑을 이용하지 않고 처음부터 RESTful API로 개발을 진행할 것입니다.
  
  

🌱 다음 프로젝트 시 배우고 싶은 것들 & 지키고 싶은 것들

1. 유닛 테스트에 공부테스트 케이스를 작성하지 않았지만 저희 팀은 프로젝트 발표 전 직접 눌러보면서 오류를 발견해서 수정을 해주었기 때문에 발표 당일 오류가 발생하지 않았지만 다른 조에서 오류가 발생하는걸 보고 테스트의 중요성을 알게 되었습니다.
   유닛 테스트를 공부해서 테스트 케이스를 만들어 보고 싶습니다. 팜팜 프로젝트에서는 직접 실행해보지 않으면 제 의도대로 코드가 작성되고 있는지 아닌지 확인해볼 수 없었습니다.
2. 트러블 슈팅을 만났을 경우 기록해두기
   트러블 슈팅을 만났을 경우 기록을 해둘 것입니다. 이번 프로젝트엔 기록을 해두지 않아서 어떤 문제를 만났었는지 회고를 하는데 어려움이 있었습니다. 다음 프로젝트 시 기록을 해두어 나중에 해당 문제를 보았을 때 그에 대한 다른 해결 방법도 고민해볼 수 있도록 기록해둘 것입니다.
3. 문서화 해두기
   팀에서 정한 규칙들이나 회의 기록들을 문서화 해두어서 언제 어떤 이야기를 나누었고 언제 무엇을 수정했는지 등 알 수 있어서 좋았습니다.
4. 반응형 웹 만들어보기
   각자 구현하는 기능들이 많아 반응형 웹을 구현해보지 못했습니다. 그래서 다음 프로젝트에선 반응형 웹사이트를 만들어 보고 싶습니다.