애자일하게 일하기
이번 포스팅에서는 애자일 관리 도구인 Jira를 직접 사용해보며 기본 기능을 파악하고, 애자일의 원칙이 Jira의 기능에 어떻게 녹아있는지 살펴보도록 하겠습니다. TMI이지만 예전에 모 회사에서 인턴으로 근무하던 당시에 팀원 분들께서 '지라 확인했어?' 라는 말씀을 자주 하셨는데, 그 때 당시 팀에 워낙 외국어가 출중한 분들이 모여 계셨던 터라 한 치의 의심도 없이 "Jira = 잘 모르겠지만 업무 상황을 파악할 수 있는 문서를 뜻하는 일본어" 라는 생각을 했던 흑역사가 있습니다.. 대충은 때려 맞힌 것 같네요. 그런데 혹시 하고 찾아보니 정말 JIRA라는 이름을 ゴジラ(고지라)라는 일본식 이름에서 따왔다고 합니다. 고지라는 고질라를 뜻한다고 하는데요, 뭔가 엄청난 소프트웨어를 만들고자 했나 봅니다..(?)
+ 수정 : 아틀리시안 개발자들이 버그 찾아낼때 썼던 Bugzilla라는 툴에서 이름을 따왔다고 합니다...! 역시 고질라에서 시작한 건 아니었던 것으로.... (Bugzilla → Godzilla → Gojira → Jira가 되었다고 하네요..!)
근무 당시에 Jira에 대해 여쭤봤다면 Jira를 조금 더 빨리 접할 수 있었을 텐데요.. 지금 생각하니 너무 아쉽습니다. 그런데 생각해보니 당시 팀은 애자일 조직이 아니었는데, Jira를 어떻게 활용하고 있었던 건지 궁금해지네요. 아무튼, 이제 Jira에 대해 알아봅시다.
Jira는 Atlassian(아틀라시안)이 개발한 이슈 추적 소프트웨어입니다. 원래 Jira는 버그 및 이슈 추적 소프트웨어로 만들어졌지만 현재는 요구사항 및 테스트 사례 관리에서 애자일 소프트웨어 개발에 이르기까지 모든 유형에 적용할 수 있는 작업 관리 도구로 발전했다고 해요. 특히 애자일 방법론을 따르는 팀의 경우 Jira Software가 바로 사용할 수 있는 스크럼과 칸반 보드를 제공합니다. 보드를 통해 각 작업 항목의 상태를 빠르게 파악할 수 있고, 시간 추적 기능과 실시간 성능 보고서(번업/번다운 차트, 스프린트 보고서, 속도 차트)를 통해 프로젝트 진척 상황에 대해 판단할 수 있습니다.
Jira 공식 가이드에 따르면, Jira를 주로 사용하는 케이스는 아래와 같다고 합니다.
요구 사항 및 테스트 사례 관리를 위해
애자일 팀을 위해
프로젝트 관리 팀을 위해
소프트웨어 개발 팀을 위해
DevOps 팀을 위해
제품 관리 팀을 위해
작업 관리를 위해
버그 추적을 위해
Jira를 통해 애자일 팀을 관리할 수 있지만, 다양한 활용사례를 통해 꼭 애자일 팀이 아니더라도 필요에 따라 활용할 수 있겠다는 생각이 들었습니다. 하지만 이 포스팅에서는, 애자일 관리 도구로서 Jira의 기능에 대해 알아보고자 하므로 애자일 팀의 활용 사례에 대해 조금 더 집중해 보도록 하겠습니다.
Jira 공식 가이드에서는 Jira를 사용해 보드를 만들고 태스크를 할당하기 전 알아야 할 주요 용어를 안내하는데요, 먼저 주요 용어부터 알아봅시다.
스크럼, 칸반, 백로그 등 익숙한 용어들이 많이 보이는데요, 아무래도 소프트웨어를 개발하는 조직의 관리를 돕는 툴이다보니 기본적으로 관련 용어들이 많이 등장하는 것 같습니다. 애자일 방법론, 프레임워크인 칸반과 스크럼 중 스크럼 보드에 대해 자세히 살펴보도록 합시다. 스크럼이니, 예상해 본다면 스크럼 보드에서는 스프린트 기간동안 태스크를 할당할 수 있을 것 같습니다.
스크럼 프로젝트 템플릿을 생성하면 위와 같이 팀에서 관리/회사에서 관리 옵션을 선택해 스크럼 보드를 생성할 수 있습니다. 애자일 제 4원칙인 '함께 일하기', 즉 비즈니스 담당자와 개발자가 프로젝트 전체 기간동안 소프트웨어 개발 진척사항을 손쉽게 확인할 수 있도록 하기 위해서 팀원이 모두 확인할 수 있는 보드 형태를 제공하는 것이 아닐까 생각했습니다.
보드를 생성하면 백로그를 등록할 수 있습니다. 위의 사진과 같이 에픽/버그/스토리/태스크로 구분해 백로그를 등록할 수 있는데, 에픽이란 많은 사용자 스토리, 세부 단위로 나눌 수 있는 업무의 큰 틀을 뜻합니다. 보통 하나의 스프린트에 걸쳐 완수되는 목표가 아니라, 여러 스프린트에 걸쳐 완수되는 주요 기능들이 에픽에 해당합니다. 스토리는 유저스토리를 뜻합니다. 보통 에픽과 스토리는 PO가 작성하게 됩니다.
위와 같이 로드맵을 활용해 큰 범위의 목표(에픽)을 작성 후 하위에 유저스토리를 추가할 수 있으며, 가로축에 스프린트 기간을 표시할 수 있습니다. 또한 해당 백로그는 아래와 같이 보드를 통해 진행 상황을 파악할 수 있습니다.
보드에서는 이슈의 진행 상황을 통해 인사이트를 얻을 수 있는 기능을 제공하고 있는데요, 스프린트의 진행률을 파악하기 위한 번업/번다운 차트와 에픽 진행률 등을 쉽게 파악할 수 있도록 하는 도구를 이용할 수 있습니다.
애자일의 제 7원칙은 실행하고, 배우고, 개선하기 위해 소프트웨어의 개발 진척도를 측정하는 것인데요, 80%의 기능을 100% 개발하는 것을 목표로 하기 위해 작업 진척도를 파악하고 백로그를 조정하는 기능이 필요하지 않을까 생각했습니다. 또한, 제 8원칙은 지속 가능한 개발 속도를 유지하는 것인데요, 지속 가능한 개발 속도를 유지하기 위해 번다운 차트를 활용하여 작업 범위와 속도를 관리해 나갈 수 있을 것이라 생각했습니다.
정리하자면 PO는 Jira의 로드맵 기능을 사용해 주로 에픽(스크럼 목표 혹은 로드맵)을 작성하고 스프린트 기간 내 일정을 파악하며, 백로그 기능을 사용해 스토리(유저스토리) 형식으로 태스크를 할당합니다. 해당 스프린트에서 태스크의 진척도를 확인하기 위해 보드를 활용하고, 인사이트 기능(번업/번다운차트 등)을 활용해 속도와 작업 범위를 조정해 나갈 수 있습니다.
*참고사이트 : https://velog.io/@jinuku/팀에-맞게-Jira로-스크럼-관리하기-규칙-정하기