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

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

지난 글까지는 이슈가 무엇인지에 대해서 알아보았습니다.

다시 요약하자면 JIRA에서 "이슈 = 해야 할 일"이고, JIRA에서 "프로젝트 = 이슈의 모음"이라는 점만 잘 기억해 주시면 아래의 내용을 이해하시는데 도움이 될 것입니다.

 

이 전 글을 읽어 보지 않으시고, 아래의 개념을 이해하려고 하시면 좀 어려울 수 있는 부분입니다.

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

"난 JIRA의 이슈와 프로젝트에 대해서 잘 알아" 하시는 분들은 자연스럽게 아래 글을 읽어 보시길 바랍니다.

 

이번 시간에는 작업 흐름. JIRA에서는 Work Flow라고 하는 것을 알아보려 합니다.

이것은 JIRA의 꽃 중의 꽃이며, JIRA를 왜 BTS(Bug Tracking System)으로만 쓰는 것이 아까운지 이유가 바로 이 Work Flow에 있습니다.

 

JIRA에서 Work Flow란 바로 이슈의 흐름을 이야기합니다.

"이슈 = 해야 할 일". 그렇다면 Work Flow는 바로 "해야 할 일의 흐름"을 이야기합니다.

 

프로젝트 측면에서 Work Flow는 프로세스. 혹은 절차를 의미합니다.

약간 말장난 같지만 의미가 크게 다르다는 것을 유념해 주세요.

 

프로젝트의 Work Flow는 큰 의미로 착수부터 프로젝트의 종료까지의 프로세스를 의미하고, 세부적으로 산출물이 만들어지기까지의 일련의 절차를 의미합니다.

 

JIRA에서의 Work Flow는 개발을 하기 위한 나의 할 일의 흐름이 바로 그 차이입니다.

개발물을 산출물이라고 생각하면 프로젝트의 세부적인 프로세스라고 말할 수도 있습니다. 

🤣 사실 크게 중요하지 않습니다. 그냥 알아만 주시면 됩니다.

 

작업 흐름(Work Flow)이 필요한 이유가 무엇입니까?

그렇다면 JIRA에서 Work Flow가 필요한 이유는 무엇일까요? 

Work Flow가 필요한 이유는 내가 할 일의 길을 정해 놓는 것입니다.

 

만약, 내가 할 일의 흐름이 정해져 있지 않는 경우를 상상해 보세요.

내가 버그의 이슈를 하나 등록했다고 가정해 봅시다. 근데, 버그의 다음 담당자로 인사팀 직원이 가져갔다고 해봅시다.

이슈가 처리될 수 있을까요? 

 

이슈는 처음에 말씀드렸듯이 해야 할 일인데 하지 못하는 일이 되는 것입니다.

그래서 이슈는 명확한 흐름을 가져야 합니다. 그것을 JIRA에서는 Work Flow라고 명명하고 있습니다.

 

아래는 다양한 Work Flow 예시입니다.

JIRA 시스템 내에 다이어그램을 통해 아주 쉽게 작성 가능합니다.

제가 개인적으로 생각해 봤을 때 PPT 도형 넣고, 직선 연결할 줄 알면 누구나 할 수 있을 정도의 UI/UX를 가지고 있습니다. 다이어그램뿐만 아니라 텍스트 목록으로도 구성이 가능합니다. 하지만 사람은 그림에 눈이 먼저 가고, 이해하기 쉽기 때문에 다이어그램으로 Work Flow를 그려보시는 걸 추천드립니다.

 

이 글에서는 도구 사용법에 대해서는 자세히 설명드리지 않습니다.

Getting Started with Jira Software |Free Tutorial |Atlassian

😅 워낙 공식 홈에 자세하게 설명되어 있으며, 다른 많은 블로거나 사용자 분들이 올려놓은 글이 많기 때문인데요.

찾아보시면 정말 상세하게 설명을 잘해두었으니 여기서는 도구에 대한 사용법은 최대한 줄여서 말씀드리겠습니다.

 

작업 흐름(Work Flow)을 만들기 전에 무엇을 해야 합니까?

Work Flow는 앞에서도 잠깐 언급했듯이 할 일의 흐름이기 때문에 말 그대로 할 일의 흐름을 만들어야 합니다.

하지만 먼저 선행되어야 할 것은 할 일의 구분 바로 "이슈의 유형"을 먼저 만들어야 합니다.

 

이슈의 유형은 보통 프로젝트를 생성하면 기본적으로 JIRA 시스템에서 만들어 주고 있습니다.

 

기본적으로 만들어지는 이슈의 유형

보통은 위와 같이 만들어집니다. 하지만 이것은 정해진 것이 아닙니다.

 

📌 지금부터가 중요합니다. 

이슈 유형은 곧 할 일의 구분. 그렇다면 할 일의 구분을 어떻게 만들어야 할까요?

내가 하는 일만 구분해서 난 QA니까 버그와 개선사항만 있으면 될까요?

이렇게 생각하셨으면 JIRA를 BTS로만 쓰겠다고 생각하는 것입니다.

 

이것은 조금만 다르게 생각해서 내가 출근했을 때부터 일상의 모든 일을 이슈 유형으로 구분해 봅시다.

예시 하루 일과	이슈 유형	설명
출근	작업(Task)	일상적 업무
오전 미팅	미팅(Meeting)	회의
A 프로젝트 일정 수립	작업(Task)	일상적 업무
B 프로젝트 테스트	테스트, 버그, 개선사항	테스팅
점심 시간	작업(Task)	일상적 업무
B 프로젝트 테스트 결과 작성	테스트	테스팅
B 프로젝트 배포	배포(Release)	출시 업무
퇴근	작업(Task)	일상적 업무

위 표에서 가장 중요한 것은 바로 할 일들을 카테고리화 해야 하는 것입니다.

 

회사는 여러 부서 그리고 수많은 사람들이 존재합니다.

또한, 부서별 하는 일도 다르고 원하는 것도 다르고, 명확하게 하는 일들이 다릅니다.

이것을 카테고리화 다른 말로 하면 통합을 해야 합니다. 이것은 굉장히 어려운 일입니다.

부서별 하는 일에 대한 분석을 필수적으로 해야 하며, 요구하는 바도 다르기 때문에 지속적으로 개선해야 하는 부분입니다. 그리고 이것을 하기 위해 사용되는 문서는 바로 R&R 정의 문서입니다.

 

JIRA를 처음 도입하고, BTS로밖에 사용하지 못하는 이유는 바로 하는 일을 카테고리화 하지 못하고, 유형을 통합할 수 없기 때문에 어쩔 수 없이 상황이 만들어지는 것입니다. 큰 비용을 들여 구매하였지만 아는 사람도 없고, 어떻게 해야 할지도 모르겠고, 컨설팅 회사에서 알려주는 것이라고는 시스템 사용법뿐이고, 초기 구축 후 유지보수는 어떻게 해야 하는지도 모르는 상황들이 빈번하게 발생하는 것입니다.

 

이슈 유형을 카테고리화 하게 되면, 할 일의 흐름을 정의할 수 있게 됩니다.

정의가 완료되면 작업 or 업무(Task) 이슈로 50% 이상의 사람들이 아래와 같이 이슈를 사용하게 될 것입니다.(예시)

• 할 일 ➡ 작업 중 ➡ 작업 완료 ➡ 이슈 종료

📌 정리하면, R&R을 확인할 수 있는 문서와 인터뷰 등의 활동을 통해 각 부서의 업무 흐름을 분석하고, 카테고리화 하고, 카테고리화 된 이슈의 유형을 가지고, Work Flow를 만들어야 하는 것입니다.

 

그렇게 해서 만들어지는 이슈의 유형은 아래와 같습니다.

 

업무 분석을 통한 이슈 유형 정의

 

작업 흐름은 어떻게 사용해야 합니까?

앞에서 이슈(할 일)에 따라 카테고리화 한 작업 흐름은 어떻게 사용해야 할까요?

이때부터는 앞에서 잠깐 언급한 프로젝트의 프로세스에 적용하게 됩니다.

 

아래는 예시입니다.

최초 이벤트	액션	판단	분기	결과
ITSM VOC 접수	VOC 분석	개발 필요?	OK	개발 작업 흐름으로 이슈 처리
			NO	VOC 코멘트로 이슈 처리

위와 같이 하나의 이벤트를 프로젝트의 프로세스에 태워서 분기를 통해 작은 작업의 흐름으로 사용을 해야 합니다.

JIRA 사용의 가장 큰 목적은 바로 "개발을 잘하기 위함"입니다. 필요에 따라 ITSM으로 구축할 수도 있지만 현재 글은 ITSM 구축은 아니고, BTS로 사용하기에 아까운 JIRA에 대한 설명임을 알고 글을 읽어 주시기 바랍니다.

 

이렇게 작은 작업의 흐름을 통해 세밀한 작업을 할 수 있게 되고, 세밀한 작업을 통해 일정 관리가 가능해지며, 일정 관리를 통해 베이스라인(데드라인)에 맞춰 개발을 할 수 있을지에 대한 것을 예측할 수도 있게 됩니다. 이 내용도 나중에 자세히 다뤄 보도록 하겠습니다.

 

또한, 너무 복잡하게 작업 흐름을 구축하게 되면, 하나의 이슈를 처리하는 데까지의 시간이 너무 오래 걸리기 때문에 이슈의 처리율은 분석이 가능하지만 프로젝트(이슈의 집합)의 관점에서는 이슈 하나 처리하는데 왜 이렇게 시간이 오래 걸리는지 의문을 가질 수도 있습니다.

 

제 경험상으로는 하나의 이슈에 5~10(리오픈을 포함) 스텝이 가장 적절하다고 생각됩니다.

 

작업 흐름의 기본적인 구성은 아래와 같습니다.

📌 할 일(Open) ➡ 진행 중(In Progress) ➡ 완료(Done) ➡ 이슈 종료(Closed)

 

여기서 진행 중과 완료는 1 Set로 생각하시고 작업 흐름을 작성해야 합니다.

📌 할 일(Open) ➡ A 진행 중(In Progress) ➡ A 완료(Done) ➡ B 진행 중(In Progress) ➡ B 완료(Done) ➡ 이슈 종료(Closed)

 

상태 값과 버튼명 예시

 

위와 같이 구성하는 이유는 완료된 Task를 다음 담당자가 완료되었구나를 알리기 위함이고, 이것은 스크럼/칸반 보드를 만들 때 유용하게 사용됩니다.

 

최초 분석된 프로세스를 JIRA의 다이어그램(or 목록)으로 작업 흐름을 만들어야 합니다. 

1. ➡ 부분 : JIRA 이슈 상단 버튼명으로 정의됩니다.

2. 상태 값 : JIRA 이슈의 상태명으로 정의됩니다.

 

JIRA 이슈에서 버튼명과 상태 값 예시

 

여담으로 JIRA의 가장 큰 장점이 바로 확장성이기 때문에 내가 생각하는 그 어떤 프로세스(우선 제가 생각했던 건 다 그릴 수 있더라고요)도 시스템적으로 구축 가능하도록 되어 있습니다. 문제는 Money죠. 회사에서 Money를 마음대로 사용하지 못하기 때문에 한 번 구축할 때 필요로 하는 부분을 잘 분석하시어 초기에 견적을 내는 것도 중요합니다.👌

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

분석 관련 글은 #1을 참고하시기 바랍니다.

 

요약 - 작업 흐름을 통합할 수 있도록 이슈를 카테고리화 해야 한다.

이번 챕터에서 가장 중요한 것은 다양한 작업의 흐름을 카테고리화 하여 이슈(할 일)의 목록으로 정의하는 것입니다.

위에 주저리 많이 작성하긴 했지만 이것만 기억하시면 됩니다.

 

JIRA를 사용하는 데 있어서 가장 중요한 부분이며, 아마 가장 어려운 부분이기도 합니다. 이때부터 JIRA 사용자들의 불만과 불평 그리고 "못. 쓰. 겠. 다."와 싸움의 시간이 찾아올 것입니다.😭

 

"우리 프로세스 JIRA로 못 만들겠네?", "우리 이런 거 필요한데 없던데?" 등 새로운 것에 적응하지 못하는 사람들이 수면 위로 올라올 텐데요. 이때부터는 "이 사람들을 교육하고, 설득하느냐.", "나도 모르겠다. 대충 쓰자" 하는 기로에 서게 될 거예요.😅

 

이제 시작입니다. 지금까지 잘해 주셨습니다. 포기하지 마시고, JIRA를 잘 사용하여 개발이 잘 될 수 있도록 끝까지 힘내시길 바랍니다. 👍

 

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