4일 차 이후부터 했던 것

• 팀 전원의 PR, Merge, 충돌 처리, 코드 관리
• Merge 적용 후 Push 하여 제공
• 수 많은 테스트
• 디버깅

회고

긍정적인 부분

1. 협업 시 가져야 할 시야를 배웠다

• 이번에 내가 맡은 주 역할은 코드 관리였다.
  불가피하게 진행 된 방식이었는데
  방식은 대략 이렇다.

  1. 5명이 구현 완료 시 push
  2. 내가 모든 PR을 처리하고, 충돌을 잡아 Merge 진행 후
  3. Merge 된 것에 반응형 적용, 페이지 간의 연결, 기능 간 연결
  4. Clone만 해서 사용할 수 있도록 다시 push 해주는 방식이다.

• 이 과정은 협업 시 좋은 시야를 갖게 해주었고
  시간에 쫓기는 상황 속에서도 프로젝트 진행 상황을
  이해할 수 있도록 해준 방식이었다고 볼 수도 있겠다.

• 모든 팀원의 코드를 읽고, 이해하고, 연결하는 그 과정은
  각자의 코드가 어떻게 짜여졌는지 파악하고
  그에 따른 다음 step은 어떻게 해야 하는지 생각할 수 있도록 해줬다.

• 물론.. 불가피하지 않다면 다시는 하고 싶지 않은 방식이지만
  다른 사람의 코드를 읽는 능력, 팀 프로젝트 시 갖춰야 할
  기본적인 시야가 생긴 거 같다.

!

아쉬운 부분

협업 룰

• 현업에서 협업에 대한 경험을 중요하게 생각하는 것을 이해했다.
  커밋 전략, 여러 개의 프로젝트 진행 방식, 상황에 따른 진행방식,
  코드 컨벤션 등.. 프로젝트를 위한 많은 용어들과 룰을 들어봤지만
  이번 프로젝트에서 적용했던 방식은 코드컨벤션 1개뿐이다.

팀의 소통 부재

• 시간이 촉박한 탓도 있겠지만
  점점 회의와 진행상황 공유는 사라졌고
  코드 리뷰의 시간도 당연히 사라졌다.
  시간이 갈수록 팀 프로젝트라는 것 안에서
  개인의 프로젝트를 진행하는 느낌이 들었다.

비효율적인 커밋 전략

• 위의 긍정적인 부분에서 설명했던 방식은 부정적인 부분도 있다.
  이번 방식대로 모든 코드를 한 명이 처리하여 제공해도
  각자의 작업에서 사용한 firebase와 관련 된 잦은 에러가 있었다.
  만약 이번처럼 소통의 부재 상태로 각자의 기능만 만들다가
  코드 공유 한 번 없이 병합을 시도했다면
  어떻게 됐을까 하는 생각이 들었다.
  협업이라면 구성원들이 협업다운 상황을 만들어 나가는 것도
  중요한 거 같다.

다음 협업 시 적용해볼 부분

• 소통을 활발하게
• 상황에 따른 그라운드 룰 생성
• 효과적인 프로젝트, 커밋 전략 적용
  
  

느낀점

• 협업 환경은 구성원들이 다 같이 만들어 가는 것이다.

• 팀장이란 역할을 맡아 본 결과
  내 작은 그릇의 크기를 봤다고 해야 할까
  나는 나대로 바쁘고, 바쁜 와중에 문제가 생기고,
  문제를 해결해도 끝나지 않고, 발표 자료, 시연영상 등
  끊임없는 상황 속에서 쫓기기만 하는 내 부족함을 봤다.

• 아쉬운 부분이 긍정적인 부분보다 많지만
  환경은 늘 다르고, 시행착오라는 것이 있기 때문에
  다음 협업 때는 어떤 역할을 맡든 아쉬운 부분을 줄이고
  구성원들과 협업이라는 환경을 잘 만들어 나가며
  이번보다는 나아진 모습일것이라 다짐했다.

정돈되지 않은 정신 없던 기록..⭐