JIRA 이해하기➡️ 이슈(Issue) 와 필드(Field)

JIRA Issue

Jira에 대한 활용도 이해를 높이기 위해서 Issue, Field에 대해서 작성해본다.

 

Jira 의 이슈는 프로젝트 내에서 일어나는 다양한 업무를 모델링하기 위해 여러 가지 항목들로 이루어져 있으며 이를 Issue Field라고 말함.

→ 이슈의 상세 정보에서 필드들을 볼 수 있으며 보드에서 이슈를 클릭하면 상세 정보 대화창이 표시됨.

• Jira 의 이슈에는 많은 필드가 있는데 필수 필드와 옵션 필드가 있고  상세한 항목은 프로젝트마다 다름.
• 한글 버전을 사용해도 JQL 쿼리는 영문 필드명을 사용 → 즉 담당자의 영문 필드명인 assignee 를 알아야 JQL 에서 담당자별로 조회 가능.

이슈 키(Issue Key)

• Jira 의 이슈는 반드시 하나의 프로젝트에 속해야 하며 이슈마다 유일한 값인 issue key 라고 불리는 식별자를 가짐.
  • 여기에서 이슈 키는 TKN-3 이며 이는 github 나 confluence, API 호출, 자동화를 통해 JIRA와 연동 때 필요.

 

• git 에서 커밋시 커밋 메시지에 이슈키를 입력해서 커밋 내역과 Jira issue 를 연동 →  Jira 의 이슈에 따른 소스 코드 레벨의 변경 사항을 추적 가능.
• 이슈를 연결할 경우 confluence 페이지에서 이슈 정보 확인가능.

 

 

이슈 유형(Issue type)

이슈가 어떤 유형인지 나타내는 이슈 유형(issue type) 필드 → 이슈 유형은 프로젝트의 종류에 따라 다르며 관리자가 추가/변경 가능

Epic(에픽)

• 에픽은 아주 큰 단위의 업무로 에픽의 정의는 회사나 팀마다 다를수 있으며 저는 주로 프로젝트의 주요 마일스톤이나 중단기 목표를 에픽으로 설정
  • 예로 새로운 사용자 경험을 제공하는 “웹사이트 2.0 출시” 를 하나의 Epic 으로 설정 가능
• 에픽을 달성하기 위해서는 관리 가능한 단위로 쪼개야 하며 하나의 에픽은 여러 개의 사용자 스토리나 작업으로 분할
  • 예로 위의 에픽은 다양한 Story 나 Task 로 분할해서 담당자별로 관리

Story(스토리)

• 요구 사항 분석 기법인 "사용자 스토리" 에서 이야기하는 스토리 유형으로 최종 사용자 관점에서 요구 사항이나 요청을 기록하는 이슈 유형
  • 스토리는 보통 epic 에 포함시키는 경우가 많음

task(작업)

• 팀에서 수행해야하는 작업으로 성능 개선이나 환경 구성등 일반적인 작업 기록 용도로 사용

버그(Bug)

• 버그는 제품에서 수정해야 할 결함으로 기능 구현이나 작업과 구분하기 위해 별도의 이슈 유형으로 등록

하위 작업(sub task)

• 하나의 task가 너무 클 경우 여러 개의 하위 작업으로 나눌수 있는데 이런 경우의 이슈 유형
• 하위 작업은 상위 이슈가 있어야 하기때문에 이슈 유형 드롭다운 박스에 표시되지 않고 독립적으로 생성할 수 없음.

• 하나의 issue 가 너무 커서 더 관리 가능한 작업으로 나눌 때나 사용자 스토리를 처리하기 위한 더 기술적인 내용이 필요한 경우에도 하위 작업을 사용

 

• 예로 상위 이슈가 스토리일때 스토리는 모든 팀원과 이해 관계자가 이해할 수 있는 비 기술적 언어로 작성-> 구현하기 위한 실제적인 기능 요구 사항은 서브 태스크로 등록하고 구현하는 개발 담당자가 관리
• 예로 제품을 개발하는 중에 새 기능을 구현하면서 문제가 되는 버그를 수정하는 작업을 한 프로젝트내에서 해야하는 경우 새로운 기능은 story 와 작업 이슈 유형으로 관리하고 버그는 버그 이슈 유형으로 관리

이슈 유형 추가

→ 기본 제공되는 이슈 유형이 적당한게 없을 경우 프로젝트 전용으로 별도의 이슈 유형 생성가능.

• 현재 프로젝트에 이슈 유형을 추가하려면 하단의 "이슈 유형 추가" 버튼을 누르면 Jira 가 기본 제공하는 이슈 유형중에 현재 프로젝트에 추가 안 된 유형인 버그와 스토리 유형을 표시

Summary

• 필드가 제목이 아니라 요약인 이유는 이 필드만 봐도 무슨 내용인지 짐작할 수 있도록 작성
  • 예시
    • 기능 개선 사항입니다. → 사용자 신규 가입시 github 인증 방식 추가 요청
    • 버그 확인 요청 드립니다. → firefox 78 에서 매출 정산 부분 화면이 깨집니다.

status(상태)

현재 워크플로우의 어떤 단계에 있는지를 나타내며 팀이 관리하는 프로젝트는 보드내에서 이슈가 위치한 컬럼과 이슈의 상태는 일치

담당자(assignee)

→ 담당자(assignee)는 현재 문제를 해결하도록 할당한 사람(변경가능)

• 담당자 지정 여부는 프로젝트와 팀의 정책에 따라 달라집니다. 예로 팀이 관리하는 프로젝트는 칸반이나 스크럼 방식을 사용하며 backlog 에 쌓인 일중에 선별해서 진행할 작업을 선택하므로 자동 담당자 지정이 적당하지 않음.
• 회사가 관리하는 프로젝트는 열어서 "프로젝트 설정" → "세부 정보"를 살펴 보면 기본 담당자를 지정할 수 있는데 기본 값은 미할당이며 이럴 경우 이슈를 등록해도 담당자가 자동으로 지정되지 않음.

• 운영 성격의 프로젝트에 많이 사용되는 방식은 프로젝트 리더로 자동 지정하고 리더가 이슈를 파악한 후에 다시 담당자를 지정

컴포넌트(component)

→ Jira 는 프로젝트에 하위 프로젝트를 둘 수 없으므로 컴포넌트를 논리적인 하위 프로젝트로 설정

회사가 관리하는 프로젝트만 컴포넌트 등록이 가능합니다.

• 예로 A라는 서비스를 개발하는 개발자 3명이서 back-end, front-end, android-app 로 역할을 나눴다면 세 가지를 별도의 프로젝트로 등록하고 관리해도 되지만 규모가 작아서 한 프로젝트로 관리하는 게 나을수 있음.
• 이럴 경우 각 파트를 프로젝트내 구성요소로 관리하면 다른 프로젝트로 이동하지 않고도 각 파트의 진행 상황을 공유 가능

보고자(reporter)

→ 현재 이슈를 등록한 사람으로 한 명만 가능하며  변경이 가능하지만 보통 변경하지는 않음.

labels

→ 레이블은 이슈를 카테고리화하고 분류해서 향후 검색이나 보고서 작성시 활용하기 위한 필드로 SNS 의 해시태그와 비슷

• 하나의 이슈는 여러 개의 레이블을 가질수 있으며 레이블 작성시 자동 완성이 되므로 이해하기 쉽게 작성해 주는 것이 용이
• 여러 단어로 레이블을 기술할 경우 공백대신 대시 - 문자를 사용해서 작성