[JIRA] 지라에 대해 (About Jira)

개요

이번 프로젝트에서 다시 한번 지라를 다루게 되었다.

기존 ssafy의 gitlab과는 달리, jira 공식 사이트에서 계정을 생성하여 운영해 볼 생각이다. (물론 크게 다르지는 않다. 호스팅의 차이만 있을 뿐)

이 과정에서 먼저 지라에 대해 정리해보고자 한다.

 

내가 사용했던 방법 ( The way I used it)

지라를 사용하는데 공식 방법이나 획일화된 방법이 있는 것은 아니라고 생각한다.

나는 지금까지 이렇게 사용하였다. 지금까지의 지라 사용법은 다음과 같았다.

 

1. 스프린트 계획 

스크럼 방법론을 따라, 주차별 스프린트 계획을 세웠다.

이는 월요일 아침 즈음에 시작해서, 오전 시간을 활용해 회의하고 이번 주차에 해야 할 목표와 세부 사항을 설정하였다.

 

1. a sprint plan
Following the scrum methodology, a sprint plan for each parking was made.
It started around Monday morning, and used the morning time to hold a meeting and set goals and details to be done this week.

 

2. 에픽과 스토리

핵심 개발 도메인의 경우는 에픽을 지정했다. 네이밍 규칙은 '핵심 도메인/도메인의 기능' 으로 구분했다.

(ex : 사용자/로그인 및 로그아웃(인가 처리), 사용자/회원가입 및 개인정보 수정) 이런 식이었다.

그리고 그 아래의 세부 기능으로 스토리(이슈)를 사용했다.

 

'사용자/로그인 및 로그아웃' 의 경우 하위 스토리로 '로그인 기능 구현', '로그아웃 구현', '토큰 발급' .. 등의 하위 스토리가 존재하는 식이다.

 

2. Epic and Story
For the core development domain, Epic was designated. The naming rule was divided into 'core domain/domain function'.
(ex: user/login and logout (authorization processing), user/member registration and privacy modification) were like this.
And used the story (issue) as a detail below it.

 

In the case of 'user/login and logout', sub-stories such as 'implementation of login function', 'implementation of logout', and 'issuance of tokens' exist as sub-stories.

 

3. 백로그 관리

주차 별 스프린트를 시작하기 전, 백로그를 통해 작업을 미리 정의했었다. (월요일 오전 목표를 세우며 자연스레 백로그에 추가해놨었다.) 

 

3. backlog management
Before starting the sprint by parking, I had predefined my work through the backlog. (I had set a goal earlier Monday and naturally added it to the backlog.)

 

 

4. 진행 사항 모니터링(및 회고)

시간이 되는 날에 따라 수요일에 중간 점검을 하고, 금요일에 스프린트 회고와 달성 및 작업량의 부족한 점을 찾아 다음 주차에 반영하였다.

 

4. Monitoring Progress (and Retrospective)
Interim inspections were conducted on Wednesday depending on the available days, and sprint retrospections and shortfalls in achievement and workload were found on Friday and reflected in the next parking.

 

지라의 구성 요소 (components of the jira)

 

 

 

1. 에픽 (Epic)

에픽 구조를 한 눈에 설명하기 좋은 다이어그램

 

- 프로젝트의 큰 목표나 주요 기능을 나타내는 상위 개념.

- 에픽은 일반적으로 여러 스토리나 작업으로 나뉘며, 이는 에픽의 세부 목표나 작업을 구체화한다.

- 큰 목표나 전략적 방향을 제시하며, 이를 통해 프로젝트의 진행 상황을 큰 그림에서 볼 수 있다.

 

ex : 프론트 화면의 리팩토링을 수행할 때는 "메인 페이지 개편", "사용자 인터페이스(UI) 개선" 등의 커다란 대주제가 필요할 것이다. 이러한 부분을 에픽으로 설정한다.

 

- A higher concept that represents a big goal or key function of a project.
- Epic is usually divided into several stories or tasks, which specify detailed objectives or tasks for Epic.
- It presents a big goal or strategic direction, which allows you to see the progress of the project in a big picture.

ex: When performing refactoring of the front screen, you will need big major topics such as "main page reorganization" and "user interface (UI) improvement". Set this to Epic.

 

2. 스토리 (Story)

사용자나 시스템의 요구사항을 나타내는 작은 규모의 개별 작업을 표현한다.

주로 사용자 스토리 형식으로 작성되며, 기능의 완료를 위한 조건과 요구사항을 설명한다.

 

ex : "사용자가 로그인하여 계정에 액세스할 수 있어야 합니다."

 

Represent a small-scale individual task that represents the requirements of a user or system.
It is written primarily in the form of a user story and describes the conditions and requirements for the completion of the function.

ex: "The user must be able to log in and access the account."

 

3. 이슈 (Issue)

작업 또는 과제를 나타내는 개념으로, 버그 보고서, 작업 요청, 개발 작업 등을 포함하는 가장 작은 단위이다.

 

A concept representing a task or task, it is the smallest unit that includes bug reports, task requests, development tasks, and the like.

 

4. 컴포넌트 (Component)

프로젝트의 특정 영역이나 모듈을 나타내는 데 사용되며, 이슈나 스토리를 논리적으로 그룹화하고 관리하기 위한 용도로 사용됨.

 

ex :  "데이터베이스", "프론트엔드", "서버" 등은 프로젝트 내의 다양한 컴포넌트일 수 있다.

 

Used to represent a specific area or module of a project and for logically grouping and managing issues or stories.

ex : "Database", "Front End", "Server", etc. may be various components within the project.

 

에픽과 컴포넌트 차이? ( Epic and component difference?)

- 에픽은 큰 작업 덩어리나 목표를 나타낸다. (작업 영역)

- 컴포넌트는 프로젝트 내의 특정 기능, 팀, 또는 작업 영역을 나타낸다. (구조적 분류)

 

ex :

"웹사이트 리디자인"이라는 에픽은 "메인 페이지 개편", "사용자 인터페이스 개선" 같은 여러 작업으로 구성

,  "데이터베이스", "프론트엔드", "서버" 등은 프로젝트 내의 다양한 컴포넌트로 구성.

 

- Epic represents a big chunk of work or goal
- Components represent specific functions, teams, or work areas within a project (structural classification)

ex :
The Epic of "Designing a Website" consists of several tasks, such as "Reorganizing the Main Page" and "Improving the User Interface."
, "Database", "Front End", "Server", etc. consist of various components within the project.

 

스토리와 이슈의 차이? ( The difference between story and issue?)

 

 

간단히 말하자면, 모든 스토리는 이슈이지만 모든 이슈가 스토리는 아니다.

 

스토리 : 이슈 중 사용자 요구사항을 특정 기능으로 표현한 것

이슈 : 프로젝트 내에서 발생하는 모든 항목

 

으로 정리하면 편할 것이다. 우리는 스토리를 위주로 사용하였고, 버그나 작업 요청 등의 작업을 이슈로 활용하여 추가하였다.

 

Simply put, every story is an issue, but not every issue.
Story: Expressing user requirements in a specific function among issues

Issue: Any items that occur within the project
It will be convenient to organize it in . We mainly used stories, and added tasks such as bugs and task requests as issues.

 

 

 

참조

 

https://community.atlassian.com/t5/Confluence-questions/What-is-the-difference-between-Confluence-Feature-and-JIRA-Epic/qaq-p/1060667

What is the difference between Confluence Feature and JIRA Epic

 

https://planyway.com/blog/jira-epic-vs-story

Jira Epic vs Story: Comparison Guide From A to Z

 

 

https://actonic.de/en/epic-vs-story-vs-task-in-jira/

Epic vs. Story vs. Task in Jira