중간 회고록 (1)

🥰 KEEP(현재 만족하고 있는 부분, 계속해서 이어나갔으면 하는 부분)

기획 측면

• 팀원 분들의 적극적인 참여로 와이어 프레임과 페이지 디자인이 구체적으로 도출된 부분이 좋았습니다.
• 와이어 프레임을 만들면서 페이지 분배, 공통 컴포넌트 분리 작업이 동시에 진행되어 개발 단계로 빨리 넘어갈 수 있어 좋았습니다.

• 주요 타겟중 하나인 개발자들이 직접 서비스를 제작하는 만큼 서비스 기획 측면에서 니즈를 즉각 반영할 수 있어 주제 선정을 잘 했다고 생각합니다.

• 남경님 최고

협업 측면

• 프로젝트 시작 전 컨벤션과 팀 규칙을 정했지만, 프로젝트를 진행하면서 부족한 점들을 바로바로 얘기하여 정하는 과정이 좋았습니다.

• 유현님 최고

시간 관리 측면

• 회의전에 이야기할 부분을 정리해서 Discussions에 안건이 정리되어있어서 회의시간이 그나마 많이 줄어든것 같습니다.

• 혜경님 최고

개발 측면

• 형진님 최고

• husky적용으로 pre-commit단계에서 eslint, Prettier 적용

• marge전에 2명의 approve를 받아서 사전에 오류를 방지할 수 있었습니다.

• storybook으로 다른 사람이 만든 코드를 어떻게 사용하는지 미리 볼 수 있어서 코드 읽는 시간이 줄어든 것 같습니다.

기록 측면

• Github discussion을 이용해 안건들과 그에 대한 결정 사항들을 문서화하는 것이 좋았습니다.

• 현진님 최고

🙄 PROBLEM(개선이 필요하다고 생각하는 부분, 잠재적인 문제)

기획 측면

• API 명세서에 대한 이해가 높은 상태로 와이어 프레임 작업에 들어갔으면 조금 더 수월하게 할 수 있었을 것 같습니다.

• 와이어 프레임 작업 때 반응형에 대한 결정을 모호하게 한 탓에 모바일 화면에 대한 디자인과 구현은 뒤로 밀려나는 것 같습니다.

협업 측면

• 코어타임 또는 디스코드에 있을 때는 편하게 음성으로 대화했으면 합니다 ⇒ 음성 소통을 적극적으로

• PR 에 대한 approve 규칙이 모호한 것 같습니다. ⇒ 1인 1짝꿍 approve + 관련자 1 approve

• 프로젝트 초기라 리뷰 해야 할 PR 수가 많은 탓에 approve를 재촉하면서 진행해 코드 리뷰를 꼼꼼히 하지 못 한 것 같습니다.

• merge후 갑작스러운 에러에대한 대처를 해도 2명의 approve를 받아야하다보니 적용이 느려지는것 같습니다.

시간 관리 측면

• 회의 시간에 논의하고 결정을 하는 시간보다 안건들 읽고 이해 시간이 더 긴 것 같습니다.

개발 측면

• storybook이 좋기는한데 환경이 달라서 오류가 많이 뜨는것 같습니다.

기록 측면

• 매 스크럼에 대한 회의록 작성이 노션에도 필요해보입니다

• 대부분의 문서는 github에 작성되고 있어서 노션에도 문서화를 해야 할 지 고민입니다.

• 작성위치를 헷갈려서 찾기가 어렵습니다.

🧐 TRY(Problem에 대한 해결책)

협업 측면

• 미완성 PR 은 미완성 라벨 or 추후에 머지할 거라는 표시를 적어주셨으면 합니다

• 각자 필수 리뷰어 깐부 한 명씩 정하기

시간 관리 측면

• 회의 전에 안건들을 미리 읽으면 좋을 것 같습니다.

• 기능별 개발은 issue로 관리하고 있는데, 개인 개발 일정은 노션 timeline으로 관리하면 서로의 진척도를 확인하기 용이할 것 같습니다

개발 측면

기록 측면

• 매 스크럼에 대한 노션 회의록 작성