“JIRA하고, 자빠졌네!”
세종대왕은 확실히 개발자의 두뇌를 가지고 있었던 게 분명합니다. 먼 시대를 지나 오늘날 QA를 하는 저에게 응원을 해주시니 말입니다. 하지만 그는 틀렸습니다. 걱정과는 다르게 다행히 자빠지진 않았거든요. 지라(JIRA) 덕분입니다.
갑자기 지라 이야기가 나와 당황하셨죠? 축하해주세요. 드디어 브랜디도 지라를 사용하게 되었답니다. (짝짝짝!) 지라 도입은 처음이라 세팅부터 쉽지 않았는데요. 이번 글은 눈물겨웠던 지라 세팅 과정과 브랜디의 이슈관리를 소개하겠습니다.
스크럼(Scrum)은 요구 사항 분석부터 하는 칸반(Kanban)보다 효율적입니다. 안드로이드와 iOS로도 나눠져 있고 업무를 짧게 반복하기 때문이죠. 스크럼에 적합한 워크플로우(Workflow)를 볼까요? 이것은 실제로 브랜디 R&D본부에서 사용하고 있기도 합니다.
IN PROGRESS: 이슈나 개발 요건을 티켓으로 만들면 IN PROGRESS 상태가 됩니다.
RESOLVED: 이슈나 개발 요건이 완료되면 RESOLVED 상태로 변경합니다.
QA: QA가 필요한 개발 요건은 QA상태로 변경합니다.
PASS: 이슈 또는 개발 요건이 수정되었거나 문제가 없다면 PASS 상태로 변경합니다.
FAIL: 이슈 또는 개발 요건이 제대로 수정되지 않았거나 다른 이슈가 발생하면 FAIL 상태로 변경합니다.
QA불필요: QA가 필요하지 않은 개발 요건은 QA불필요 상태로 변경합니다.
DONE: 이슈를 해결했거나 개발을 완료하면 DONE 상태로 변경합니다
CLOSE: 담당 팀장님이 이슈 확인 후 CLOSE 처리합니다.
예를 들어보겠습니다. 킥오프 서비스 회의를 하고, SB를 제작, 리뷰합니다. 이후에 디자인팀과 개발팀 일정을 공유하고 스크럼 마스터는 스프린트 주기를 책정하죠. 스프린트가 시작되면 개발자는 스토리 티켓을 작성하는데요. 개발이 끝나면 QA가 필요한 티켓은 테스트를 진행하고, QA가 종료되면 스프린트도 종료됩니다.
위의 이미지는 Epic 티켓입니다. Android, iOS, 이슈 등 모든 티켓은 Epic 안에서 관리합니다. 한 곳에서 한꺼번에 관리하기 때문에 히스토리 관리가 편하고, 진행 상황도 확인할 수 있습니다.
개발팀의 티켓 생성입니다. 개발자는 SB를 보고 개발 티켓을 작성합니다. 개발 티켓 작성 후에 개발이 진행되며 QA 판단 여부를 체크해 QA 상태로 변경합니다. 변경된 티켓에 관한 QA가 진행되며 문제가 없으면 해당 티켓은 종료됩니다.
다음은 이슈 생성입니다. 파악한 SB는 디자인 시안과 비교하며 개발이 된 Android, iOS 테스트 파일을 QA합니다. QA를 진행할 때 발생한 이슈는 지라 티켓으로 등록하여 이슈를 관리합니다. 모든 이슈 티켓 종료되면 해당 차수의 QA는 끝나고 마침내 상용에 배포합니다. 배포가 완료되면 필수 및 크리티컬 리그레이션 테스트가 진행됩니다.
실수는 항상 모든 것이 끝난 이후에 보이기 마련입니다. 수십 번 QA를 해도 보이지 않던 문제들이 상용에 올라간 이후부터 보이기 시작하죠. 스크럼은 이런 실수들을 가장 최소화할 수 있는 툴이 아닐까 생각합니다. 물론 아무리 좋은 툴을 써도 팀원들과 함께 뭉치는 것보다 중요한 것은 없겠죠. 다음 글은 자동화를 주제로 찾아뵙겠습니다. JIRA하고 자빠지지 않는 개발자가 됩시다!
글
김치영 대리 | R&D PM팀
kimcy@brandi.co.kr
브랜디, 오직 예쁜 옷만
#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #JIRA
관련 스택
가입하기
