우리 팀은 프론트엔드 3명, 백엔드 4명으로 구성된 만큼 파트 간의 원활한 소통과 API 인터페이스 조율이 프로젝트의 성패를 좌우합니다. 불필요한 회의로 인한 컨텍스트 스위칭(Context Switching)을 최소화하고, 개발에 집중하기 위해 아래의 회의 룰을 따릅니다.
1. 정기 동기화 (Regular Sync)
데일리 스크럼 (Daily Scrum)
- 목적: 단순 진척도 보고가 아닌, 이슈(Blocker) 파악과 파트 간 조율에 집중합니다.
- 시간: 매일 오전 10시, 최대 15분 타임박싱(Timeboxing)
- 진행 방식: Jira의 활성 스프린트 보드를 화면에 띄워두고 티켓(HSC-XXX) 위주로 짧게 공유합니다.
- 어제 완료한 티켓 / 오늘 진행할 티켓 / 현재 작업에 방해가 되는 요소(Blocker)
- ⚠️ 스크럼 도중 특정 기술에 대한 깊은 논의가 길어질 경우, 스크럼 종료 후 관련 담당자들만 남아 별도로 논의합니다.
주간 스프린트 미팅 (Weekly Sync)
- 목적: 지난주 작업 회고 및 이번 주 진행할 Jira 이슈(Story, Task) 산정
- 진행 방식: 개별 작업의 우선순위(P0~P3)를 조정하고, 파트 간 의존성이 있는 작업(예: BE의 특정 API 배포 후 FE가 연동해야 하는 작업)의 일정을 맞춥니다.
2. 파트 간 협업 미팅 (FE ↔ BE)
프론트엔드와 백엔드 간의 병목을 줄이기 위해, 기능 개발 전 API 명세 협의를 최우선으로 합니다.
- API Contract (명세) 미팅: 새로운 화면이나 기능을 기획할 때, 백엔드 개발에 들어가기 전 프론트엔드와 백엔드 담당자가 모여 API URL, Request/Response JSON 규격(아까 정한 컨벤션 기반)을 먼저 확정합니다.
- 게릴라 미팅 (필요시): 7명 전원이 모일 필요 없이, 해당 이슈(Jira 티켓)와 관련된 실무자들만 즉석에서 모여 문제를 해결하고 결과를 텍스트로 공유합니다.
3. 룰(Ground Rules) : “No Agenda, No Meeting”
- 사전 안건 공유: 회의를 소집할 때는 목적과 논의할 안건을 슬랙이나 Notion에 반드시 미리 공유합니다. 안건이 명확하지 않은 단순 진행 상황 공유 회의는 지양합니다.
- 회의록(Minutes) 필수 작성: 휘발되는 대화를 막기 위해, 모든 회의의 결론과 액션 아이템(Action Item, 누가 언제까지 무엇을 할 것인가)은 Notion 회의록에 문서화합니다.
- 지라(Jira) 연동: Notion 회의록에서 논의된 결과물이나 변경 사항은 반드시 연관된 Jira 티켓에 링크(또는 코멘트)를 남겨, 히스토리가 끊기지 않게 추적합니다.