Jira BTS 초보자를 위한 가이드
애자일 프로젝트 관리를 위한 협업 툴 'BTS'
이전 직장에서는 Jira를 사용하지 않아서 쿠팡페이로 이직하고 처음 BTS라는 용어를 접했을 때 당황했던 기억이 난다. 우선 여기서 말하는 BTS는 방탄소년단이 아닙니다. 그런데 Jira를 사용하지 않는 기업에 종사하는 친구들과 얘기해 보면 아직도 BTS를 방탄소년단으로만 알고 있는 경우가 많다. 그래서 오늘은 BTS 초보자를 위해 Jira와 BTS에 대해 간단히 이야기하고자 한다. 완전 초보자 눈높이 설명!
우리는 애자일 프로젝트를 진행하며, 지속적인 릴리즈를 위해 개발 진행상황 및 QA 결과를 실시간으로 추적/관리해야 할 필요가 있다. 이러한 프로젝트 관리를 위해 Jira, Wrike, Trello, Redmine 등 많은 협업 툴이 존재하며, 기업이나 프로젝트의 규모/성격에 맞는 툴을 사용하면 된다.
규모가 작은 회사에서 QA 및 버그 관리 용도로만 사용하기엔 Flow, Mantis 같은 가벼운 협업 툴도 나쁘지 않다. 하지만 규모가 큰 조직에서 프로젝트를 진행하며 Product/Dev/QA 전체를 관리하기 위한 협업 툴을 찾는다면 Confluence와 Jira를 함께 사용하는 것을 추천한다. 둘 다 아틀라시안에서 만든 제품으로 같이 사용하면 연동이 용이하다는 장점이 있다. 실제로 아틀라시안에서는 업무를 할 때 아래와 같이 Confluence와 Jira를 같이 사용할 것을 권장하고 있다.
출처: https://www.atlassian.com/Confluence 페이지에서 Jira 매크로("/Jira")를 사용하여 Confluence 페이지와 Jira 이슈를 연결할 수 있다. 또한 JQL 매크로나 기존에 Jira에 만들어둔 필터를 활용하여 페이지에 특정 티켓을 불러올 수 있다.
예를 들어, 스프린트 회고 때 "Status"가 "≠Done"인 티켓을 불러와서 왜 완료하지 못했는지, 어떤 블로커나 이슈가 있었는지 이야기할 수 있다. 보통 회고록을 Confluence에 작성하는데, 티켓을 보기 위해 Jira를 왔다 갔다 하는 것이 아닌, 페이지 하나에서 모두 해결할 수 있어서 편리하다.
BTS (Bug Tracking System)
Jira의 프레임워크인 BTS는 Bug Tracking System의 약자로 일정 주기를 갖고 프로젝트를 진행하는 애자일에 특화된 협업 툴이다. 티켓을 생성하여 Backlog 및 Sprint를 만들 수 있고, Kanban, StoryPoint와 같은 보드를 통해 진행상황을 시각화할 수도 있다. 또한 Dashboard를 생성하고 디펜던시 팀들의 티켓을 필터링하면 하나의 대시보드에서 전체 개발팀의 Progress 및 Issue를 쉽게 추적/관리할 수 있다.
티켓 생성(Create Issue)
티켓 생성이라는 말의 의미를 모르는 초보자도 있을 것 같아서 티켓(Issue) 생성하는 화면을 우선 첨부했다. 실제로 티켓을 따고, 필터 및 대시보드를 만드는 방법은 나중에 따로 포스팅하겠다.
PO/PM은 Product Requirement에 따른 Epic이 정해지면, BTS에서 Epic을 생성한다. 그리고 개발팀에서는 Epic 별 개발 요건을 분석하고, Task 및 Sub-Task 단위의 티켓을 생성한다. 개발팀에서 티켓을 생성할 때 Epic에 링크를 해야 나중에 대시보드에서 Epic 별 진척도를 관리할 수 있다. 그러니 꼭! 올바른 Epic에 연결해달라고 개발팀에 사전에 부탁해야 한다. (안 그러면 두번 일해요..)
Create 화면 하단에 있는 'Epic Link'에서 에픽을 연결할 수 있다Issue Type
처음 티켓 생성 시, 프로젝트 팀은 당연히 알겠지만 Issue Type은 잘 모를 수 있다. 참고로 BTS에서 이슈 타입은 각 기업의 Jira 관리자가 설정/변경할 수 있어서 기업마다 다를 수 있다. 우선 가장 많이 사용하는 이슈 타입들에 대해 알아보자.
출처: https://www.atlassian.com/이슈 타입의 구조는 위와 같이 Initiative > Epic > Story > Task > Sub-Task 순으로 구성되며, 당연히 상위에 있을수록 더 큰 개념이라고 보면 된다. 이전 회사에서 진행한 마이데이터 서비스 런칭 경험을 토대로 아래와 같이 타입별 코멘트와 예시를 작성했다.
Initiative
기업에서 공동적으로 추구하는 목표로 다수의 Epic들이 취합되어 이룰 수 있는 넓은 의미의 Goal이다. KR(Key Result)과 접근 관점에서의 차이가 있다고 하나 개념은 같다.
e.g. 1Q 내에 마이데이터 서비스 런칭
Product
프로젝트의 최종 산출물로 사용자(고객)에게 제공되는 제품 및 서비스를 의미한다. PO는 고객 요구사항 분석을 통해 프로덕트에 고객의 니즈를 반영해야 한다. *Issue Type은 아니며, 아래 예시들의 이해를 돕고자 작성
e.g. 마이데이터 서비스 앱
Epic
이니셔티브를 구성하는 큰 덩어리이며, Epic의 합이 Initiative를 빠짐없이 구성할 수 있어야 한다.
e.g. 마이데이터 사업 허가 취득
Story
User Story라고도 부르며, 사용자 관점에서 작성한 Ptoduct 기능에 대한 설명으로 Product가 고객에게 가치를 제공하는 방법을 Who(role), What(goal), Why(benefit) 관점에서 서술하는 것이다.
e.g. 사용자가 보유한 전 은행 계좌를 한번의 인증만으로 간편하게 조회할 수 있어야 한다.
Task
Story를 만들기 위해 필요한 개발 작업을 의미한다.
e.g. XX은행 잔액조회 API 연동
Sub-Task
Task의 하위 작업으로 필요에 따라 생성한다.
e.g. API 명세서 정의
기업에서 처음 BTS를 도입하면 Jira 관리자를 정하여 권한을 부여하고, 관리자는 기업 및 프로젝트 팀별 특성을 고려하여 Issue Type, Workflow 등을 세팅해야 한다.
Workflow
워크플로는 작업이 처리되는 절차를 의미하며, 작업 흐름이라고도 부른다. 워크플로는 큰 틀에서 봤을 때 아래와 같이 구성된다.
출처: https://www.atlassian.com/To-Do
백로그 티켓으로 개발 대기 중인 상태이다.
Open
스프린트 플래닝에 포함된 티켓으로 개발을 시작하기 위한 사전준비(자료조사, 코드분석 등) 작업 중인 상태이다.
In-Progress
개발 중인 상태이다. 참고로 티켓에 StoryPoint를 찍으면 In-Progress 상태에 머물렀던 시간을 계산하여 어느 시점에 개발이 지연됐는지 확인할 수 있다.
In-Review
개발 완료되어 팀원들과 코드 리뷰 중인 상태로 리뷰를 통과해야 QA를 진행할 수 있다.
In-QA
QA 중인 상태로 잔존 이슈가 없는 경우에만 배포할 수 있다.
Done / Resolved / Closed
배포 완료된 상태이다.
+) 그 외 상태 값들
Ready to Review : 팀 리뷰가 가능한 상태
Ready to Deploy : QA까지 끝나고 배포 대기 중인 상태
On-Hold : 특정 사유로 개발/배포가 중단된 상태
Re-Open : On-Hold 였던 작업이 다시 열린 상태
마치며
오늘은 BTS를 시작하기 전에 알아야 할 기초 정보에 대해 공유했다. 다음에는 BTS Dashboard를 만들고, 프로젝트 타임라인/이슈를 관리하는 방법에 대해 이야기하겠다.
