# Situation 상황
- QA 시작일 전날 오후에 staging 서버에 해당 스프린트 작업분 코드를 반영해서 배포했다.
- QA 시작 첫날 많은 버그가 나왔다.
- 개발자와 PO, PD, QA 등 담당자들이 서로 다르게 기획을 이해해서 뒤늦게 이슈가 되는 경우가 있었다.
# Task 과제
- 버그를 줄일 필요가 있었다.
- 서로 같게 개발 스토리를 이해하고 있는지 확인하는 단계가 필요했다.
# Action 행동
- 전 회사에서 개발자 프리뷰란 이름으로 QA 시작일에 개발자가 직접 기능을 소개하는 시간을 가졌던 것이 떠올랐다.
- 동료 팀원과 함께 팀 내에 개발자 시연을 제안했다.
- 스프린트 프로세스에 개발자 시연이 추가되어, 가능하면 QA 전에 늦어도 QA 시작일에는 시연을 진행하게 되었다.
- 시연 방법은 개발자가 개발한 기능을 스스로 PO, PD, QA 등 해당 스프린트 참가자들 앞에서 보여주는 방식으로 진행했다.
# Result 결과
- 개발자 시연 중에 개발자가 스스로 버그를 발견하는 경우가 많았다.
- 시연 중 발견된 버그는 굳이 QA 담당자가 다시 지라 티켓으로 재현 경로를 적을 필요가 없어서 QA 담당자의 시간과 노력을 절약할 수 있었다.
- 개발자가 시연 중 발견된 버그를 QA 시작 전에 빠르게 고칠 수 있어서 QA 때 버그 개수가 감소했다.
- 개발자 시연을 통해서 개발자와 PO, PD, QA 등 관련 담당자들이 기획대로 구현되었는지 QA 시작 전에 다시 한번 확인할 수 있었다. PO가 기획과 다르게 구현된 경우를 뒤늦게 발견하는 일이 줄었다.