Project 1 - 3일차 : 2차 standing meeting w/ 멘토님

임시저장해놓고 프로젝트 끝나고 숨돌리며 올리는.

---

개선사항

• 회의 시작한다는 것 알리기. --> 회의를 하는 중인지 모르셔서 멘토님께서 중간에 계속 끊음. 
• 회의록 작성 , 서기 정해서, 회의 내용 정리 --> 나는 개인적으로 적고 있었으나, 공식적인 내용 정리 (오해 방지) 
• 이 티켓을 완료하는 것을 예상하는게 어렵다. 대표님도. 그러나, 대략적으로 말해두고, “오늘까지 하겠다” . 그리고 나서 다음날 아침 standup meeting에서, 다시 수정하는. 

 

회의록의 목적:

지금은 1주 sprint라 기억에 의존할 수 있는데, 개별 진행상황 공유 사항

• 내가 뭘 했고 
• 막혔던 것 공유
• 예상시간 (추후 맞춰보는거 계획 위해)
• 기획적 수정 
• Action item (누가 뭘 하기로 했다. ) 
• 중간에 방향이 다른 거로 진행이 됐다. - 기억에 의존하지 않도록. 

 

라이브로 코드 리뷰하는 시간이 목요일에 있을테니,

그때까지 Pr 올려야 하고.

 

기능 구현 자체에 대해 막히면, 빨리 멘토에게. 

 

내가 프론트팀에게, 지금 구현하기로 한 기능 4개 중에 몇개가 완료되었고, 

남은 1개 소요시간이 어떻게 되는지 물어보았다. 

 

이전의 Pm 근성, 디데이 맞추는 파워 J 성향 반영.

체크리스트와 우선순위 / 계속 바뀌어가는 우선순위 반영

 

이에 멘토님께서는,

일정에 맞추려는 모습이 보기 좋았다고 하셨다.

미팅 주 목적은 일정 안에 맞추는 것이기에,

체계적으로 완성하는 과정이라고 하셨다. ----> 내 전문 영역 

질문 할 것도 다 기록해 둠

 

만약, 백엔드의 진도가 더 빨라서 

처음에 프론트측과 말한 것보다 더 많은 기능 구현을 하고 싶다면, 

 

백엔드가 기능 구현을 더 할 수 있지만, 

프로젝트의 주 목적인, 프론트와의 통신을 등한시 하면 안 된다고 정리해주셨다.  

 

하지만, 이 또한 백엔드 팀 내에서

의견이 달라서

프론트와 이야기 한 기능부터 제대로 완성 후에

추가 기능을 나가자고 정리를 하였다.

 

——

미팅 이후에, 내가 멘토님께 조언을 구했다. 

1차 프로젝트의 목적은 2주의 foundation 에 배운 것을 정리하고, 

앞으로 있을 2,3차 프로젝트를 위한 기반을 닦는 복습이라고 

여러 멘토님들께 재차 확인을 했었다. 

 

그러나, 팀원을 비롯한 전반적인 분위기가, 

복습보다는 더 많은 기능을 구현하고, 

깃허브 브랜치 활용의 중요성을 등한시한 채, 통신만을 중요시하는 분위기였다. 

 

멘토님께서는, 

기능 2-3개를 추가하고, 프론트의 경우 장바구니 만들고, 페이지 더 넣고 해서

"나 이렇게 페이지 여러 개 만들었어" 하는 거 까보면, 코드가 엉터리고, 주먹구식으로 동작하게만 해놓은 경우가 많은데,

그보다, 

검색 기능 하나만 넣어도, 코드를 열어보면 얼마나 많은 고민이 담겼나 

볼 수 있는 게 좋다고 하셨다. 

---

팀원의 경우에는, 내가 이렇게 4일째 말하지만, 

계속 "부트캠프에서 하는 거 이상을 해야하지 않겠냐, 그래도 우리가 개발자인데~ "라며 

추가 기능 추가를 강요했지만,

 

우리 팀이 해야 할, 코드는 제대로 짜지 않았고, 

코드 리뷰를 하지 않은 채 계속 앞만 보고 달려나갔다. 

 

---

그럴 경우, 멘토님께서는 혼자 추가로 기능하고, 

멘토님과 테스트해보라고 전달하라고 하셨다. 

나 또한, 진작에 생각했던 부분이였다.

팀이라고 해서 동시에 모두가 모든 것을 함께하는 게 아니지만, 팀에 대한 이해도의 차이라고 본다. 

---

나는 본질에 집중하는 사람이고, 목표와 방향을 늘 점검하며 가는 사람이라, 

스타일이 맞지 않아 고민을 많이 했다. 

그 결과, 팀원이 다 만들었다고 주는 코드는 참고를 하고,

내가 코드 리뷰를 해가면서 코드를 다시 빌드업하였고, 

깃허브 브랜치에도 

초기세팅, user service, post service로  layer를 여러 개 나누어서 만들었다. 

 

팀원들은 코드를 주었기에 

다 하지 않았냐고 했지만, 

 

코드는 어떻게 기획하고 layer를 나누느냐에 따라 계속 추가되고, 

그럴 경우, git add , commit, push로 계속 올려야 하고,

이미 merge 될 경우, 혹은 branch 이동을 할 경우의 어려움은 이해하지 못했다. 

 

그래서 나는 github의 branch 생성과 관리, pr 담당을 하였지만, 

결국 remote repository와 연결되는 로컬은 내 맥북 하나였기에,  

결국은 처음부터 끝까지 모든 것을 혼자 하고 있음을 인정하였다. 

 

어떻게든 해결해야겠다는 집요함과

혼자 깃허브 브랜치 이동을 해가며 해결해나가고, 

내가 commit을 하지 않고, 

작업을 구분해서 branch에서 하지 않은 실수 덕에

깃허브 입문자가 하기에는 심화과정인 응용을 계속 멘토님께 배우면서 하게 되어, 

깃허브 마스터가 되겠다는 성취감으로 이겨냈다. 

 

물론, 다른 팀은 기능 구현과 통신에만 집중했기에,

나는 깃허브에도 추가로 집중할 시간이 필요해서,

가장 이른 시간인 아침 7시, 7시30분에 와서 

가장 늦게 10,11시에 가기도 했다.

---

오전 standup meeting에 참관하셨던 멘토님께서 

마음에 걸리셨던지, 

 

저녁에 다시 오셔서 이야기 해주셨다. 

 

팀이라고 모두가 한낱 동시에 같은 일을, 같은 자리에서 함께 해야 하는 게 아니지만,

이런 힘듦과 고통은, 

처음에 우리 팀이 분업을 하지 않아서 벌어진 일이라고.

 

 

복습 차원에서 모두가 다같이 해보자고 해서 

분업을 하지 않았다. 

 

2차 프로젝트 사이에 추석 연휴가 있어서 걱정을 하니,

멘토님께서, 

만약 처음에 분업을 잘 했다면, 새벽에 연락오거나 주말에 연락와도 (중요한 업무에 대한 연락이 아니였지만) 

내가 맡은 일만 다 하면,

주말에 쉬거나, 휴일에 쉬어도 상관 없는 것이라고 하였다. 

다 같이 더 하자고 할 일도 없을 것이고. 

 

 

다음 2차 미팅은 무조건 분업을 할 것.