JIRA Issue 와 Field

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

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

Open

Jira 의 이슈에는 많은 필드가 있는데 필수 필드와 옵션 필드가 있고  상세한 항목은 프로젝트마다 다를수 있습니다.

이슈 키(Issue key)

Open

Jira 의 이슈는 반드시 하나의 프로젝트에 속해야 하며 이슈마다 유일한 값인 issue key 라고 불리는 식별자를 가집니다.

여기에서 이슈 키는 TKN-3 이며 이는 github 나 confluence, API 호출, 자동화를 통해 JIRA와 연동할 때 꼭 필요합니다.

예로 Bitbucket 을 연동했다면 issue 상세 화면에서 개발 필드에 "브랜치 만들기" 를 볼 수 있으며 클릭해서 바로 빗버킷에 해당 이슈와 관련된 브랜치를 만들어서 개발 작업을 진행할 수 있으며 이때 브랜치 명은 이슈키와 요약 필드를 결합해서 자동으로 생성됩니다.

git 에서 커밋시 커밋 메시지에 이슈키를 입력해서 커밋 내역과 Jira issue 를 연동할 수 있으며 이럴 경우 Jira 의 이슈에 따른 소스 코드 레벨의 변경 사항을 추적할 수 있습니다.

또 다른 예로는 confluence page 작성시 이슈 key 를 넣어서 지라 이슈와 confluence page 를 연결할 수 있습니다. (https://lesstif.atlassian.net/wiki/spaces/TEST/pages/865107984 페이지 참고)

이슈를 연결할 경우 confluence 페이지에서 이슈 정보를 볼 수 있고 Jira 이슈에서 관련된 confluence page 를 확인할 수 있습니다.

이슈 유형(Issue type)

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

이슈 유형마다 별도의 아이콘이 있어서 구분하는데 도움을 주며 Jira 는 다음과 같은 이슈 유형이 있습니다.

Epic(에픽)

에픽은 아주 큰 단위의 업무로 에픽의 정의는 회사나 팀마다 다를수 있으며 저는 주로 프로젝트의 주요 마일스톤이나 중단기 목표를 에픽으로 설정합니다.

예로 새로운 사용자 경험을 제공하는 “웹사이트 2.0 출시” 를 하나의 Epic 으로 잡을 수 있습니다.

에픽을 달성하기 위해서는 관리 가능한 단위로 쪼개야 하며 하나의 에픽은 여러 개의 사용자 스토리나 작업으로 분할할 수 있습니다.

예로 위의 에픽은 다양한 Story 나 Task 로 분할해서 담당자별로 관리하면 됩니다.

Jira Cloud 는 에픽과 종속성으로 프로젝트의 기본 로드맵을 작성할 수 있습니다.

Story(스토리)

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

task(작업)

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

버그(Bug)

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

하위 작업(sub task)

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

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

예로 상위 이슈가 스토리일때 스토리는 모든 팀원과 이해 관계자가 이해할 수 있는 비 기술적 언어로 작성하지만 이를 구현하기 위한 실제적인 기능 요구 사항은 서브 태스크로 등록하고 구현하는 개발 담당자가 관리하면 됩니다.

이슈 유형을 통해 팀은 하나의 프로젝트에서도 다양한 유형의 작업을 처리할 수 있습니다. 예로 제품을 개발하는 중에 새 기능을 구현하면서 문제가 되는 버그를 수정하는 작업을 한 프로젝트내에서 해야하는 경우 새로운 기능은 story 와 작업 이슈 유형으로 관리하고 버그는 버그 이슈 유형으로 관리할 수 있습니다.

Jira 는 세밀한 조정이 가능하기 때문에 각 이슈 유형마다 다른 필드, 화면 및 워크플로를 설정할 수도 있습니다.

팀이 관리하는 프로젝트에서는 Epic, 작업, 하위 작업 3가지 유형을 제공합니다.

보드에서도 바로 이슈 생성이 가능한데 1)에는 Issue 의 Summery 를 넣고 2)에는 생성할 이슈의 유형을 선택합니다.

이슈 유형마다 필드와 화면을 다르게 설정할 수 있습니다.

아래는 작업 이슈 유형의 화면입니다.

에픽은 다른 화면이 되도록 관리자가 컨텍스트 필드를 설정할 수 있습니다.

이슈 유형 추가

기본 제공되는 이슈 유형이 적당한게 없을 경우 프로젝트 전용으로 별도의 이슈 유형을 만들 수도 있습니다.

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

여기에서 추가할 이슈 유형을 선택해 주면 되며 우리는 현재 프로젝트에 스토리 이슈 유형을 추가하겠습니다.

전혀 새로운 이슈 유형을 추가하려면 "이슈 유형 만들기" 를 클릭하고 이슈 유형 이름과 설명을 적어주면 됩니다.

예로 에픽을 사용자 스토리로 나누기 위한 "사용자 스토리" 이라는 이슈 유형이 필요할 경우 이름에 개선을 넣고 설명에 "사용자 스토리" 이라고 넣고 추가를 눌러 줍니다.

이제 사용자 스토리 이슈 유형을 추가했으니 스토리를 하위 작업으로 분할하는 예를 알아 보겠습니다.

 프렌차이즈 관리 서비스를 개발중인데 다음과 같은 사용자 스토리를 작성했다고 가정해 보겠습니다.

"지점 관리자는 관리 시스템에 로그인한 후에 지점의 당일과 이전 매출 집계 및 상세 내역을 확인할 수 있다"

"매출 목록은 2초안에 표시되어야 한다. " - 제약 사항"

이 스토리를 구현하기 위한 기술적인 내용은 하위 작업을 분리해서 처리하는 게 좋습니다.

예로 "매출 이력 db 테이블에서 데이타를 가공해 집계 및 상세 이력을 표시" 하는 웹 페이지 작업을 하나 만들수 있습니다.

여러 지점이 있을 경우 권한이 없다면 다른 지점의 내역을 보면 안되므로 "지점별 매출 데이타 접근 권한 관리 구현" 을 하위 작업으로 만들수 있습니다. 

그리고 빠르게 집계를 보여주기 위한 "정산 전용 테이블 설계 및 데이타 수집" 을 하위 작업으로 만들 수 있습니다.

스토리 이슈 유형을 사용할 경우 구현에 필요한 기술적인 내역은 하위 작업으로 분할하는 예제를 보여 드렸습니다.

우측에 "이슈 제한" 버튼이 있는데 특정 이슈 유형은 보안에 민감할 경우 접근을 역할별로 제한할 수 있습니다.

이슈 유형을 추가할 경우 우측 상단의 "동작" → "이슈 유형 편집" 을 클릭하고 이슈 유형 목록에서 사용할 이슈 유형을 추가해 주면 됩니다.

만약 기존에 없는 새로운 이슈 유형이 필요하면 우측 상단의 "이슈 유형 추가" 를 누르고 추가해 줍니다.

이슈 필드 추가

이슈 유형을 클릭하면 이슈를 이루는 필드 정보를 확인할 수 있습니다.

예로 팀이 관리하는 프로젝트의 이슈 유형에 들어가서 에픽을 보면 컨텍스트 필드에 "start date" 와 기한 필드가 있는 것을 보실수 있습니다. 지난 시간에 프로젝트 로드맵을 만들기 위해 epic 을 만드는 예제를 설명드렸는데

에픽은 시작과 종료가 있었고 마우스로 끌어다가 일정을 설정한 것을 기억하실 겁니다.

그래서 epic 은 "start date" 와 기한 필드가 존재합니다.

이번에는 작업 필드를 보시면 컨텐스트 필드가 에픽과는 다르게 2개의 필드가 빠져 있는 것을 확인할 수 있습니다.

보통 스크럼은 작업별로 기한을 두지 않고 여러 작업을 스프린트로 묶어서 단기간에 실행하며 칸반도 동시 작업수 제한만 두지 별도의 일정을 설정하지만 않습니다.

기한을 설정 안 하는 것은 애자일이 유연한 방법론이고 그만큼 규정이 덜 빡빡하다는 의미이고 작업에 기한이 없어야 한다는 의미는 아닙니다.

만약 팀에서 작업별로 기한 관리를 하는게 정책이라면 여기에서 필드를 추가하면 됩니다. 우측에 보시면 여러 필드가 있는데 필드에 마우스를 올리고 우측 상단의 정보  버튼을 누르면 필드의 샘플 값을 볼 수 있습니다.

타임스탬프 필드는 날자와 시간을 같이 표시하고 날짜 필드는 날자만 표시하는 것을 확인할 수 있습니다.

작업의 기한은 날자 필드가 더 정확한 것 같으니 시작일, 종료일이라는 2개의 날자 필드를 추가해 보겠습니다.

이제 "변경 사항 저장" 을 하고 다시 프로젝트로 돌아와서 해당 이슈를 클릭해 보면 2 개의 필드가 추가된 것을 확인할 수 있습니다.

클래식 sw 프로젝트도 "프로젝트 설정" → "이슈 유형" 메뉴에서 상세한 이슈 유형을 확인할 수 있습니다.

다만 클래식 프로젝트는 유형에 필드를 추가/변경하는 게 Jira server 버전처럼  매우 복잡합니다.

이슈 필드를 추가/변경하려면 화면과 워크플로우,  필드를 같이 설정해야 해서 전문 Jira 관리자가 있지 않으면 설정하기가 매우 까다롭습니다.

클래식 프로젝트의 이슈 필드 설정 방법은 향후에 별도의 과정으로 설명 드리겠습니다.

Summary

다음 필수 필드는 요약(summary) 필드입니다. 요약은 이슈가 무엇인지에 대한 한 줄 설명과 같은 역할을 합니다.

필드가 제목이 아니라 요약인 이유는 이 필드만 봐도 무슨 내용인지 짐작할 수 있도록 잘 기술하라는 의미인데 다음과 같이 요약 필드를 적는 경우를 많이 보았습니다.

• 기능 개선 사항입니다.

• 버그 수정 요청 드립니다.

이는 회사의 프로젝트와 제품이 늘어나고 고객이 많아질 경우 기존에 수행한 이력을 찾아볼 경우가 많은데 필요한 정보를 쉽게 찾지 못하게 하고 업무 이력의 지식화를 방해하는 나쁜 요약 필드 작성 방법입니다.

요약 필드의 의미에 맞게 다음과 같이 어떤 내용의 이슈인지 판단할 수 있게 작성하는 게 좋습니다.

• 기능 개선 사항입니다. → 사용자 신규 가입시 github 인증 방식 추가 요청

• 버그 확인 요청 드립니다. → firefox 78 에서 매출 정산 부분 화면이 깨집니다.

status(상태)

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

현재 프로젝트의 워크플로우는 이슈 상세화면에서 워크플로 보기를 선택하면 됩니다.

설명(description)

설명(description) 필드는 이슈에 대한 상세한 내용을 기술하는 옵션 필드로 상단의 에디터 기능을 사용하여 내용을 꾸밀수 있습니다.

형식보다 내용이 더 중요하다는 말이 있지만 내용에 신경쓰지 않고 꾸미기만 하지 말라는 의미이지 형식이 중요하지 않다는 얘기는 아닙니다.

Jira cloud 는 github 와 비슷한 문법의 markdown 을 지원하고 있으므로 익숙해 지면 빠르게 내용을 작성할수 있고 팀원들에게 더 가독성있게 내용을 전달할 수 있으니 markdown 에 익숙해 지는게 좋습니다.

댓글(comment)

댓글은 팀원과 이해 관계자들이 프로젝트에 대해 논의할 수 있는 좋은 기능입니다. 설명 필드처럼 markdown 문법을 지원하며 멘션도 가능합니다/

Jira 의 멘션은 프로젝트 팀원만이 아니라 Jira 와 연계된 외부 서비스에도 보낼수 있으며 예를 들어 slack 채널을 연결해 놓았다면 바로 채널에 멘션을 보낼수 있습니다.

담당자(assignee)

이제 옵션인 필드들을 살펴보겠습니다.

먼저 담당자(assignee)는 현재 문제를 해결하도록 할당한 사람으로  현재의 담당자가 적절하지 않을 경우 완료 상태가 아닌 경우 언제든지 변경할 수 있습니다.

이슈 등록시 담당자 지정 여부는 프로젝트와 팀의 정책에 따라 달라집니다. 예로 팀이 관리하는 프로젝트는 칸반이나 스크럼 방식을 사용하며 backlog 에 쌓인 일중에 선별해서 진행할 작업을 선택하므로 자동 담당자 지정이 적당하지 않습니다.

회사가 관리하는 프로젝트는 열어서 "프로젝트 설정" → "세부 정보"를 살펴 보면 기본 담당자를 지정할 수 있는데 기본 값은 미할당이며 이럴 경우 이슈를 등록해도 담당자가 자동으로 지정되지 않습니다.

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

이는 작은 규모에서는 상관없지만 큰 규모에서는 리더가 모든 이슈의 상세 내역을 파악하고 담당자를 지정해야 하는 어려움이 있으므로 규모있는 프로젝트는 구성요소로 번역되는 컴포넌트를 등록하고 컴포넌트 리더를 기본 담당자로 지정할 수 있습니다.

컴포넌트(component)

Jira 는 프로젝트에 하위 프로젝트를 둘 수 없으므로 컴포넌트를 논리적인 하위 프로젝트로 생각하면 됩니다.

예로 A라는 서비스를 개발하는 개발자 3명이서 back-end, front-end, android-app 로 역할을 나눴다면 세 가지를 별도의 프로젝트로 등록하고 관리해도 되지만 규모가 작아서 한 프로젝트로 관리하는 게 나을수 있습니다.

이럴 경우 각 파트를 프로젝트내 구성요소로 관리하면 다른 프로젝트로 이동하지 않고도 각 파트의 진행 상황을 공유할 수 있습니다.

여러 개의 프로젝트로 나눌지 컴포넌트로 나눌지는 정답이 없지만 대략 각 파트 규모가 5명 이상은 되야 별도로 나누는게 좋지 않을까 생각합니다.

보고자(reporter)

보고자(Reporter) 는 현재 이슈를 등록한 사람으로 한 명만 가능하며  변경이 가능하지만 보통 변경하지는 않습니다.

labels

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

하나의 이슈는 여러 개의 레이블을 가질수 있으며 레이블 작성시 자동 완성이 되므로 이해하기 쉽게 작성해 주는 것이 좋습니다.

여러 단어로 레이블을 기술할 경우 공백대신 대시 - 문자를 사용해서 작성해 주면 됩니다.

이미 등록된 이슈에 label 을 추가할 때 레이블 필드를 클릭하고 입력하거나 도는 단축키 소문자 l 을 누르면 됩니다.

해당 레이블이 있는 다른 이슈를 검색할 경우 레이블을 마우스로 클릭하면 되며 JQL 과 필터를 사용해서  더 상세한 검색을 할 수 있습니다.

더 자세한 설명은 뒷 부분인 JQL 과 필터 항목에서 다루겠습니다.