요새 팀 프로젝트를 하면서 흘려 들었던(...) Jira를 활용해보고 있다.
특히 Automation을 적용해서 Ticket, Template을 자동화해보면서 여러모로 실질적인 개발보다 툴을 다뤄보는데 재미를 느끼고 있다. (원하는 형식으로 구현을 할 수 있다는 점에서 재미를 느끼는 중인 것 같다. 개발과 같다랄까...)

나름 시간을 투자하기도 했고, 툴이지만 개발자로써 이런 툴은 왜 사용하는지 고민을 해보게 된 점이 유익한 것 같아 오늘은 왜 Jira를 활용하기로 했는지와 셋업을 정리해보고자 한다.

---

Why Jira?

이미 많은 개발자 분들이 알고 있거나 들어본 적이 있는 Jira는 프로젝트 매니지먼트 툴이다. 예전에는 프로젝트 관리를 할 때 노션을 사용했었는데 생각보다 불편한 부분들이 많았다. 타임라인을 구축하더라도 페이지가 엇갈리는 경우도 있었고, 데이터가 안 보여지는 이슈부터 무엇보다 Github와 연동이 잘 안되는 상황도 겪었다.

테이블에 투두를 정리해서 나름 직관적인 관리를 시도해봤지만, '필수' 라는 개념이 점점 모호해지다보니 시간을 많이 소비했던 것 같다. 조금 더 명확한 구조로 작업에 대한 디테일한 정보를 쉽게 볼 수 있으면 좋겠다는 생각이 나를 Jira로 이끌었다. (미안해요 팀원...)

Integrating Jira

노션에 익숙해져서 그런지, 단순히 프로젝트 관리 툴로만 생각해서인지 생각보다 Learning curve가 매우 복잡했다. 단순 투두 작성 - 완료 형태가 아닌 Jira는 issue라는 것을 통해 모든 것을 구분 짓고 있었는데, 먼저 헤맨 Jira & Github 연동 방황기를 정리해본다.
(모든 내용은 개인용 기준으로 작성했습니다. 기업 아이디는 조금 더 다를 수도 있음.)

---

1. 프로젝트 생성

가장 먼저 Jira에 가입한 이후 홈페이지를 가면 개인 프로덕트를 볼 수 있다.

여기서 Create Project 버튼을 눌러 새로운 프로젝트를 생성하면 직무에 따라 제공되는 기본 템플릿을 볼 수 있는데, SW의 경우 Kanban, Scrum, Top-level Planning, Bug Tracking 등이 제공되고 있다.

상황에 맞게 활용하는 게 중요한데, 개인적으로 Kanban을 만들어보겠다!
이때 프로젝트 명칭(Key)를 설정하는데, 이건 추후 서술할 Issue Ticket을 위해 원하는 약칭을 만드는게 좋다!

2. Github 연동

프로젝트를 생성했다면 빈 보드가 보이고 투두를 작성하기 시작하면 될 것 같다.
하지만, Github을 연동해두면 훨씬 재밌는 작업을 할 수 있게 되기 때문에 연결을 해보자!

• 2.1 Jira Github 다운로드

  'More' 메뉴에서 Apps > Explore More해서 Github for Jira를 다운받자. Github 데이터와 레포 등을 Jira와 연결하기 위해 필요한 앱이기 때문에 무조건 필수!
  다운을 받으면 바로 organization을 검색할 수 있게 되는데, 필요한 Organization (나는 개인 Github를 선택했다)을 설정하면 된다. 여기서 전체 레포를 설정하거나 일부만 선택할 수 있는데, 추후에 레포를 추가하고 싶다면 Github for Jira에서 추가하면 된다.

• 2.2 Jira Github 오류 시

  간혹 Jira에서 Github repo를 제대로 못 읽는 경향도 있었다. 이럴 땐 아래와 같이 시도를 해보자!
  1. Code > Edit Repositories
  2. Add > Add code repository

여기서 Github를 선택해서 Repo를 다시 한번 설정하면 연결이 된다. 이마저도 안되면 나처럼 All repo가 아닌 selected repo만 연결하게 되면 이 문제가 발생하는 것으로 보인다. 권한 설정에서 문제가 있거나 repository 연결이 완전히 되지 않은 것으로 이해되는데, 이건 추가로 정리를 할 예정이다!

---

Jira In-depth

Issue Ticket

연동까지 됐다면 Jira와 지정한 Github Repo는 모든 내용을 공유하게 된다!
Github에 하는 모든 작업이 Jira에 보일 수 있게 된 것인데 여기서 앞서 설명한 Issue 타입이 활용된다. 위처럼 생성하는 Issue 마다 하나의 티켓이 발급이 되는데, 프로젝트 명칭(혹은 브랜치, Issue 명칭 등) 뒤에 숫자가 발급이 된다. 이 Issue 티켓으로 브랜치를 생성하고 커밋하면 Jira에서 자동적으로 커밋을 트래킹해주는 편한 기능을 제공한다! (브랜치, 커밋, PR도 한번에 모두 트래킹이 가능하다.)

Issue Types

Jira의 Issue는 아래와 같이 4가지로 구분된다. Story: 새로운 기능, 사용자들이 고려할 기능
Bug: 어플을 사용하며 발생하는 문제점들
Task: 해야하는 작업들이지만 기능 또는 실행에 문제가 없는 업무들

'Issue는 그냥 '문제' 아닌가?' 싶었는데, 개인이 처리해야 할 모든 행동 및 기능 등을 Issue로 통합해서 사용하고 있어 보였다. 한가지 특징은 Epic을 프로젝트를 나누는 대주제 같은 개념으로 권장하고 있던 점이다.

따라서 프로젝트를 쪼개는 단계에서 가장 먼저 Epic을 만들 것을 추천하고 있었다.
쉬운 예로 쇼핑 어플에서 쇼핑 기능을 개발한다면 '장바구니'가 하나의 Epic이 된다.

전체 프로젝트를 Epic으로 기능 혹은 파트별로 구분 짓고,
해당 Epic 안에 Story, Task 등으로 다시 한번 더 구분 지어 각 Issue별로 티켓을 발급할 수 있게된다.

---

Looking back...

Jira, 위키, Asana 등, 기업에서 사용되고 있는 다양한 매니지먼트 툴이 있다는 것을 알고 있었다. 단순히 '관리 툴'이라면 큰 차이가 없을 것이라고 생각했는데 생각보다 더 직관적이고 편리한 기능들이 구현되어 있었다. 직무별로 본인 업에 집중할 수 있도록 돕는 부분도 좋았지만, 한 눈에 어떤 구조와 단계별로 진행이 되고 있는지 등을 확인할 수 있던 점이 매력적이었던 것 같다. 개인 개발에도 Issue 티켓별로 묶어두니 놓친 부분은 뭐가 있는지, 어떤 코드를 작성했는지 등 다 볼 수 있던 점에서 팀 단위에서 사용하는 이유가 와닿았다.

더불어 Githook으로 Issue Ticket 자동 작성, 템플릿 수정 등 개발하면서 반복적이면서도 문제를 일으킬 수 있는 귀찮은 작업도 처리 가능하니 앞으로도 프로젝트를 관리하는데 잘 사용할 것 같다.