[1차 프로젝트 회고] Jira 사용 후기
Jira를 선택한 이유
프로젝트 초반 시점, 프로젝트를 관리할 툴을 결정해야 했다.
구글에 서치해보니 굉장히 다양한 툴이 있었지만, 유료가 아니면 기능이 제한적인 것들이 많았다.
따라서 무료이면서 소규모 프로젝트 관리가 가능한 툴을 선정했다. 실제로 회사에서도 많이 사용되는 툴이었다.
우리 팀이 최종적으로 고민했던 툴은 두 가지 였다.
1. 노션
2. Jira
노션과 같은 경우, 개인적으로 일정관리나 문서를 정리할 때 자주 사용해본 적이 있었다.
노션의 사용자 인터페이스는 굉장히 직관적이면서 깔끔하기 때문에, 접근성이 좋다고 느꼈다.
그래서 프로젝트 관리에 적합한 툴이라고 생각했지만, 이미 많이 써봤던 툴이기도 했기 때문에..
좀 더 새로운 툴을 경험해보는 것이 좋을거라 생각하여 노션은 제외하게 되었다.
최종적으로 Jira를 선택하게 된 이유는,
Jira가 애자일 원칙과 스크럼 프레임워크를 기반으로 설계되었기 때문이다.
우리 팀의 목표는, 애자일 원칙을 따라 스프린트 단위로 프로젝트를 진행하는 것이었기 때문에, 이는 Jira의 설계 기반과 잘 맞는다고 판단하였다.
Jira는 애자일 방식의 프로젝트 관리를 지원하며, 스프린트 계획, 테스크 관리, 진척도 추적 확인 등이 가능했다.
또한 실제 회사에서도 많이 사용된다고 하여, 프로젝트 관리 툴을 Jira로 결정하게 되었다.
우리 팀이 정했던 Jira 사용 방식
1. 에픽을 추가하여 업무의 큰 틀을 나누었다.
다음과 같이, USER(회원), Delivery(배송지), Product(상품), Order(주문)-1차, Order-2차, Event/Alarm(이벤트/알람), Infra(인프라) 라는 에픽을 생성하여, 업무의 큰 틀을 나누었다.
2. Jira의 타임라인을 이용하여 스프린트 기간을 정하고, 관리하였다.
1차 스프린트에서는 USER, Delivery, Product, Order-1차를 3월 16일~31일까지(대략 2주),
2차 스프린트에서는 Order-2차와 Event/Alarm, Infra를 4월 1일~14일까지(2주),
3차 스프린트는 Buffer 기간으로 4월 15일~21일(1주)로 정하여 구체적이고 직관적인 타임라인을 생성하였다.
타임라인을 통해 스프린트 기간을 직관적으로 볼 수 있어서 좋았다.👍
3. 하위 이슈로 스토리를 추가하여 업무를 구체화하였다.
Order-1차라는 에픽에, 하위 이슈로 스토리를 추가하여 업무를 세부적으로 나타내었다.
예를 들어 Order-1차에서는 주문 생성, 주문 조회, 사용자 환불, 판매자 환불 등의 이슈로 나누어볼 수 있다.
Jira 사용시 발생했던 문제점
1. 다양한 협업 툴을 동시에 사용하다보니 Jira에 집중할 수 없었다.
우리 팀은 Google Docs, 노션, Jira, Github 등 다양한 협업 툴을 같이 사용하고 있었기 때문에,
노션에서 정보 공유를 하다가 데일리 스크럼을 작성하기 위해 Google Docs로 들어가는 등 여기저기 이동할 일이 많았다.
또한 데일리 스크럼에서 진행중인 일, 완료한 일, 앞으로 할 일을 나눠서 써놓았는데 Jira로 또 들어가서 이 작업을 다시 하는 것이 비효율적이라고 느꼈다.
그러다보니 다른 협업 툴의 우선순위에 밀려 Jira는 자주 들어가지 않게 되었고, 후반 즈음에는 거의 사용하지 않게 되었다.
2. 사용자 인터페이스가 직관적이지 않아 적응하기 힘들었다.
노션과 달리 Jira는 처음 봤을 때 이걸 어떻게 사용해야 하는건지 직관적인 느낌이 잘 오지 않았다.
그래서 사용 방법을 인터넷에서 따로 서치해야 했고, 적응하는 데 시간도 오래 걸려서, 초보자가 다루기 쉽지 않은 툴이라고 생각했다.
3. 프로젝트 진행에 차질이 생겨, 스프린트를 나눠 진행하지 않게 되었다.
프로젝트 설계 초반에는 스프린트를 1, 2, 3차로 나눠 진행할 예정이었다.
그러나 프로젝트 진행이 생각보다 느려져서, 스프린트의 경계가 점차 흐려졌고, 결국엔 프로젝트 하나를 하나의 스프린트로 진행하는 꼴이 되었다. 사실상 이것이 Jira를 사용하지 않게된 가장 큰 이유다.
( 프로젝트가 느려졌던 이유는, 팀원 모두가 Mybatis를 처음 써봐서, 적응하는 데 시간이 좀 걸렸기 때문이다. 그리고 나는 프로젝트 자체가 처음이기도해서 더더욱 적응할 것이 많았다. )
결론
이러한 문제점들 때문에 Jira는 더이상 프로젝트에서 사용하지 않게 되었다.
나와 팀원들은 MyBatis와 같은, 다른 요소들에 더 익숙해지기 바빴고.. 이러한 상황에서 Jira까지 익숙해지기가 힘들었던 것 같다. 우리 팀의 상황과는 잘 맞지 않는 툴이었던 것 같다.
다음 프로젝트에서 적용할 방식
1. 대부분의 기능을 하나의 협업 툴로 통일 - GitHub Projects
1차 프로젝트에서 너무 많은 협업툴을 동시에 썼기 때문에, 몇몇 툴에 대해서는 소홀해지는 경향이 있었다.
따라서 다음 프로젝트에서는 다양한 협업 툴을 사용하기 보다는, 대부분의 기능을 하나의 협업 툴로 통일할 생각이다.
그 협업 툴은 GitHub Projects로 결정하였다.
2. Jira는 사용하지 않음
물론 대부분의 기능을 Jira에서도 할 수 있다.
그러나 Jira의 자세한 기능까지 모두 사용해보진 않았어도, 스토리나 에픽 등과 같은 큰 흐름 안에 있는 기능들은 어느정도 다뤄봤기 때문에, 이후 프로젝트까지 Jira를 사용하는 것보다는 다른 툴을 다양하게 경험해보는 것이 더 좋을거라 판단하였다. 따라서 Jira를 사용하지 않고 GitHub Projects를 이용하기로 결정하였다.
3. GitHub Project를 선택하게된 이유
많은 툴 중에 GitHub Projects를 선택하게된 이유는 다음과 같다.
일단 GitHub은 협업에서 가장 강력하게 쓰이는 툴이므로, 이것에 대한 Projects 기능에 대해 알아보고 싶었다.
그리고 여러 기능을 하나의 툴로 합칠 때 발생하는 어려운 점들을 직접 경험해보고 싶었기 때문에, Git까지도 하나의 툴로 뭉칠 수 있는 GitHub Projects를 선택하게 되었다.
게다가 이 툴은 GitHub Repository와 직접적인 연관이 가능하므로, Git과 연동해서 쓸 수 있는 방식이 많아보였다.
이러한 이유들로, 다음 프로젝트에는 대부분의 기능을 GitHub Projects에서 진행해볼 예정이다!
결론
이번 프로젝트를 통해 애자일 방식의 프로젝트 관리와 Jira 툴 사용을 경험해볼 수 있었다.
여러 툴을 동시에 활용하며 협업하는 과정에서 다른 툴을 소홀히 하게 되는 어려움도 있었지만, 실제 프로젝트 진행 방식을 직접 경험할 수 있었던 좋은 기회였다.
특히 Jira의 장단점을 파악하고 다음 프로젝트에서 GitHub Projects를 활용하기로 결정한 점이 큰 수확이었다고 생각한다.
앞으로는 GitHub Projects를 사용할 때 발생 가능한 이슈나 문제점들을 검토하면서, 프로젝트 관리 툴 적용에 있어 더 실전적인 경험을 쌓을 계획이다.