[TIL#40] 아웃소싱 프로젝트 팀 프로젝트 회고

팀 프로젝트 소개

•  

• 한 줄 정리 : 유저들이 자신의 하루에 대한 게시글을 올려서 서로 공유하고 댓글을 달면서 소통할 수 있는 SNS 사이트
• 내용 :

- 로그인 기능이 있어 유저별로 개인 식별이 가능하고 각자의 프로필을 설정할 수 있다.

- 로그인을 한 유저라면 댓글을 달아 서로 소통할 수 있으며 자신의 댓글을 삭제하거나 수정할 수 있다.

- 관리자는 백오피스에서 한번에 사이트를 관리할 수 있다.

- 로그인을 하지 않아도 사이트 이용이 가능하지만, 사이트에 있는 내용을 조회만 할 수 있다.

- 유저마다 자신의 고유한 페이지가 있으며 각 유저의 페이지에서 특정 유저의 게시글 조회가 가능하며 전체 페이지에서 모든 게시글을 확인하거나 자신이 팔로우한 유저들의 게시글만 확인하는 것도 가능하다.

 

 

 

 

 

팀 프로젝트 깃 허브 링크

https://github.com/ggumi030/StoryiNdayS?tab=readme-ov-file

GitHub - ggumi030/StoryiNdayS: SNS 백엔드 서버 개발

 

 

 

 

 

KPT 회고

 

Summary

KEEP 모르는 게 있으면 팀원들에게 바로 물어보는 분위기가 형성되어서 프로젝트가 빨리 진행된 것 같고 좋았다. 설계단계에 많은 시간을 들여서 기본적인 룰과 구조를 쌓고 시작한게 참 좋았다. 덕분에 설계 했던 내용들을 참고하면서 프로젝트에 속도를 낼 수 있었다. 팀원분들이 모르는 부분을 잘 가르쳐주셨고 실력적으로 부족해서 걱정하는 것을 많이 격려해주셔서 다른 생각들은 버리고 코딩에 몰두 할 수 있는 상황을 만들어 주신게 좋았다. GIt push 및 merge 규칙을 정하고 merge시 바로바로 공유함으로서 충돌 문제가 한번도 나지 않았던 부분이 좋았다.	⛳TRY 프로젝트 과정중 하루단위로 그날 발생한 트러블 슈팅을 정리한 후 일정 마지막 날에 각자의 트러블 슈팅과 해결방법 공유하도록 한다. 코드리뷰를 몰아서 마지막 날에 하려고 하지 말고 그때 그때 PR 할 때마다 한다. 절대 오류가 해결되지 않은 상태에서 푸쉬하고 머지하지 않다. 또한 클래스간 연결이 필요한 부분이 있다면 해당 담당자에게 협력을 요청하여 해결하고 진행하도록 한다. API 명세서는 팀원과 함께 작성한 하나의 약속이고, 팀원의 동의를 얻지 않은 상태에서 임의로 변경하면, 프로젝트가 조금씩 엇나가기 시작하므로, API 명세서를 반드시 따르고 변경이 필요하다고 느꼈다면 이에 대해 팀원들과 상의하여 변경하도록 한다.
❗PROBLEM 새로운 추가 기능에 도전한 점이 매우 좋았지만 그러다보니 시간이 부족해서 코드리뷰를 꼼꼼히 하지 못 한 부분이 아쉬웠다. 프로젝트 진행중 트러블 슈팅을 공유하지 못한 부분이 조금 아쉬웠다. 초반에 설계한 API 명세서와 다르게 Response 에 createdAt 을 생략하였다. 이에 반발한 모두의 의견을 다시 수렴해서 재반영했다. 역할별 코딩을 시작하고 초반에 연결오류(UserDetailsImpl에 내용이 없는 상태)를 해결하지 않은 상태로 머지하였다. 이로 인해 잠시나마 모두의 컴파일을 막아버렸다. 팀원들에 비해 부족한 실력으로 비교적 쉬운 파트를 많이 맡게 되었고 그 결과 팀원들의 부담을 덜어주지 못한게 아쉬웠다.

---

TRY /  Action Plan

1. 프로젝트 과정중 하루단위로 그날 발생한 트러블 슈팅을 정리한 후 일정 마지막 날에 각자의 트러블 슈팅과 해결방법 공유하도록 한다.

 

2. 코드리뷰를 몰아서 마지막 날에 하려고 하지 말고 그때 그때 PR 할 때마다 한다.

 

3. 절대 오류가 해결되지 않은 상태에서 푸쉬하고 머지하지 않다. 또한 클래스간 연결이 필요한 부분이 있다면 해당 담당자에게 협력을 요청하여 해결하고 진행하도록 한다.

 

4. API 명세서는 팀원과 함께 작성한 하나의 약속이고, 팀원의 동의를 얻지 않은 상태에서 임의로 변경하면, 프로젝트가 조금씩 엇나가기 시작하므로, API 명세서를 반드시 따르고 변경이 필요하다고 느꼈다면 이에 대해 팀원들과 상의하여 변경하도록 한다.