brunch

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 기획하는 족제비 Apr 02. 2024

3. 기획자를 위한 툴 기초-2

지라의 티켓 구조

지식 공유를 위해 경험과 자료를 정리하며 작성한 글이다.
이번 글에선 아래 내용을 확인할 수 있다.

1. 지라에서 ‘이슈’란?
2. 이슈의 유형
3. 이슈의 계층 구조

지라와 이슈

많은 소프트웨어 개발 회사에서 지라Jira를 사용한다. *이슈 추적, 프로젝트 관리부터 릴리즈, 배포 등 개발 운영Dev Ops 까지. 개발 처리까지 이어지는 모든 프로세스를 지라에서 관리할 수 있다. (휴가 요청, 업무 분배 등 전반적인 팀 운영을 지라로 하는 곳도 있다.)

*여기서 이슈Issue란 팀에서 수행해야 하는 개별 작업의 단위를 의미한다.

실무 사례

1. 작업 관리: 다음에 어떤 기능을 개발할지 정했다. 기획 작업을 관리하기 위해 지라에 이슈를 생성하고, 작업 일정을 설정한다.

2. 버그 처리: 서비스에서 버그를 발견했다. ‘버그’ 유형으로 이슈를 생성한 후, 개발자에게 이슈의 번호와 링크를 전달한다. 이후 버그의 처리 과정을 해당 이슈에서 관리한다.

3. 백로그 관리: 버그, 스토리, 작업 등 해야 할 일을 이슈로 미리 생성한다. 다음 스프린트를 시작하기 전, 지라의 *제품 백로그 페이지에서 작업 목록을 확인한다. *백로그 그루밍 후 스프린트 항목을 지정한다.

알쓸지식

- 이슈를 생성하는 것을 ‘티켓을 발행한다.’라고도 부른다.

- 정형화할 수 있는 업무는 지라의 자동화 기능을 활용해서 생산성을 높이자. 예를 들어 CX 팀에서 이슈를 생성하고 담당자를 지정한 경우, 담당자에게 사내 메신저 알림을 자동으로 발송한다. 이를 통해 소통 비용을 줄일 수 있다. (지라 자동화 템플릿)

이슈의 유형

작가 편집 ⓒ Atlassian

지라는 기본적으로 5가지 이슈 유형을 제공한다. 이는 애자일 원칙에 기반을 두고 있기 때문이다. 각 유형의 정의는 아래와 같다.

1. 에픽(Epic)

- 큰 규모의 작업을 의미한다. 대게 여러 이슈의 모음이다.

- 프로젝트의 목적을 작성할 수도 있고, 목표를 작성할 수도 있다. 조직에서 정의하기 나름이다.

- 나는 보통 ‘프로젝트의 목표’를 작성한다.

2. 작업(Task)

- 해야 할 작업을 의미한다. 포괄적으로 사용할 수 있는 유형이며, 다른 유형에서 해야 하는 작업을 정확하게 나타낼 수 없을 때 사용한다.

- 나는 보통 비즈니스 가치가 적고, 기술적 기능 개발을 관리해야 할 때 작업 유형으로 이슈를 생성한다.

3. 스토리(Story)

- 사용자 관점에서 표현한 요구 사항을 의미한다. 스토리는 ‘기능’이 아니다. 서비스 사용자의 관점에서 표현한 ‘최종 목적’을 의미한다.

- 나는 보통 기능의 인수 조건을 고려하여 스토리를 작성한다.

4. 버그(Bug)

- 해결해야 할 문제를 의미한다.

- 크게 1) 운영 중에 수시로 발견한 버그와 2) 검증을 하며 발견한 버그가 있다.

- 운영 중에 수시로 발견한 버그를 작성할 때 1) 기획 누락으로 인한 미개발인지, 2) 예상하지 못한 로직에 의한 오류인지 구분하여 이슈 유형을 선택하면 개발자가 부담을 덜 느낀다. 개인적인 팁이다.

5. 하위 작업(Sub Task)

- 이슈를 완료하는 데 필요한 작업을 더 세부적으로 분해한 것을 의미한다.

- 모든 이슈 유형 하위에 만들 수 있으며, 실무자의 실제 작업이 이루어지는 단위다.

- 조직별로 일련의 규칙을 정하는 게 좋다. 나의 경우, 기능 개발을 위한 에픽 이슈를 생성하면, 하위에 ‘[기획] OOO 기획서’라는 하위 작업 이슈를 생성한다. 대괄호 등 특정한 구분값을 넣어둠으로써 지라의 대시보드, 리포트, 컨플루언스 등에서 자동으로 추적할 수도 있다.

실무 사례:
서비스에 쿠폰 기능 도입하기

이번 스프린트 동안 서비스에서 판매하는 콘텐츠를 할인 가격을 적용할 수 있는 ‘쿠폰’ 기능을 개발한다고 가정해 보겠다. 크게 두 가지가 필요할 것이다. 1) 회원이 서비스에서 쿠폰을 사용할 수 있는 기능과 2) 관리자가 관리자 사이트에서 쿠폰을 관리할 수 있는 기능이 대표적이다. 이 경우 이슈를 아래와 같이 생성할 수 있다. (기획은 이미 완료한 상태라고 가정하자.)

실무 사례 예시 ⓒ 327roy

0. 에픽: 콘텐츠 할인 쿠폰 기능 출시

1. 스토리: 회원은 콘텐츠 구매 시 할인을 받기 위해 쿠폰 코드를 사용하고 싶다.

1.1. 하위 작업: [백] 쿠폰 코드 유효성 검사 로직 구현

1.2. 하위 작업: [백] 쿠폰 할인 로직 구현

1.3. 하위 작업: [프론트] 쿠폰 코드 입력 인터페이스 개발

2. 스토리: 관리자는 특정 콘텐츠나 전체 서비스에 대한 할인 쿠폰을 생성하고 싶다.

2.1. 하위 작업: [백] 데이터베이스 스키마 설계 및 구현

2.2. 하위 작업: [백] 배치 작업을 통한 쿠폰 코드 만료 처리

2.3. 하위 작업: [프론트] 쿠폰 관리자 페이지 개발

3. 작업: AWS에 새로운 서버 환경 설정

3.1. 하위 작업: EC2 인스턴스 생성

4. 작업: 콘텐츠 할인 쿠폰 기능 기획

4.1. 하위 작업: [기획] 사용자 사이트 쿠폰 기능 기획

4.2. 하위 작업: [기획] 관리자 사이트 쿠폰 관리 메뉴 기획

5. 작업: 콘텐츠 할인 쿠폰 기능 디자인

5.1. 하위 작업: [디자인] 사용자 사이트 쿠폰 기능 디자인

5.2. 하위 작업: [디자인] 관리자 사이트 쿠폰 관리 메뉴 디자인

지라에서 이슈 생성 시 작업의 위계를 제목 기준으로 정렬한 것이다. 이슈에는 ‘스프린트 차수, 릴리즈 버전, 담당자, 작업 시작일자, 종료일자’를 설정한다. (조직의 개발 스타일과 기획단에서 정의한 정책에 따라 해야 하는 작업은 항상 달라질 수 있다.)

알쓸지식

- 관련된 이슈가 있다면 ‘이슈 연결’ 기능을 사용하자. 프로젝트와 히스토리 파악에 용이하다.

- 이슈 유형은 관리자가 직접 추가할 수 있으며, 유형별로 워크플로우를 다르게 설정할 수 있다.

- 버그처럼 처리를 위한 프로세스를 정형화하기 쉬운 경우엔 관리자에게 ‘이슈 템플릿’을 만들어달라고 하자.

- 애자일 형태의 프로젝트 관리 방법에선 보편적으로 이니셔티브Initiatives를 함께 제안한다. 이니셔티브는 공통의 목표를 추구하는 에픽의 모음을 의미한다.

이슈의 계층 구조

이슈도 조직, 기업 목표처럼 위계가 존재한다. 지라에서 제안하는 이슈의 위계는 이와 같다.

작가 편집 ⓒ Atlassian

1. 최상위 레벨

- 가장 큰 사이즈의 목표를 관리한다.

- 이니셔티브를 작성한다. 이니셔티브는 에픽의 모음을 의미한다.

- 이니셔티브에 조직 혹은 프로젝트의 정성적인 목표를, 에픽에 보다 정량적인 목표를 작성한다.

2. 상위 레벨

- 보다 작은 사이즈의 목표를 관리한다.

- 이니셔티브 하위에 에픽을 연결한다.

- 에픽의 상위 작업으로 연결할 수 있는 이슈 유형은 이니셔티브와 에픽 밖에 없다.

3. 중위 레벨

- 중간 사이즈의 작업을 관리한다.

- 에픽 하위에 스토리, 작업을 연결한다.

4. 하위 레벨

- 실무와 직결된 업무 단위의 작업을 관리한다.

- 스토리, 작업 하위에 하위 작업을 연결한다.

알쓸지식

- 에픽에 연결하지 않고 스토리만 진행할 수도 있다. 작업도 마찬가지다. 무조건 에픽으로 이슈를 묶어줄 필요가 없다. 조직에서 세운 기준과 상황에 맞춰 프레임워크에 발목이 잡히지 않도록 주의하자.

- 여러 개의 버그 이슈를 하나의 에픽으로 묶는 경우도 있다. 보통 기술 부채로 인해 발생한 버그가 많이 모였을 때, 혹은 비슷한 기술 부채로 인해 버그가 여러 개 생성된 경우 이를 한 번에 관리하기 위함이다. 건강한 제품을 만들기 위해 기술 부채 해결을 위한 스프린트도 고려하자.