중급 프로젝트 2주차 팀회고

[Y00JUNG]

왜 회고를 해야 하나요?

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

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

회고 방법

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

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

참고 글

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

[Y00JUNG]

🍀 0팀 (예시)

Keep

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

Problem

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

Try

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

[bk-git-hub]

[hansaemkim38]

🍀 6팀

Keep

• 미팅 시간 모두 참여를 해서 약속을 잘 지켰다.
• 위워크에 모여서 하다보니, 프로젝트 진행
• pr요청을 체계적으로 해서 충돌이 나지 않았다.

Problem

• 브랜치를 하나로 너무 진행을 길게 해서 그 해당 브랜치에 올바르게 커밋이 들어가지 않았다.

Try

• 각 작업 내용에 맞게 브랜치를 나눠서 작업을 할 것 같다.
• 문제 해결 시간을 정하고, 시간이 지나면 문제에 대해 얘기해본다.

[ohdong9795]

🍀 4팀

Keep

• 프로젝트를 구현할 때 알게된 정보가 있다면 서로 공유해줘서 많이 배울 수 있었다.
• 기능 구현에 어려움을 느꼈을때 타협하지 않고 새로운 라이브러리를 익혀서 해결한 것
• 잘 안되던 부분을 팀원간의 소통을 통해 알려주고 배워가는 자세가 좋았던것 같다.

Problem

• 특정 기능에 대한 마감일자를 넘기는 일이 많았다.

Try

• 프로젝트 준비 과정에서 기술 스택을 선택함에 있어서 신중하면 좋겠다.
• 초반 사전 준비 단계에서 조금 더 신중을 가해서 구상에 힘을 좀 더 썻으면 좋겠다.

[O-daeun]

🍀 2팀

[HMRyu]

9팀

[eunji-0623]

8팀

Keep

• 데일리 회의에서 현재 진행상황과 남은 작업내용 공유를 잘해주셔서 좋았다.
• 코드에 주석을 잘 달아주셔서 코드 리뷰할 때, 사용할 때 편리했다.
• github의 PR 기능을 아주 잘 사용한 것 같다. ( PR 이전 오류검사, 메세지로 소통 등)

Problem

• 추가적인 기능까지 구현할 시간이 없었던 것이 아쉬웠다.
• 개발 후반부에 가서 테스트를 꼼꼼하게 하지 못한 점이 아쉽다. 발견하지 못한 에러를 추가적으로 수정하게 되면서 계획한 시간보다 더 촉박해졌다. 그래서 QA 시간이 짧아졌다.
• 다양한 버그, 문제상황이 발생했을 때의 대응력이 부족한 것 같다.
• 처음에 전체적인 데이터 관리에 대해 정하지 않았던 점이 아쉬웠다.

Try

• 프로젝트를 시작할 때 데이터 관리에 대해서도 미리 생각해보는 게 좋을 것 같다.
• 일정 계획 시 QA를 위한 여유 기간을 하루정도 더 추가하는 것이 좋을 것 같다.
• 기능을 더 효율적으로 다룰 수 있는 다양한 라이브러리를 더 사용해봐도 좋을 것 같다.
• figma에 없는 디자인이나 기능이 필요해 보일 경우 팀원들과 적극적으로 소통해서 완성도를 높혔으면 좋았을 것 같다.
• 테스트를 할 때 꼼꼼하게 해야겠다.
• 할 일을 좀 더 세세하게 계획해야겠다.

[jisurk]

Keep

• 팀 미팅 참여를 잘 한다.
• PR 꼼꼼하게 잘 올려준다
• 본인 파트가 아니어도 팀원의 어려운 부분을 잘 도와줬다.

Problem

• 개발 진행 상황 공유가 부족하다.
• 한 PR에 여러 작업이 담겨있을때가 있다.
• 막힘이 있을 때 팀원에게 적극적으로 도움을 요청하지 않는다.

Try

• 일정 관리를 구체적으로 한다.
• 한가지 주제에 대한 작업이 끝나면 그때마다 PR을 올린다.
• 일정 시간 문제를 해결하지 못하면 도움을 요청한다.

[jose0229]

7팀

[BaeUiJin]

10팀

Keep

😗 기록하자

• 무엇을 얼마만큼 했는지
• 이슈와 해결

‘이렇게 하기로 했으니까 이렇게만 공유할거야, 알아서 지키겠지’라고 하는 게 아쉽다. 결국, 무언가를 남기는 이유는 팀원들과 공유하고 일을 잘 풀리게 만들기 위함이다. DM 이든, 노션이든 팀원들이 컨텍스트를 알고 있는지 확인해야 한다.

Problem & Try

😗 공통 컴포넌트를 다시 만드는 경우가 더러 있었음.

⇒ UI 만 가지고 ‘공통’ 컴포넌트라고 판단했기 때문은 아닐까.

⇒ 계획을 세울 때 치밀하게 정말로 쓸 거란 생각으로 만들어야겠다.

⇒ 혼자 만드는 게 아니라, 그걸 쓰는 모든 사람이 같이 검토해야 중복 작업을 피할 수 있다.

⇒ 공통 컴포넌트의 수정은 반드시 공유 및 합의 하에 진행. 불필요한 수정작업 최소화.

😗 한 사람이 해도 되는 일을 두 사람이 한 경우가 종종 있었음.

⇒ 마음에 여유가 없을 때, 소통하고 공유하는 일을 소홀히 했음.

⇒ 작업을 어떻게 하고 있는지 서로 ‘공유’하는 것도 내 일만큼 중요하다'고 느낄 수 있을까?

😗 eslint

⇒ vscode 에서 eslint 설정 enable 로 ! 이건 파일로 공유가 안됨. 각자 해야 함.

😗 yarn.lock 파일의 충돌

⇒ yarn.lock 파일의 개별적인 삭제 후 설치가 원인

😗 Mantine 설치하고 사용을 안 했음.

⇒ 찾아보니까 좋은 UI 요소들이 많았음.

⇒ 활용했다면 시간을 조금 더 절약했을 것 같음.