[실무적용편 - Chap.2] 효과적이고 효율적인 Jira 활용 방안 공유

JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #2

이전 글에서는 JIRA를 도입하기 전에 무엇을 준비해야 하는지 알아보았습니다.

 

앞으로의 글은 JIRA의 기능 설명이 아닌 정말 프로젝트를 만들고 어떻게 설정해야 하는지에 대해 효율적인 방법을 제안하고, 수많은 프로젝트를 어떻게 관리해야 하는지에 대한 방안을 말씀드리려 합니다.

 

현재 글을 이해하고, 적용하기 위해서는 꼭 이전 글을 읽어 보시고 이 글을 읽어 보시길 바랍니다.

[STEEG - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1

 

이슈? 이거 꼭 만들어야 하나요?

보통 이슈란? 논점(論點) 또는 논쟁점. 순화어는 `논쟁거리', `쟁점', `논점'. 혹은 이벤트 성 심각도가 높은 활동을 의미합니다.

 

그렇다면 JIRA에서 이슈란 무엇일까요?

간단하게 설명하면 내가 해야 할 일을 구분해 놓은 것이 바로 이슈입니다.

 

예를 들면, "내가 개발을 해야 해 ~" 그럼 "신규 아이템"이라는 이슈 유형으로 이슈를 등록하고, 개발을 시작하게 됩니다. 이때, 이슈에는 많은 정보들을 입력하게 됩니다. 이 것은 차차 알아보도록 할 것이고, 이렇게 이슈들이 쌓이고, 모이게 되는 것이 바로 JIRA에서는 프로젝트라고 할 수 있습니다.

 

결론적으로 JIRA에서 프로젝트란? 이슈들의 모임이고, 이슈는 내가 할 일이라고 할 수 있습니다. 3단 논법으로 풀이하면 내가 할 일을 모아놓은 것이 프로젝트라는 결론을 얻을 수 있습니다.

 

이렇게 생성되고, 만들어진 이슈들(여기서 들은? JIRA에 백로그라 불립니다.)을 하나씩 해결해 나가면서 모든 이슈를 해결했을 때 비로소 프로젝트가 완료되는 것입니다. 이러한 이슈들을 해결해 나가는 방법으로 스크럼✔과 칸반✔이라는 방법론을 사용하게 되고, 이슈들(할 일들)은 유형을 분류하여 작업을 하게 되는 것입니다.

스크럼 프로세스

 

구분	스크럼	칸반
기간	기간이 고정된 이터레이션✔을 규정한다.	기간이 고정된 이터레이션은 선택사항.
약속	팀이 이터레이션에서 할 일의 양을 결정, 약속한다.	약속은 선택사항이다.
지표	계획하기와 공정 개선에 속도(velocity)를 기본 지표로 사용한다	리드 타임을 기본 지표로 사용한다.
팀	교차 기능 팀을 규정한다	교차 기능 팀은 선택사항, 전문가 팀도 허용한다.
아이템 크기	아이템들을 한 스프린트 안에 완료될 수 있을 정도의 크기로 잘게 쪼개야만 한다.	아이템 크기를 특별히 규정하지 않는다.
차트	번다운 차트를 규정한다.	차트 사용 규정 없다.
WIP	WIP 리밋을 간접적으로 한다.(스프린트마다)	WIP 리밋을 직접적으로 한다.(작업 흐름 단계마다)
추정	추정을 하도록 규정한다.	추정은 선택
아이템 추가	이터레이션이 진행 중일때는 아이템 추가 불가.	수용 능력이 허용한다면 새로운 아이템을 추가할 수 있다.
보드 소유	스프린트 백로그는 특정 팀이 소유한다.	칸반 보드는 다수의 팀이나 개인들 간에 공유하기도 한다.
역할	세가지 역할을 규정. (제품 책임자, 팀, 스크럼 마스터)	어떤 역할도 규정하지 않는다.
보드 초기화	이터레이션마다 스크럼 보드 초기화	칸반보드는 계속 유지
우선순위	제품 백로그에 우선순위를 정의할 것을 규정한다.	우선순위 정의하기는 선택 사항이다.

이터레이션은 어떤 객체의 원소에 하나씩 차례로 접근하는 것. 명시적으로든 암묵적으로든 반복문을 사용해 객체의 여러 원소에 하나하나 접근하면 그것은 이터레이션(iteration)이다.

 

어려운 용어들이 많이 나오지만 궁금한 용어는 구글링을 통해 알아보시고, 스크럼과 칸반의 가장 큰 차이점은 Time Boxing✔이 있고, 없고의 차입니다.

 

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

 

JIRA가 처음 도입되고 나면 모든 사람들이 가장 어려워하는 부분이 바로 이슈를 만드는 것이라고 해도 과언이 아닙니다.

정말 필수 입력 값이 요약(제목)만임에도 불구하고, 그거조차도 어렵다고 하는 사람들이 많습니다.

 

이슈를 귀찮아하거나 만들지 않겠다고 하는 사람들의 유형은 아래와 같습니다.

1. 이슈 만들 시간에 개발을 더 해야 한다.
2. 이슈에 무엇을 작성해야 할지 모르겠다.
3. 이슈를 등록하려고 보니 입력할 필드가 너무 많아서 모르겠다.
4. 이슈는 만들었는데 이것 어떻게 써야 할지 몰라서 방치하게 되었다.

정말 다양한 케이스가 존재하지만 이슈는 처음에도 말씀드렸듯이 내가 해야 할 일을 글로 쓰는 것과 마찬가지이며, 내가 쓴 글(할 일 = 이슈)을 동일 프로젝트 혹은 JIRA 시스템을 사용하는 모든 사람들과 공유하는 것이 목적인 것입니다.

 

그럼 또, "난 내가 하는 일 남에게 알리고 싶지 않습니다."라고 하는 분들도 있을 겁니다. "같이 일을 하고 있지만 제가 하는 일은 너무 보안 등급이 높아서 다른 사람들이 알면 안 됩니다."라고 하는 분들을 위해 정말 미친 듯이 세밀한 권한 관리가 가능하기 때문에 해당 팀원 혹은 파트원들끼리라도 관리를 위해 JIRA를 사용하게 만들면 됩니다.

 

결론적으로 마음만 먹으면, 혹은 의지만 있다면 전 직원이 사용 가능한 시스템이 바로 JIRA인 것입니다.

🤔 이렇게 얘기하면 제가 아틀라시안 직원인가? 하실 분들도 있으실 거 같지만 잘 찾아보시면 제 프로필이 여기저기 뿌려져 있습니다. 참고로 제 도메인은 교육 업계이고, QA를 하면서 JIRA를 사용하고 있을 뿐이라는 점 다시 말씀드립니다. 

 

오해 없으시길 바라고, JIRA를 좀 더 효율적으로 사용하고 싶은 분들께 도움이 되고자 글을 쓰는 것이니 필요하 신 분들만 읽어 주시길 바랍니다.

 

이슈 유형? 이것도 알아야 하나요?

네 알아야 합니다. 

이슈 유형은 앞에서도 말씀드렸듯이 내가 할 일을 카테고리화 해놓은 목록이라고 생각하시면 됩니다.

 

예를 들면 아래와 같습니다.

No	이슈 유형	설명
1	디자인 아이템	디자인 작업을 위한 이슈
2	신규 아이템	신규 개발을 위한 이슈
3	개선 항목	기존 기능에 대해서 개선을 위한 이슈
5	작업	업무 관리용 이슈
6	부작업	작업을 완료하기 위해 세분화된 작업 이슈

위 항목들은 예시입니다. 당연히 이슈 유형은 커스터마이징이 가능하며, 필요에 따라 다양한 이슈 유형을 생성할 수 있습니다. 현재 제가 하는 일은 테스트, 작업, 부작 업, VOC, 배포 등의 R&R을 가지고 있는데 모든 항목은 이슈 유형으로 구분하여 사용을 하고 있습니다.

 

이슈 유형을 구분했는데 어떻게 사용되는 거예요?

이번 시간은 여기까지 말씀드리고 마무리하겠습니다.

결론적으로 이슈 유형에 따라 업무 흐름이 달라지게 됩니다.

 

예를 들면 아래와 같습니다.

No	이슈 유형	업무 흐름
1	디자인 아이템	할 일 > 작업 중 > 작업 완료 > 검토 중 > 수정 중 > 수정 완료 > 이슈 종료
2	신규 아이템	할 일 > 분석 중 > 개발 중 > 개발 완료 > 테스트 > 이슈 종료
3	개선 항목	신규 아이템과 동일한 업무 흐름
5	작업	할 일 > 작업 중 > 작업 완료 > 이슈 종료
6	부작업	작업과 동일한 업무 흐름

내가 할 일이 어떠한 업무 흐름을 타고 진행되는지 이슈 유형별로 구분 가능하며, 업무 흐름도 맞춤형으로 생성이 가능합니다. 여기서 중요한 점은 이슈 유형이 생성되어 있어야지만 업무 흐름을 생성할 수 있고, 생성된 업무 흐름은 이슈 유형에 매핑시킬 수 있다는 것을 알아 두시길 바랍니다.

 

기본적으로 프로젝트를 생성하면 이슈 유형과 업무 흐름을 JIRA 시스템 내부적으로 자동 생성을 해주고 있습니다. 자동 생성된 것을 고쳐서 사용하는 것도 편할 수 있겠지만 필자가 추천하는 방법은 모든 설정 항목들을 수정하고, 향후 카테고리 화하여 모듈식으로 사용할 수 있도록 만드는 것이니 다르다는 점을 기억해 주시길 바랍니다.

 

대신 이렇게 모듈화를 하게 되면 기존 자동 생성되는 부분들은 쓰레기 값이 돼서 매번 수동 삭제를 해줘야 한다는 불편한 점도 존재합니다. 참고하세요.

 

요약 - 이슈가 무엇인지? 이슈를 왜 만들어야 하는지 인식을 변화시켜야 한다.

위에 길게 작성하였지만 분석 활동이 끝나고 JIRA가 도입되었다면 아마도 컨설팅 업체에서 사용법에 대한 교육을 한 두 차례 진행하였을 겁니다.

 

하지만 실 사용자들은 멘붕이 와 있겠죠? 그래서? 어떻게 쓰라는 건데?

다 똑같이 들었지만 아무도 모르는 이상한 현상이 발생하게 됩니다.

 

이유는 하나입니다. 그들은 이슈를 왜 만들어야 하는지 모릅니다. 이슈를 만들어서 쓰라는데 이슈를 왜 만들어야 하는지 모르니 왜 해야 하는지를 모르게 되는 것입니다.

 

그래서 시스템이 도입되고, 어느 정도 기본 교육이 되었다면, 이슈를 왜 만들어야 하는지에 대해서 캠페인을 해야 합니다. "할 일이 생기시면 이슈를 만들고, 작업을 시작하세요." 혹은 "이슈 하나 만들어서 담당자에게 할당하세요."의 캠페인을 모두가 용인할 때까지 해야 합니다. 이 시간은 정말 오래 걸릴 수도 있고, 의지가 있는 조직이라면 금방 될 수도 있습니다.

 

가장 좋은 건 역시 탑다운. 위에서 바로 "JIRA 잘 써라. JIRA 데이터로 평가할 거다." 하면 위에 활동이 매우 쉬워질 것입니다.

 

📌 한 줄 결론을 말씀드리면, "이슈는 곧 내가 할 일이고, 이슈를 모아 놓고, 쌓아 놓은 것이 바로 프로젝트다." 첨언하면, "그래서 이슈를 모두 해결하면 프로젝트를 종료한다."로 말씀드릴 수 있을 것 같습니다. 이슈를 모아놓고, 혹은 쌓아 놓은 것이 JIRA에서는 백로그라는 개념으로 사용되는데 이것은 애자일을 공부하시면 알 수 있는 개념이니 따로 설명드리지 않고, 링크 하나 남겨 놓도록 하겠습니다.

 

백로그 개념도

스크럼의 진행 과정

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, 아틀라시안, 지라, 컨플루언스