배포했음. 공지사항도 추가함
김 부장님: 지라처럼 업무 공유가 되어야 한다. 아니면 지라 연동하든가.
지라
Jira의 기본 컨셉은 업무를 이슈(Issue)라는 단위로 쪼개서 추적하고 관리하는 시스템입니다.
처음 Jira를 볼 때는 Project → Issue → Workflow → Board → Sprint 순서로 이해하면 가장 쉽습니다.
1. Project — 업무 공간
Project는 특정 팀이나 제품의 업무를 모아놓는 공간입니다.
프로젝트: PAY
프로젝트 이름: 결제 서비스
├── 결제 API 개발
├── 결제 장애 수정
├── 결제 DB 마이그레이션
└── 결제 성능 개선
회사에 따라 프로젝트를 다음처럼 나눌 수도 있습니다.
PAY → 결제 서비스
AUTH → 인증 서비스
WEB → 웹 서비스
OPS → 인프라/운영
즉, Project = 업무를 묶는 큰 컨테이너라고 보면 됩니다.
2. Issue — 실제 업무 단위
Jira에서 가장 중요한 개념
1 Issue == 할 일 하나
PAY-123
결제 API 응답 속도 개선
PAY-124
결제 실패율 모니터링 추가
PAY-125
결제 서버 메모리 누수 수정
각 Issue에는 보통 다음 정보가 들어갑니다.
Issue
├── 제목
├── 설명
├── 담당자(Assignee)
├── 보고자(Reporter)
├── 상태(Status)
├── 우선순위(Priority)
├── 라벨(Label)
├── 댓글
├── 첨부파일
└── 변경 이력
그리고 Issue에는 Type이 있습니다.
대표적으로:
- Epic — 큰 업무/목표
- Story — 사용자 관점의 기능
- Task — 일반적인 작업
- Bug — 버그 수정
- Sub-task — Issue를 더 작은 작업으로 분리
Epic
└── 결제 시스템 개편
│
├── Story
│ └── 카드 결제 기능 개선
│
├── Task
│ └── DB 스키마 변경
│
├── Bug
│ └── 결제 승인 실패 오류 수정
│
└── Task
└── 모니터링 대시보드 추가
다만 Epic / Story / Task를 반드시 이런 식으로 사용해야 하는 것은 아닙니다. 회사마다 Jira를 사용하는 방식이 상당히 다릅니다.
3. Workflow — 일이 어떻게 흘러가는가
Issue는 계속 상태가 변합니다.
가장 단순하게 보면:
TO DO
↓
IN PROGRESS
↓
DONE
조금 더 복잡하게 만들면:
BACKLOG
↓
SELECTED
↓
IN PROGRESS
↓
CODE REVIEW
↓
QA
↓
DONE
이게 Workflow입니다.
즉,
"이 업무가 지금 어떤 단계에 있으며, 다음에는 어디로 이동할 수 있는가?"
를 정의합니다.
예를 들어 개발팀에서는:
개발자가 작업 시작
↓
In Progress
↓
PR 생성
↓
Code Review
↓
QA
↓
Done
처럼 구성할 수 있습니다.
4. Board — Issue를 시각적으로 보는 화면
Board는 Issue들을 Workflow에 따라 보여주는 화면입니다.
예를 들어 Kanban Board라면:
┌───────────┬─────────────┬────────────┐
│ TO DO │ IN PROGRESS │ DONE │
├───────────┼─────────────┼────────────┤
│ PAY-101 │ PAY-103 │ PAY-099 │
│ PAY-102 │ PAY-104 │ PAY-100 │
│ PAY-105 │ │ PAY-098 │
└───────────┴─────────────┴────────────┘
Issue를 이동시키면 실제 Issue의 Status도 변경됩니다.
그래서 Board는 본질적으로
Workflow에 있는 Issue들을 시각적으로 표현하는 방법
이라고 이해하면 좋습니다.
5. Backlog — 아직 작업하지 않은 일들
Backlog는 앞으로 해야 할 Issue들을 모아놓은 곳입니다.
Backlog
PAY-101 결제 API 개선
PAY-102 결제 로그 구조 변경
PAY-103 장애 알림 추가
PAY-104 DB 인덱스 개선
PAY-105 결제 통계 API 개발
여기에서 우선순위를 정하고, 어떤 일을 먼저 할지 결정합니다.
6. Sprint — 일정 기간 동안 처리할 작업 묶음
Scrum을 사용하는 경우 Backlog에서 일부 Issue를 가져와 Sprint를 만듭니다.
예:
Sprint 42
기간: 2주
├── PAY-101 결제 API 개선
├── PAY-102 결제 로그 구조 변경
├── PAY-103 장애 알림 추가
└── PAY-104 DB 인덱스 개선
즉,
Sprint = 일정 기간 동안 완료하기로 약속한 업무의 묶음
입니다.
보통 1~2주 단위로 운영합니다.
7. Epic — 큰 목표를 묶는 단위
큰 프로젝트를 하나의 Issue로 관리하기에는 너무 큽니다.
예를 들어:
Epic: 결제 시스템 개편
아래에 여러 작업을 넣을 수 있습니다.
결제 시스템 개편
│
├── 결제 API v2
├── 결제 DB 개편
├── 결제 모니터링
├── 결제 장애 대응 개선
└── 결제 성능 개선
그래서 일반적으로:
Epic
↓
Story / Task / Bug
↓
Sub-task
형태로 업무를 쪼갤 수 있습니다.
8. Jira의 전체 그림
이것들을 합치면 대략 이렇게 됩니다.
Jira Project
│
▼
┌─────────┐
│ Backlog │
└────┬────┘
│
작업할 Issue 선택
│
▼
┌─────────┐
│ Sprint │
└────┬────┘
│
▼
┌────────────────────┐
│ Board │
│ │
│ To Do │
│ ↓ │
│ In Progress │
│ ↓ │
│ Code Review │
│ ↓ │
│ Done │
└────────────────────┘
그리고 각각의 작업은 Issue입니다.
Project
│
├── Epic
│ ├── Story
│ ├── Task
│ └── Bug
│ └── Sub-task
│
└── Issue들은
↓
Backlog
↓
Sprint
↓
Board
↓
Workflow
↓
Done
핵심만 기억하면
Jira를 처음 접한다면 일단 이 6개만 기억하시면 됩니다.
| 개념 | 쉽게 말하면 |
|---|---|
| Project | 업무를 담는 공간 |
| Issue | 실제 해야 할 일 |
| Epic | 큰 목표/큰 업무 |
| Backlog | 앞으로 해야 할 일 목록 |
| Sprint | 이번 기간에 할 일 |
| Workflow | 일이 진행되는 과정 |
| Board | 그 과정을 눈으로 보는 화면 |
그리고 가장 중요한 것은 Jira 자체가 Scrum과 동일한 것은 아니라는 점입니다.
Jira는 업무 추적 도구이고, Scrum/Kanban은 업무를 운영하는 방법론입니다. Jira는 Scrum 방식으로도, Kanban 방식으로도, 그냥 단순한 업무 티켓 시스템으로도 사용할 수 있습니다.
댓글 0
불러오는 중…