🥁요한팀의 스프린트 회고🥁

동현

Keep ✨

• 초기에 프로젝트를 기획할 때, 크게 하지 않고 현실적으로 잡았던 부분이 안정적으로 프로젝트를 진행 하는데 도움이 많이 되었던 것 같다.
• 각자 상황에 맞는 적절한 업무량이 배분이 되어 문제 없이 결과물을 만들 수 있었다.
• 프로젝트를 진행하면서 생긴 각종 이슈와 문제들을 거리낌 없이 공유하면서 오래걸릴수도 있는 문제를 빠르게 해결 할 수 있었던 것 같다.
• 마감 기한에 맞게, 최대한 완성도 있는 결과물을 만들기 위해 유동적으로 계획을 수정한 것이 비교적 좋은 결과를 만든 것 같다.

Problem 🔥

• 공통 코드를 사용하기로 하면서, 코드의 버그나 문제점이 있을 시 다른사람의 작업속도에 영향을 줄 수 있음을 인지 했다.
• 프로젝트 기획 때 정했던 코드 컨벤션이나 규칙들이 후반으로 갈수록 서로 잘 지켜지지 않았던 것 같다.
• 모든 사람이 작성한 코드스타일이 모두 동일하지 않아, 나중에 유지보수를 할 경우, 다소 이해하기 어려울 수 있을 것 같다.
• 새로운 기술 스택을 미리 선행학습 하지 않고 프로젝트 투입 시, 학습하는데에 다소 시간이 걸려, 정해진 업무를 순탄하게 진행하지 못하게 되는 것 같다.

Try 🌱

• PR을 할 경우, 구현한 것과 작성한 코드에 대해 좀 더 구체적인 설명을 적어 놓을 수 있으면 좋을 것 같다. 마찬가지로 리뷰어들도 코드에 구체적인 질문이나, 이유 , 피드백등을 적으면 좋을 것이다.
• 프로젝트의 마감일이 촉박하다면, 공통 코드를 먼저 만들어 놓고 쓰기보다는 각자 구현 후 , 중복을 추려내어 빼는것도 좋은 방법인 것 같다.
• PR을 하기 전, 현재 코드에서 발생할 수 있는 에러나, 버그등을 미리 생각해보거나 테스트를 하는 시간을 가진 후, 올리는 것이 결국에는 더 빠르게 작업을 하는 방법인 것 같다.
• 문제가 발생해도 다른 팀원들의 시간을 뺐지 않게 비동기적인 소통방법을 정하는것도 좋을 것 같다.
• 깃헙 프로젝트 페이지에 현재 발생한 이슈에 대해, 공개하거나 발표하여 같이 해결하는 게시판을 두면 좋을 것 같다.

칭찬 🐳

• 이진욱: 프로젝트 마무리 단계에서 각종 버그를 솔선수범하여 찾고 직접 해결하시는 모습을 칭찬합니다.
• 안혜수: 다른 컴포넌트와 사이드바 사이에서 생기는 충돌이나 버그등을 끝까지 책임지고 해결해주셔서 성공적으로 프로젝트를 마칠 수 있었던 것 같습니다.
• 이진욱, 안혜수: 마감기한과 프로젝트 상황에 따라, 유동적으로 계획을 변경하는데 동의 해주시어 무리하지 않고 완성도 높은 결과물을 만들 수 있게 해주신 것 같습니다.
• 이진욱, 안혜수: 좋은 문서화나, 프로젝트 세팅, 발표 자료 등을 제작해주셔서, 이번기회에 부수적인 역량에서 차이가 남을 느꼈으며 많이 배운것 같습니다.

혜수

Keep ✨

• 새로운 기술을 도입하는데 적절한 수준의 러닝커브를 가진 기술만 도입함
• 모두 팀원과의 소통을 위해 슬랙을 꾸준히 들어가 의사소통 문제가 생기지 않도록 함
• 개인에게 문제가 발생하면 다들 함께 문제를 해결하기 위해 적극적으로 도움
• 스크럼에서 하루의 일과를 전부 공유해 누가 어떤 작업을 하고있는지, 할 예정인지 쉽게 확인할 수 있었음
• 다른사람과 겹치는 영역 없이 대부분의 일의 분배가 잘 이루어져 충돌이 잘 일어나지 않았음, 겹치더라도 먼저 작업을 진행한 사람이 충돌나지 않도록 대비를 잘 해놓음
• 상황에 따라 유동적으로 계획을 변경해 마감 기한까지 급한 일을 먼저 처리해 완성도를 높일 수 있었음

Problem 🔥

• 고민하는 시간을 딱 정해놨으면 좋았을 것 같음. 내 개인의 문제일 수 있지만 한 문제를 깊게 파는 경향이 있어 프로젝트 도중에 고민의 시간을 너무 깊게 가져 일이 미뤄지는 현상이 발생함.
• 공통 컴포넌트를 만들게 됨으로써 미처 생각해지 못한 부분을 타인이 필요로 하는 일도 있었고 이를 수정하느라 작업속도에 영향을 주는 경우가 꽤 있었음.
• 새로 도입하는 기술을 학습할 시간이 부족했음. 프로젝트를 시작하기 전 학습을 할만한 시간을 뒀으면 좋겠지만 현실적으로 불가능했던것 같음.
• 스토리북을 사용하기 위해 컴포넌트를 독립적으로 만든것은 좋았지만 다른사람이 만든 컴포넌트를 사용할때 스토리북 보단 코드를 보면서 직접 사용했던것 같아 굳이 도입해야했나 하는 생각이 들었음.
• 커밋 단위가 이상했던 것 같음. 만약 코드에 문제가 생겨 커밋을 과거로 되돌렸을때 과연 문제가 안생길까?라고 생각해봤을때 확실하게 문제가 생길 것 같다.

Try 🌱

• 새로운 기술을 사용할 때 충분한 학습 기간을 두고 적용해보도록했으면 좋겠음.
• 한 일에 집중하다보면 생각을 그쪽으로만 하게되는 경향이 있기 때문에 1시간 정도만 고민하는 시간을 가지고 다른 사람의 관점으로 바라본 문제 해결 방법을 들어보도록하면 좋을 것 같음.
• 이번에 코드리뷰를 거의 못했는데 다음에는 코드리뷰를 하는 고정적인 시간을 두고 남의 코드를 읽을 수 있는 시간을 가져보도록 했으면 좋겠음.
• 노션에 문서화하는것도 좋지만 깃허브 wiki에 문서화도 한번 잘 해보도록하자.
• 트러블슈팅을 기록해놓지 않은 부분이 아쉬움. 다음 프로젝트때는 어떤 트러블이 있었는지 기록해놓는 습관을 가지면 좋을 것 같음.

칭찬 🐳

• 동현 : 맡은 일을 문제없이 빠르게 처리하시는 부분이 너무 인상깊었습니다. 문제가 생겨도 빠르게 수정해주셔서 프로젝트 진행에 문제가 없었던것 같습니다. 일정 시간만 고민하다 문제를 공유해주시는 부분은 제가 잘 하지 못하는 부분이었는데 저도 잘 실행해보겠습니다..!
• 진욱 : 팀장 일을 잘해주셔서 팀이 잘 굴러갈 수 있었던것 같습니다. 맡으신 일을 먼저 빠르게 처리하시고 디테일한 부분을 잡아주시며 프로젝트의 전체적인 방향을 흔들림 없이 잡아주신 부분 너무 좋았습니다.
• 두분 모두 혼자 맡기로 한 부분이 아닌 공통으로 하기로 남겨두었던 일을 솔선수범하여 해주셨기 때문에 마감기한을 맞출 수 있었던것 같습니다. 제가 좀 더 잘했어야하는데 그렇제 못해서 많이 아쉬웠습니다.

진욱

Keep ✨

• 팀원 모두 시간약속(코어타임 준수)을 잘 지켜서 좋았다. 임의로 코어타임을 오전 10시부터로 늘렸음에도 모두 잘 참여했다.
• 아토믹 디자인 패턴: 디자인 시스템이 없고, UI라이브러리를 사용하지 않는 프로젝트에서 유용한 패턴이라는 생각이 들었다.
• 프로젝트를 진행하면서 팀의 맨데이를 대략적으로 알 수 있었고, 그에 맞춰 일정을 유동적으로 바꾸어 잘 마무리할 수 있었다.
• 데일리 스크럼을 통해 체크리스트를 만들고 하나씩 지워나가면서 개발을 진행했고, 하루 맡은 일을 책임감있게 마무리할 수 있다는 점에서 좋은 방법이었다고 생각한다.
• 슬랙과 디스코드를 통해 어려운 구현이나 문제상황을 빠르게 공유하고, 같이 해결할 수 있었다.

Problem 🔥

• 명확하지 못했던 테스크 종속성: 일 배분을 할 때 공통되는 부분을 최우선 순위로 두기 위해 노력했지만, 미흡한 부분이 있었다고 생각한다. 간혹 PR이 머지되는 것을 기다리게 되거나, 머지해달라고 부탁하는 일이 발생했다.
• Storybook: 컴포넌트가 Provider가 필요한 라이브러리(ex. React Router Dom, TanStack Query)에 의존하는 경우 스토리북 구현이 어려웠다. 다른 라이브러리에 크게 의존하지 않는 디자인 시스템과 같은 부분에서 강점이 있는 라이브러리라는 생각이 들었다.
• ErrorBoundary: 선언적인 에러 처리를 위해 사용하기로 했지만, 작동 방식을 제대로 몰랐어서 구현에 어려움을 겪었다. 또한 에러 처리를 섬세하게 하지 못한 점이 아쉽다.
• 내가 구현한 공통 코드에 문제나 변경점이 생길 경우, 다른 작업에 영향이 가는 것이 아쉬웠다.

Try 🌱

• ErrorBoundary에 대해서 더 깊게 공부해보고 어떻게하면 에러 처리를 잘 할 수 있을지 생각해보기
• 공통 코드를 작성할 때에는 최대한 버그나 문제가 없도록 하고, 변경하기 쉽게 작성하기
• 프로젝트 기획 시 테스크 종속성을 명확히하고 일의 순서에 반영해 일정을 산정하기
• 다른 팀원의 PR을 꼭 읽어보고 코드리뷰 해주기
• 개발하면서 문서화 꼭 신경쓰기. 트러블 슈팅이 있을 경우 꼭 코드와 스크린샷 기록해두기