심화 프로젝트 최종 팀회고

[miju-seaweed]

왜 회고를 해야 하나요?

바쁘고 치열하게, 또 잘 버티고 있는 스프린트 16기 여러분!
정신없이 프로젝트를 하다 보면 현재 우리 팀의 방향성과 목표를 잊어버리기 쉬워요.
매주 팀원들과 일주일을 회고하며 프로젝트를 위한 원동력이 되었으면 좋겠어요.

회고에 대한 궁금증

회고와 일기의 차이는 무엇인가요?

• 일기는 일상에서 있었던 일들을 의식의 흐름대로 편하게 적는 것이라면,
  회고는 함께 보고 듣고 경험한 사건과 현상들을 곱씹어 보고, 그중에 특히 되짚고 싶은 것들을 '왜' 와 '어떻게'에 집중해서 기록하는 것입니다.

회고 방법

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

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

참고글

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

[miju-seaweed]

🍀 0팀 (예시)

Keep

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

Problem

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

Try

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

[Chiman2937]

🍀 1팀

Keep

• 애자일 협업 구조 도입 - Feature별 이슈 생성과 타임라인 관리로 작업현황이 잘 공유되었다.
• 사용자 경험 개선을 위한 적극적인 토론을 통해 합리적인 결론을 도출할 수 있었다.
• 코드 리뷰 참여도가 높았고, 피드백 수용도 적극적으로 이루어져서 일관적인 프로젝트 구조를 지키는데 도움이 많이 되었다.
• 전체적인 일정 내에 작업이 이루어졌고, QA 시에 발생했던 문제점들도 빠르게 반영되어 일정이 지연되지 않았다.
• 작업 단위별로 PR 작성하는 과정이 잘 이루어져서 작업물 검토에 많은 도움이 되었다.
• 기본 요구사항 뿐만 아니라 작은 단위의 작업까지 명확하게 R&R을 분리하여 불필요한 중복 작업을 피하고 자신의 담당 영역에서 효율적으로 작업할 수 있었다.
• 새로운 기능을 추가할 때 단순히 기능 추가만 하는 것이 아니라 코드 구조/사용자 경험 등을 깊게 고민하여 작업했고, 예상치 못한 문제가 발생했을 때는 팀원들 모두 자신의 역할에 국한하지 않고 문제 해결에 적극적으로 참여하여 프로젝트의 완성도를 높일 수 있었다.

Problem

• 초기에 애자일 협업 방식 도입을 고려하지 않았어서 간단하게 github issue만 다루었는데, 애자일 협업 방식을 도입하게 되면서 github project와의 연동 만으로는 관리 체계가 완벽하지 않음을 느꼈다.

Try

• Next.js에서는 여러가지 렌더링 방식을 제공하고 있는데, 현재 프로젝트에는 SSR과 CSR만 적용되어있어서 성능 최적화를 위해 SSG, ISR 도입할 만한 기능을 검토해보고자 함
• 사용자 경험 개선에 대해 많은 고민을 하고 기능 추가 및 수정 과정을 거쳤지만, 유저 페르소나에 대해 분석해보는 과정을 거치면 더 좋은 결과물이 나올 것이라고 생각 됨

[626-ju]

🍀 3팀

Keep

• 막판에 여러 변경점들이 발생을 했는데 서로 소통을 잘해서 원활하게 처리할 수 있었음
• 난관을 겪어 진행이 어려울 때 팀원 모두가 도와 해결함

Problem

• 초기 설계의 문제가 막판에 발목을 잡아 큰 변경 사항이 생겼음
• 마지막에 가까워질 수록 코드리뷰를 깊게 하지 못했음

Try

• 처음부터 다른 사람의 작업물을 관심을 가졌다면 문제가 발생하더라도
  일을 더 효율적으로 나누어서 할 수 있었을 것 같음
• 일정이 밀리더라도 코드리뷰 좀 더 신경 쓰기

[Sea0Soda]

🐳 5팀

Keep

• 꾸준한 의사소통으로 진행도와 남은일 완료된일 공유
• 의사소통 잘하려고 노력함, 코어타임외에도 코드 공유 및 코드리뷰 진행
• 마지막까지 느슨해지지않고 각자 프로젝트에 집중하고있음

Problem

• API구조 파악 미숙으로 인한 관련 코드 수정 필요. but, 시간없음으로 어떻게든 돌아가게끔 구현함
• api 구조에 대해 어려움을 느끼고 있고, 하드 코딩이 많이 되었음
• 코드리뷰를 열심히 진행했으나 아직도 타인작업물에 대한 이해도가 부족할떄가 자주보임
• 내가 짠 코드지만 질문이 들어오면 순간 뇌가멈출때가많음 (기억이잘안나서..)

Try

• 컴포넌트 구조와 페이지끼리의 데이터 향방을 더 자세히 파악한 후, 코드 작성 필요일을 더 효율적으로 나누어서 할 수 있었을 것 같음
• 남은 완료 시점까지 다 끝낼 수 있도록 신속한 코드 공유 및 코드 리뷰 필요
• 결과물이 잘나와도 코드를보고 어떤 구조로 만들어졌는지 자주 읽어보면서 기억에 남기면 좋을듯함

[summerDev96]

🍀 2팀

Keep

• 지도 결제 등 다양한 외부 API를 적용하는 경험을 해서 좋았다.
• react의 선언적인 코드 작성 방식에 대해 다시 공부해보게 되었다.
• 사용자 경험을 고려한 페이지 개발을 했다.
• 리니어 사용으로 브랜치명이 정확했다.

Problem

• 페이지를 여러개 개발하다보니 분산돼서 작업을 효율적으로 못했다.
• 추가 기능 구현을 구현하려고 하였는데 백엔드에 없던 부분이라 구현이 힘들었다.
• 코드리뷰를 적극적으로 하지 못했다.
• 기능을 빨리 개발하다보니 코드 퀄리티를 신경쓰지 못했다.

Try

• 백엔드와 소통하며 작업을 해보고싶다.
• 에러를 빠르게 파악하고 사소한 오류도 공유해야겠다.
• 작업 단위를 쪼개고 자주 코드 리뷰를 받는 습관을 들여야겠다.

[Luganic]

🍀 7팀

Keep

1. 협업 및 업무 관리 능력

프로젝트를 진행하며 지라(Jira) 티켓 관리와 진행 상황 공유를 통해 팀 전체의 업무 흐름을 명확하게 파악할 수 있었습니다. 개인적인 일정 변동 사항을 팀원들과 세밀하게 공유하여 프로젝트가 지연되지 않도록 노력했습니다.

2. 품질 관리 및 피드백

꼼꼼한 QA와 세심한 코드 리뷰를 마지막까지 진행하여 프로젝트의 완성도를 높이는 데 기여했습니다. 이 과정에서 건전하고 건설적인 피드백을 주고받으며 서로의 부족한 부분을 보완하고, 더 나은 결과물을 만들 수 있었습니다.

3. 책임감 및 소통

어려운 부분에 부딪혔을 때는 적극적으로 도움을 요청하거나 먼저 도움을 주며 팀원들과 협력했습니다. 이러한 과정을 통해 책임감 있게 일정 목표를 달성할 수 있었습니다.

Problem

1. 버그 분석 시간 단축

버그가 실제로 어떤 현상을 일으키는지 정확히 파악하지 못해 불필요한 시간을 낭비했습니다.

2. 코드 중복 방지

다른 팀원이 만든 공용 코드를 파악하지 못해 코드가 중복되는 경우가 종종 발생했습니다.

Try

1. 버그 분석 시간 단축

문제의 원인을 더 신중하게 분석하여 효율성을 높여야 합니다.

2.코드 중복 방지

공용 컴포넌트나 코드를 팀원들과 함께 논의하고 공유하여 효율성을 높이겠습니다.