🥰 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으로 관리하면 서로의 진척도를 확인하기 용이할 것 같습니다
기록 측면
- 매 스크럼에 대한 노션 회의록 작성