TIL | [React] 맨땅에 헤딩한 팀프로젝트 KPT회고

레이나·2024년 12월 30일

Today I Learned

목록 보기
18/47
post-thumbnail

[241230 팀프로젝트 발표]

Keep 잘했음!

칭찬할건 칭찬해야지!

  • 최초 기획한 내용에서 크게 변동된 부분 없이 대부분의 기능과 모양을 완수하고 제출!
  • 각자 본인이 담당한 부분을 마감전 까지 수행 완료!
  • 페이지를 깃헙에서 배포하란 사항은 없었으나 프론트엔드개발자이니 프로젝트 페이지를 배포하여 시연한것!

조금 일찍 본인의 파트를 끝낸 팀원들은 다른 부분 지원을 하기도 하고, 그 과정에서 수정이 생기면 또 수정을 하기도 하고 서로 도와가면서 잘 마무리하게되었다.

Problem 아쉽네..

팀차원에서도 개인적으로도 가장 아쉬웠던 부분은 내부적 소통과 공유였다.

  • 중간 브리핑시간을 명확하게 지정하지 않아 각자 파트의 진행상황을 알수 없었다.
  • 그로인해 동일 기능 코드가 중복 작성되기도함.
  • 코딩 룰을 정하고 시작하지 않아서 코드 병합 단계에서 시간이 오래걸림.

프로젝트를 제출하고 나중에 튜터님께 피드백 받는 과정중에 확인한 부분.

  • 유효성 검사의 누락
  • 테스트케이스 부족

유효성 검사와 테스트케이스 부족이 생긴 이유 역시 소통이 적었기 때문이라고도 할 수있다. 상대방이 담당한 부분에 대해서도 확인 하고 피드백하는 과정이 필요했는데 그부분을 놓친셈이다.

Try 그럼 개선해야지?

우리가 제출한 프로젝트를 좀더 보완해 보자면

  • 이미지를 URL형식이 아닌 파일업로드 형식으로
  • Input요소들 유효성검사
  • Open API를 받아오는 과정중에 생기는 약간의 딜레이 시간에 로딩UI추가
  • 반응형 텍스트 보완을 위해 워드브레이크 사용

현재의 팀으로 다시한번 프로젝트를 진행하게 된다면

  • 중간브리핑, 회의시간을 고정하여 소통하는 시간을 더 분배: 의견과 피드백을 주고받는 시간 갖기.
  • 기획단계에서 코딩규칙, 파일규칙, 화면 비율등 미리정해야할 부분들 기록해두기
  • 트러블 슈팅은 그때 그때 기록해두기

그래서~

프로젝트 제출 후에 팀원들과 많은 이야기를 나눴다.

다들 공통적으로 생각한 부분은 소통이었다.

프로젝트 후반부로 갈수록 자잘한 수정사항들 소통오류로 인한 코드중복 등 필요없는 시간소요가 많았다는 것을 느꼈기 때문이다.
자신의 코드를 끝냈다고, 다른 팀원을 도와주는 것도 좋다. 다만 자신의 코드에 오류가 있는지 테스트과정과 input페이지의 유효성검사는 다들 놓친 부분이다.

내 실력에 대한 메타인지 부족

때문에 시간배분도 여러번 변경을 해야 했다.
쉬는날에는 몇가지 구현해야 하는 부분들로 애매하게 알고 있던 부분을 다시한번 찾아보고 공부했고, 동일한(비슷한) 문제를 가지고 튜터님께도 여러번 찾아갔다.
쉬는날 계획은 세워도 1~2개 실행했으면 아주 잘한거라 생각했던 내가, 공부했다.
그렇게 공부해서 해결하는게 시간을 오래 걸렸어도 재밌는 과정이었다.
다만 마감시간이 있기에 시간을 오래들여 코딩할 수 없었기에 프로젝트 후반으로 갈 수록 찾아보는 시간보다 팀원에게 물어보고 튜터님을 찾아가고 주말에도 나와서 마무리 하면서 완수하였다.

이번 프로젝트를 진행하면서 내가 개선해야 할 부분은 명확했다.

  • 내가 예상한 시간보다 실제 작업시간이 더 소요되기 때문에 너무 단시간에 끝내려 하지 말것.
  • 마감이 있다는 것을 항상 염두해 두고 팀원과 튜터님을 적극 찾아갈것.
  • 모르는것이 생기면 무조건 질문부터하는 것이 아닌, 내가 해결하고 싶으니 그것에 대해서 나혼자 해결할 시간의 최대시간을 정해두고 그 시간안에 해결 못하면 팀원과 튜터님을 찾아가겠다는 것이다.
  • 트러블슈팅은 그때그때 기록해두기.
profile
one setp

0개의 댓글