중간 회고록

🤷‍♂️회고 때 무엇을 하나요??

• 기획
• 프로젝트를 시작하면서 팀원들과 조율하면서 사용자 입장에서 어떤 기능이 필요하고 어떤 기능은 오버 엔지니어링으로 오히려 불편함을 줄 수 있는지에 대해 많이 알게 되었습니다.
• 아이디어를 자유롭게 제안할 수 있는 분위기가 조성되어 있어서 여러 아이디어 중 좋은 주제를 정할 수 잇어서 좋았습니다.
• 프로젝트를 체계적으로 기획하다보니 대략적으로 알기만 했던 부분들과 기획 흐름을 더 깊게 이해할 수 있었습니다.

• 개발 환경 설정
• 커밋 컨벤션, 브랜치 전략, 이슈와 PR 컨벤션, 프로젝트 구조 등 함께 토론하고 결정해서 맞춰나가는 부분이 실제 프로젝트를 어떻게 구성하고 진행하는지에 대해 많이 알게 되었습니다.
• 지금까지 딱히 eslint나 prettier 설정을 따로 하지 않고 코드를 작성했었는데 팀원들의 코드 스타일이 모두 다르다는 걸 알게되었습니다. 이런 사소한 부분들도 팀 단위로 규칙을 정해야 한다는 것을 배웠습니다.
• 협업을 하기 위해서, 생각보다 많은 부분들을 함께 맞추어 나가는 과정이 필요하다는 것을 느꼈습니다. 또한, 기획 초반의 개발 환경 설정이 나중에 개발을 하는 과정까지 큰 영향을 미칠 수 있다는 점을 깨달았습니다. 따라서, 협업에 있어서 개발 환경을 설정하는 부분을 견고하게 서로 토의해봐야겠다는 생각이 들었습니다.
• 혼자 git을 사용하다보니 git의 여러 기능들을 사용해 볼 일이 많이 없었습니다. 1년 동안 사용한 git의 기능보다 최근 1주일동안 사용한 git 기능이 더 많은 것 같습니다.
 

• 프로젝트 관리
• Issue 템플릿과 PR 템플릿을 상의해서 적용하여 공통된 양식을 만들었기 때문에 더 쉽게 파악할 수 있었습니다.
• 노션 스크럼 보드를 활용하여 시작전, 진행중(구현), PR(리뷰 대기), 피드백 반영 중, 완료로 진행사항을 나누어 팀원 별로 각자 어떻게 진행하고 있는지 한눈에 파악할 수 있었습니다.
 

• 개발
• 기능 구현에서 코드리뷰를 받으며 클린 코드와 다른 로직에 대해서도 시도를 하며 더욱 더 자신감을 얻게 되었습니다.
• 모르는 기능 구현에 대해서도 고민을 하고 질문도 하며 구현을 해나가며 완성도에 대해 고민 해볼 수 있는 시간을 가졌습니다.
• 코드 리뷰를 하면서 다른 팀원들과 토론을 하고 더 좋은 방법은 없을까 고민하는 과정이 좋았습니다. 또 미처 생각하지 못한 방법으로 로직을 설계하는 팀원의 코드를 보며 시야를 넓힐 수 있었습니다.
• 자신이 생각하는 개발 기능이 다른 사람들의 관점에서는 다른 방식으로 느껴질 수 있다는 사실을 깨달았습니다. 따라서 PR이나 이슈 등을 작성할 때, 개발할 내용을 구체화하고, 왜 이렇게 개발했는지 잘 표현해야 한다는 생각이 들었습니다.
• 자신이 생각하는 개발 기능에 대한 피드백을 받을 수 있는 점이 좋았습니다. 혼자만의 관점으로 개발을 하다보면 원래 개발하려고 하는 주제나 기능과 멀어지는 경우가 많은데, 서로 어떤 것을 개발할지에 대해서 이야기를 나누면서 꼭 필요한 기능에 대해서만 구체화할 수 있었습니다.
 

• 팀 문화
• 비동기적 소통과 급하게 처리해야 할 이슈가 있을 때를 구분하여 문제를 순차적으로 처리해나갈 수 있는 분위기가 좋았습니다.
• 중간에 떠오르는 아이디어나 건의사항이 있을 때 안건으로 다 같이 스크럼 시간에 보며 고민하고 회의하는 시간을 가지는 문화가 있어서 좋았습니다.
• 매일 스크럼 시간을 가져 이슈, 안건, 스프린트 진행 척도, PR확인, 공지를 매일 확인하여 스스로 할 일을 다시 되새길 수 있어서 좋았습니다.

• 기획
• 기획을 하며 놓친 기능들도 조금 있어서 아쉬움이 남습니다.
• 기획을 할 때, 세세한 기능을 생각하지 못했다는 점이 아쉽습니다. 특히나 기획만으로 기능을 구체화 할 때는 그 기능을 위한 숨은 의존성에 대해서 통찰하지 못했다는 점이 아쉬웠습니다. (따라서, 기능을 구현하면서도 그 기능을 구현하기 위하여 다른 부분을 다시 회의하고, 다시 이야기하는 과정에서 시간을 많이 소요하게 되었습니다)
• 기획을 꽤 오래 잡으면서 오버해서 힘을 쓴 듯한 느낌이 있습니다.

• 프로젝트 관리
• 작은 변경사항이거나 빠른 시간내에 일을 처리해야 하는 부분들도 있지만 프로젝트를 체계적으로 처리를 하려 하다보니 시간이 지체 되는 느낌이 있어서 아쉽습니다.

• 개발
• 짧은 기간 내에 React를 배우고, 그에 맞춰 개발하려다보니 원하는 기능을 쉽게 구현하기가 힘들었습니다. 특히나 마음이 급해져서 강의에서 들었던 코드를 변형하는 식으로 구현을 하는 경우가 있었는데, 이 경우 본인이 짠 로직이 아니다 보니 후에 로직을 확장하는 것이 어려웠습니다.
• 개발 기능의 분리 측면에서 아쉬웠습니다. 개발에 있어서, 의존성이 있는 부분을 한 사람이 맡아서 개발하는게 더 좋을 것 같은데 이러한 역할 분리가 미숙하여서 의존성이 있는 부분을 여러 사람이 맡는 일이 생겼고, 따라서 개발해야할 기능이 모호해지고, 개발 시 혼란스러워지는 점이 있었습니다.
• 사용자 UX에 관련된 부분을 미리 분리한 후, 구현시 적용시키지는 않고 있는데 간단한 UX에 관련된 부분은 개발하면서 함께 챙겼으면 좋겠습니다. 현재 UX에 모아놓은 부분만 너무 비대해지고, 컴포넌트에는 UX 적인 부분이 거의 반영되지 않은 점이 아쉽습니다.
 

• UI/UX 디자인
• 아무래도 팀원 대부분이 디자인에 익숙하지 않아 전체적인 view 디자인 설계에 시간이 조금 걸린 것 같습니다. 현재 기능을 구현하면서도 미처 생각하지 못했던 부분이 많아서 그때마다 협의하고 있습니다.
• 프로젝트 기획 처음에 각자 생각하고 있는 디자인이 모두 달랐기 때문에 디자인→기능 으로 토론하는 과정에서 소통에 어려움이 많았습니다. 이 문제는 각자 생각하고 있는 디자인을 먼저 그려서 공유한 다음 함께 토의해서 해결할 수 있었습니다.

• 팀문화
• 초반에는 서로의 의견을 강하게 주장하는 경향이 있어 조율하기 어려웠으나 점차 해결이 되었다고 생각합니다.
• 스크럼에서 결정된 사항은 스크럼 문서 뿐만이 아니라 다른 문서에도 빼두면 좋을 것 같습니다. 예를 들어서 스크럼때 DB MODEL이나, 테스트 용 아이디 비밀번호를 정리했는데 이 내용들이 따로 문서화되어있는게 아니라 스크럼 문서에 들어있었기 때문에 후에 내용을 찾는게 어려웠습니다.

• 코드리뷰
• 코드리뷰에 대한 많은 시간을 투자해야 함에 대한 압박감이 조금 있습니다.
• 각자 구현해야 할 기능이 많았지만 종종 코드 리뷰에 소홀해서 PR이 밀리는 경우가 있었습니다. PR이 올라오면 빠른 시간 내에 리뷰를 하면 좋을 것 같습니다.
• PR 단위가 커지면 코드 리뷰도 부담이 커지는 것 같습니다.
• 코드리뷰에서 구현한 기능에 대해서 자세하게 적어주셨으면 좋겠습니다. 그렇게 하면 코드를 보면서 기능 위주로 코드를 읽을 수 있을 것 같습니다.

• 기획
• 다음 프로젝트 때에는 기능, 의존성, 시간분배에 더 신경을 써야한다고 느낀다.

• 협업(개발)
• 짧은 기간 내에 React를 배우고, 그에 맞춰 개발하려다보니 원하는 기능을 구현하고 로직을 확장하는 것이 어려웠습니다.
• 처음부터 의존성, 확장을 고려하고 코딩하는 것은 쉽지 않다. 개발하면서 메모를 해놓고 추후에 리팩토링 할 때 해결할 수 있을 것이다.
• 처음 리액트로 개발하는 부분이었다고 생각해서 꾸준히 노력(공부)하면 확장되지 않을까 생각합니다.
• 개발 기능의 분리 측면에서 아쉬웠습니다. 의존성이 있는 부분은 한 사람이 맡아서 개발하는 것이 더 좋을 것 같다.
• 어쩔 수 없다고 생각합니다. 왜냐하면 기능이 몇개 없는 상황에서 한 사람이 다 맡기에는 시간적 여유도 없고 기능 분배가 한쪽으로 치우칠 수 있기 때문입니다.(동의합니다)
• 최소한의 단위로 가져가는 것이 가져가는 것이 좋을 것 같습니다.
• 사용자 UX 관련 부분을 너무 나중에 적용시키는 것 같습니다.
• 좋은 리팩토링을 목표로 시작했기 때문에 기본 구현 후 리팩토링 때 적용해야할 것 같습니다.
• 지금은 시간이 많이 부족하기 때문에 그 이후에 UX를 고려하고 그리고 시간이 남으면 꼭! 리팩토링하며 구현해보도록 하겠습니다.

• 팀문화(스크럼, 문서화 등)
• 지금도 충분히 많은 부분에서 정리를 하고 문서화 하고 있다고 느껴서 더 할 필요는 없다고 느낍니다.
• 서로 본인이 개발하고 있는 진행 사항에 대해 얘기 하는 것도 좋지만 컨디션에 대해서도 서로 이야기를 해보는 시간을 가져도 좋다고 생각합니다.
• 스크럼에서 결정된 사항은 스크럼 문서 뿐만이 아니라 다른 문서에도 빼두면 좋을 것 같습니다.
• 스크럼 진행 할 때 추후에 필요할 것 같으면 얘기해보도록 하겠습니다.(팀장 빼고도 다들 생각하면서 스크럼하기)
• 그 후에 필요하다고 생각이 들면 안건에 문서 링크 추가하자고 적어주세요!(혹은 직접 적어놓기)

• 코드리뷰
• 코드리뷰에 많은 시간을 투자해야 해서 압박감이 있다. PR에서 구현한 기능에 대해 자세히 적어 주셨으면 좋겠습니다.
• 코드 리뷰에 있어서 시간 분배를 잘 할 수 있도록 근본적인 방법을 찾아보는게 좋다고 생각합니다.
• pr을 요청하는 사람이 어떤 부분을 봐줬으면 좋겠는지도 자세히 적어서 그 부분을 집중적으로 더 봐준다.
• PR 단위를 적게 가져가면 좋을 것 같습니다.
• 각자 구현해야 할 기능이 많았지만 종종 코드 리뷰에 소홀해서 PR이 밀리는 경우가 있었습니다
• 스크럼 시작하고 PR 리뷰 요청을 먼저 언급하여 신속히 진행할 수 있게 진행되고 있습니다.
• 지금 당장 필요한 기능은 따로 슬랙에 요청 보내서 즉시 리뷰할 수 있도록 노력하면 좋을 것 같습니다.

6/22 자정 마지막 사진

6/22 최종 발표 날 마지막 스크럼

6/22 최종 발표 날 새벽 1시

6/22 최종 발표 날 새벽 3시

6/21 온라인 스크럼

6/17 새벽 어느날

6/15 온라인 스크럼

6/14 온라인 스크럼

6/13 온라인 스크럼

6/13 새벽 4시 🔥 

6/10 온라인 스크럼

6/9 온라인 스크럼

6/8 온라인 회의

6/7 오프라인

6/6 온라인 회의