기초 프로젝트 최종 팀 회고

[miju-seaweed]

왜 회고를 해야 하나요?

바쁘고 치열하게, 또 잘 버티고 있는 스프린트 16기 여러분!

매주 팀 단위로 회고를 하며 어떤 점이 좋았고, 어떤 점이 아쉬웠고, 아쉬웠던 부분은 어떻게 개선해볼지 함께 이야기해보면
그 다음주에는 더 나은 프로젝트를 진행할 수 있을거예요. 회고를 통해 함께 성장해보아요 🔥

회고 시간만큼은 솔직한 생각, 마음을 터놓기
솔직한 회고를 통해 다음주는 더 즐겁게 프로젝트를 진행할 수 있을거예요.

회고 방법

회고는 “KPT 회고” 방식으로 진행해볼거예요. 아래 방법대로 회고해주시면 됩니다.

• 팀원들과 모여 그 주의 팀 프로젝트 활동을 돌아보며, '좋았던 점(Keep) / 아쉬웠던 점(Problem) / 시도해볼 것(Try)'으로 항목을 나누어 회고해주세요.
  • Keep : 현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분
  • Problem : 현재 우리팀이 가지고 있는 문제
  • Try : Problem에 적은 것을 해결하기 위해 우리 팀이 다음에 시도해볼만한 것 (혹은 Keep 중에서도 더 개선하거나 시도해보고 싶은 것)
• KPT 회고 피그마 템플릿을 활용해서, 팀 회고를 진행하셔도 됩니다.
  • 단 템플릿 사용시, 팀별로 복제해서 사용해주세요. 꼭 템플릿을 사용하지 않아도 되니, 팀별로 편한 방식으로 회고를 진행해주세요.
• 이번주 일요일까지, 팀 회고한 내용을 정리하여 댓글로 올려주세요.
  (댓글에 예시 회고를 올려드릴테니, 참고해주세요. 피그마 템플릿으로 진행하셨다면 캡쳐본을 올려주셔도 돼요.)

참고글

• KPT 회고란 무엇인가?
• 팀문화의 탄생

[miju-seaweed]

🍀 0팀 (예시)

Keep

• 미팅 시간 약속을 모두 잘 지켜준다.
• 프로젝트 과정에서 기술 고민을 함께 하는 것이 서로의 학습에 도움이 된다.
• 새로운 제안을 했을 때, 모두 개방적으로 의견을 들어주어서 고맙다.
• 위워크에 모여서 하다보니, 프로젝트 진행이 빠르게 잘 이루어진다.

Problem

• 커밋 메시지가 명시적이지 않아서, 서로 어떤 작업을 했는지 파악하기 힘들었다.
• 급하게 코드를 작성하느라, 폴더 구조가 이상하다.
• 서로를 너무 배려하느라, 의견을 더 많이 나누지 못한다.

Try

• 협업을 위해, 커밋 메시지를 더 구체적으로 작성한다. (커밋 메시지 규칙 정하기)
• 폴더 구조를 다시 논의하여 폴더 구조 규칙을 만들고, 규칙에 맞추어 파일을 배치한다.
• 각자 하루에 한 번 이상 의견을 낸다.

[minji9029]

🍀 1팀

Keep
어려움이 있을때 원활한 소통을 통해 해결함
코어타임을 잘 지켜줌
각자 맡은 역할을 책임감있게 함
자주 소통하면서 진행상황을 확인함

Problem
코드리뷰 부진
리팩토링 부진
상태관리 툴을 사용하지 않음

Try
코드리뷰활성화
리팩토링 활성화
Redux 사용해보기

[Luganic]

🍀 4팀

Keep

• 효율적인 분업화와 전략으로 적은 팀원수에도 빠른 진행률
• 팀미팅 시간 준수와 높은 참여도로 팀원 각 진행율 및 파악 원활
• 중도하차 인원 발생에도 역할 재분배 및 역할 조정으로 빠르게 대응
• 새로운 기능 구현과 개념에도 팀원 모두 주저하지 않고 시도하여 자신감 상승

Problem

• 코드리뷰 시간을 갖지 못해 코드 품질 검토 및 개선 기회 부족
• 정해진 시간 외에 방향성, 어려운 점 등 프로젝트 관련 소통이 부족
• 완전한 분업화로 다른 팀원의 작업 흐름 및 전반 구조 이해 어려움

Try

• 효율적인 시간 분배와 전략을 미리 짜서 서로 코드리뷰 시간을 가짐으로써 다른 팀원 작업 흐름 및 전반 구조 파악하기
• 이슈가 있으면 기록하고 서로 공유하는 시간 가지기
• 프로젝트를 통해 얻는게 무엇인지 다시 한번 생각해보기

[Chiman2937]

😊 2팀

Keep	Problem	Try
데일리 미팅 진행을 꾸준히 진행했고완료 / 진행중 / 장애물 등을 매일 공유하면서 우선순위 선정, 작업 재분배 등이 유연하게 진행되어서 좋았다
기능 구현에 대한 아이디어를 구현하는 추진력이 좋았다
초기에 vercel 배포를 통해 개발 환경을 직접 보면서 확인할 수 있어서 원활한 진행 좋았다
코드리뷰하면서 다른 사람 코드 파악 능력이 향상되었다
초기에 공용 컴포넌트를 제작하면서 사용성에 대한 고민을 꾸준히 하고, 실제 사용하는 팀원들과 피드백, 개선 과정이 빠르게 이루어졌다.
초기에 팀 컨벤션을 세부적으로 잘 작성했다.	기능 구현을 우선하여 작업에 몰두하다보니 중반 이후 컨벤션이 관리되지 못한 부분이 있다	더 디테일하게 설정하고, 숙지하고 시작한다그 외에 자동화할 수 있는 것들을 최대한 적용시켜본다.
코드리뷰 담당자 분배했는데 모든 팀원들이 책임감 있게 코드리뷰를 진행해서 작업 일정에 지연이 발생하지 않았다.
팀원 업무 분담이 잘 이행되어 일정에 지연이 발생하지 않았다
	프로젝트 초기 설정이나 자료준비가 더 원활했으면 매끄러웠을 거 같은데 뭘 해야할지 감을 잡지 못한 부분이 있었다
	테스트를 잘 진행하면서 프로젝트를 진행했다고 생각했는데, 시연 준비하다가 오류가 확인 되어 마무리 작업이 촉박한 점이 있었다	테스트 케이스를 세분화해서 체크리스트를 만들어 디테일하게 체크하면 더 빨리 체크할 수 있었을 것 같다.
	공용 컴포넌트의 경우 기능 수정하면서 사이드 이펙트가 발생한 경우가 있었다	코드 레벨로 격리하여 별도로 관리하는 방법을 고민해봐야 할 것 같다.
	시간 부족으로 검색기능, 다크모드 등 기능 차별화에 시간을 투자하지 못했다.
	공용 컴포넌트의 경우 기존에 사용하던 컴포넌트에 영향을 주지 않는 수정 방식에 대한 고민이 많았지만 만족스럽게 반영되지는 않은 것 같다.
	주석 작성에 대한 아쉬움	내가 작성한 코드에 대해 타인의 피드백을 받아보고, 주석의 장단점에 대해 생각해봐야겠다.
	타인의 피드백
	프로젝트를 진행할 때 고객 페르소나에 대한 고민이 부족했다	다음 프로젝트를 진행할 때는 고객 페르소나에 대해 더 깊이 고민하여 프로젝트의 방향 및 목표를 명확하게 설정해 보아야겠다.
API를 테스트하는 페이지를 구축하여 작업 효율이 상승하였다.
	기초 프로젝트이다 보니 제시된 기능만 구현하려고 했고, 서비스 기획에 대한 고민 (방향성)이 부족했던 것 같다.	주어진 서비스 기획이 있더라도 어떤 문제를 해결하고자 하는지 팀에서 재구성
	PR을 올릴 때 변경사항에 대한 커밋을 한번에 진행 한 경우가 많았다.	커밋을 한번에 진행할 때와 나누어서 진행할 때 장단점을 고려해보기
	브랜치 분기를 하지 않고 작업한 경우가 많았다	분리해서 작업을 해보고, 어떤 장단점, 어려운 점이 있는지 느껴보기
	github issue 와 notion timeline을 연동해서 일정을 관리해보려고 했는데큰 단위로 나눴다보니 타임라인이 크게 의미가 없었음	마일스톤 단위를 세분화해서 더 관리하기 좋게 작업해보고 싶다
	아직 실력이 부족하여 프로젝트에 적극적으로 참여하지 못했다	기능 구현에 크게 기여를 하지 못하더라도 할 수 있는 것을 찾아 해보자 (UI 디테일, 기획 디테일)

[kimin0401]

🍀 8팀

Keep

• 미팅 시간 약속을 모두 잘 지켜준다. 데일리 스크럼에 모두 성실히 참여해주었다.
• 새로운 제안이나 피드백을 자유롭고 정중하게 해주어 건전한 팀 활동이 되었다.
• 혼자서는 해결 못할 문제를 다 같이 고민해보고 해결해보려고 했다.

Problem

• 구현할 기능이나 디자인에 너무 집중하여 성능 개선에 소홀했다.
• CLS를 잘 고려하지 못했다.
• 후반에 수정사항에 너무 집중하여 발표준비에 충분한 시간을 투자하지 못했다.

Try

• 첫 팀 프로젝트를 통해 각자 느낀바를 정리해본다.
• 다음 프로젝트에서는 이번에 부족했던 점을 보안해보고 더 나은 팀원으로서 활약한다.

[youjin-hub]

7팀

Keep
• 각자 맡은 부분을 끝까지 책임감 있게 해냈고, 자발적으로 다른 팀원의 작업을 도와주는 모습도 인상 깊었다.
• 의견 제시에 거부감이 없고 어떤 의견이든 경청하며 호의적으로 받아들여주는 분위기 덕분에 부담 없이 소통할 수 있었다.
• 세세한 부분까지 신경 쓰며 수정 및 추가 기능 구현에 최선을 다했고, 프로젝트가 끝난 이후에도 발전시켜보려는 주도적인 태도는 큰 동기부여가 되었다.
• 기본적으로 배려심이 넘치는 팀원들이라 불화 없이 협업을 마무리할 수 있었다.

Problem
• 시간이 촉박해 막판에 코드 리뷰를 충분히 하지 못해 아쉬움이 남았다.
• 발표 준비에 집중하다 보니 프로젝트 구현 방법 자체를 공유하는 본질에 다소 소홀했던 것 같다.
• 폴더 및 파일 구조 정리가 미흡했고, 코드 가독성에 신경을 많이 쓰지 못했다.
• 진행 상황을 명확히 공유하지 않아 다른 팀원이 내 작업을 대신해주는 일이 생기기도 했다.
• GPT의 도움을 과하게 받았던 점과, 나의 기술적 역량 부족으로 팀에 더 큰 기여를 하지 못한 점이 아쉽다.
• 개인적인 기록을 남기지 않아 내가 어떤 점을 잘했고 부족했는지 정확히 파악하지 못했다.
• 다들 배려가 많아서 필요한 조언이나 피드백도 조심스럽게 하는 분위기가 있었다.

Try
• 프로젝트 초기 단계에서 폴더 구조나 세팅 방식에 대해 충분히 논의하고 미리 공부하여 구조를 명확히 하겠다.
• 발표는 대본보다는 솔직한 경험 위주로 공유하고, 피어 리뷰는 간단히 진행한 뒤 멘토 리뷰를 중심으로 보완하는 방식이 좋을 것 같다.
• 트러블슈팅 내용을 꼼꼼히 메모하고, CLS와 같은 기술 요소도 따로 공부해 프로젝트에 더 잘 적용할 수 있도록 하겠다.
• 내가 모르는 부분은 반드시 기록하고 복습하여 도움 없이도 스스로 구현할 수 있도록 학습하겠다.
• 기술적 성장을 통해 다음 프로젝트에는 더 많은 기여를 할 수 있도록 노력하겠다.
• 하루에 한 번이라도 간단한 기록을 남기는 습관을 들이겠다.
• 서로의 발전을 위해 꼭 필요한 피드백은 상처를 주지 않는 선에서 솔직하게 나눌 수 있는 팀 분위기를 만들고 싶다.

[Heedong0924]

5팀

[626-ju]

✨Keep

• PR을 기반으로 잦은 코드리뷰를 통해 에러와 버그를 빠르게 잡고 속도감 있는 작업을 할 수 있었다.
• 꾸준한 데일리 스크럼과 모두가 적극적으로 참여한 코어 타임을 통해 이슈가 발생하거나 논의가 필요할 때마다 빠르게 수정 및 결정을 하여 프로젝트 속도를 높일 수 있었다.
• 데일리 스크럼을 통한 하루하루의 진행 을 공유하고, 이를 통해 상황 인지를 명확히 할 수 있었다.
• 발표와 시연을 마친 후에도 코드품질 개선을 위해 리팩토링을 했다.

☠️Problem

• 초반 설계 미스와 소통 부족으로 인한 불균형한 R&R과 중복 작업이 발생했다.
• 초반에 적용한 일정을 그대로 유지하며 진행하다 보니 일정에 쫓겨 코드 퀄리티를 올리지 못했다.
• 프로젝트 후반에 급하게 추가하느라 pr을 생성 안하고 직접 main에 푸쉬하는 상황들이 발생했다.

💪🏻Try

• 유저 플로우 도식화와 더 상세한 명세서 작성으로 균형 있는 R&R 배분이 필요하겠다.
• 주강사님이 주신 피드백처럼 데일리스크럼을 통해 태스크를 세분화하여 일정을 조율하며 작업해보면 좋을 것 같다.
• 다음번에는 좀 더 시간을 효율적으로 쓰기 위해 적절한 라이브러리들을 사용해봐야겠다.
• 다음 프로젝트에서는 좀 더 적극적인 소통이 필요하고, 역할을 명확히 인지해야 할 필요성을 느꼇다.

[youjin-hub]

7팀 💫💫 최종 팀 회고

Keep

• 다들 맡은 역할에 책임감을 가지고 꾸준히 열심히 해줘서 큰 동기부여가 되었다.
• 모르는 부분이 생기면 바로바로 질문하고 끝까지 도와주는 적극적인 분위기가 좋았다.
• 모두가 온라인으로만 소통했음에도 불구하고 즉각적으로 연락이 잘 되어 작업에 큰 어려움이 없었다.
• 회의 중 자유롭게 의견을 제시할 수 있는 분위기 덕분에 역할 분배나 의사결정이 수월했다.
• 코드리뷰를 세세하게 해주고 해결책까지 제안해주는 과정에서 서로 많이 배울 수 있었다.
• 감정 상하지 않도록 배려하는 리뷰 태도도 좋았고, 협업 중 개선할 점이 보이면 자연스럽게 제안하는 분위기가 형성되어 있었다.
• 코드 컨벤션, 커밋 메시지 규칙, PR 템플릿 등 초기 세팅이 잘 되어 있어 협업 효율이 높았다.
• 예민할 수 있는 상황에서도 서로 이성적으로 대화하며 의사소통이 원활했다.

Problem

• 사전 공유 없이 미팅에 불참한 경우가 있었고, 이는 팀워크에 영향을 줄 수 있어 아쉬웠다.
• 코드 리뷰를 PR당 2명으로 지정하다 보니 리뷰 및 병합 속도가 늦어지는 경우가 있었다.
• 프로젝트 초기에 구조나 규칙을 미리 정하지 못한 채 시작해서 약간의 혼란이 있었다.
• 협업 툴이나 배포 방식 등에 대한 고민이 많아 본격적인 개발이 다소 늦어졌다.
• API 사용 방식이나 파일 구조가 통일되지 않아 관리가 어려웠던 부분이 있었다.
• 데일리 스크럼 외 시간에는 의견 공유가 부족했던 경우도 있었고, 실시간 소통이 어려울 때도 있었다.
• 개인적인 사정이나 실력 부족, 익숙하지 않은 도구 사용으로 어려움을 느꼈던 팀원도 있었다.

Try

• 미팅에 참석이 어려운 경우나 컨디션이 좋지 않은 날에는 반드시 사전에 공유하기.
• 코드 리뷰어를 1명으로 줄이고, 충돌 가능성이 적은 간단한 PR은 공지 후 셀프 머지로 진행해보기.
• API 호출 방식, 파일 구조 등을 하나의 통일된 형식으로 정리하기.
• 공통 훅을 하나로 모아서 재사용성과 관리 효율성을 높이기.
• 프로젝트 시작 전에 충분한 시간 여유를 갖고 규칙과 구조를 꼼꼼히 정하기.
• 낮 시간대에 디스코드나 Zep 등 음성 채팅 채널을 적극 활용해 실시간 소통 강화하기.
• ChatGPT를 활용하더라도 나의 코드 스타일에 맞게 수정하고, 필요한 부분만 참고하는 습관 들이기.

[hong0121]

3팀

Keep

• 각자 맡은 역할에 책임감을 가지고 성실히 참여해 프로젝트가 원활하게 진행되었다.
• 팀원 간 적극적인 피드백과 질문을 주고받는 문화 덕분에 혼자 고민하지 않고 빠르게 문제를 해결할 수 있었다.
• 온라인 중심의 협업 환경에서도 소통이 잘 이루어져 작업 분담이나 일정 조율에 큰 문제가 없었다.
• 회의 시 다양한 의견을 존중하는 분위기 덕분에 결정 과정이 효율적이었다.
• 초기 세팅(폴더 구조, 커밋 메시지, 브랜치 전략 등)이 체계적으로 이루어져 협업이 수월했다.
• 일정에 맞춰 각자 책임감을 가지고 작업을 마무리해 프로젝트 전체 흐름을 지킬 수 있었다.

Problem

• 이탈자를 고려하지 못한 부분을 예상하지 못하고 중간에 버벅임이 있었다.
• 일부 툴이나 기술에 익숙하지 않아 구현에 시간이 오래 걸리는 경우도 있었다.
• 데일리 스크럼 이후 자유로운 의견 교환이 부족했던 경우가 있었고, 실시간 피드백이 필요한 상황에서는 반응이 늦어지는 일이 있었다.

Try

• 프로젝트 시작 전 역할과 범위를 명확하게 정리하고 문서화하여 혼란을 줄이기.
• 주기적으로 통합 테스트를 진행하여 기능 간 충돌을 사전에 확인하고 조율하기.
• 익숙하지 않은 도구나 기술은 사전에 학습할 수 있는 시간을 확보하고, 팀 내 지식을 공유하는 시간을 정기적으로 가지기.
• 코드 리뷰 시 형식적인 피드백보다 구체적인 개선 방향이나 질문을 주고받는 문화 형성하기.