A
약 60초
용어 정의와 경계 케이스 사전 협의 경험
인턴 프로젝트에서 기획·디자인·QA 팀과 함께 2주 스프린트를 처음 경험했을 때, 가장 크게 느낀 건 각자가 쓰는 단어가 같아 보여도 전혀 다른 뜻인 경우였습니다. 기획이 말하는 상태와 개발이 말하는 status 필드는 범위가 달랐고, 이걸 초반에 안 맞추니 스프린트 중반에 두 번 다시 설계하게 됐습니다. 그 이후로 스프린트 킥오프 때 핵심 용어를 화이트보드에 함께 정의하자는 제안을 먼저 꺼내는 편입니다. QA와는 경계 케이스 목록을 초반에 같이 뽑았더니 막판 버그가 확연히 줄었고, 디자인과는 컴포넌트 명세가 확정되기 전까지 플레이스홀더로 연결하는 방식이 서로에게 편하다는 걸 경험으로 익혔습니다.
이 결의 특징
기획과 개발, QA 간 용어 차이(status 필드)를 발견한 후 스프린트 킥오프 때 화이트보드에서 핵심 용어를 정의한 구체 절차가 드러납니다. QA와 경계케이스 목록을 사전 공유한 행동이 막판 버그를 줄인 흔적이 기록됩니다.
이 결이 통하는 자리
커뮤니케이션 미스로 인한 비용을 미리 제거한 과정이 살아 있을 때 통합니다. 언어 통일이 얼마나 단순하지만 강력한 도구인지를 보여줄 때 면접관은 '이 사람은 팀의 번복을 줄이는 사람'이라고 판단합니다.