왜 Jira를 사용하며 어떻게 사용해야 하는지

Why Jira?

왜 지라인가?

• Issue Tracking(Project Manager)
• Agile
• Devops
• SRE

Issue Tracking(Project Manager)

• 팀 단위의 Todo list를 정의하기 위한 것
  • Todo 하나하나가 Issue로 불림
• 이슈가 상태가 있고 관리할 수 있기 떄문에 Tracking을 할 수 있다
• 그래서 Issue Tracking이라 부름
• 그리고 Issue Tracking Tool로서 가장 많이 쓰는게 Jira임

Project Manager

Jira는 Project Management를 도와준다

Agile

• 개인과 상호작용을
• 작동하는 소프트웨어를
• 고객과의 협력을
• 변화에 대응하기를
• 애자일의 오해
  • 왼쪽에 있는 말을 안하겠다는게 아님
    • 오른쪽을 조금 더 중점에 두는 것이지 왼쪽의 말들 또한 당연히 중요하다.
  • 애자일 방법론 → 명세서나 문서가 아니다.
    • ~~하게 같은 태도의 느낌

• 애자일하게~의 대표적인 예시인 SCRUM과 KANBAN의 비교
  • 우선 보드를 세우고 이슈를 보드에 정리하며 상태를 관리한다는 공통점이 있음
  • 차이점은 스크럼은 스프린트가 있음
    • 우리팀의 이슈를 백로그에 다 쌓아둔다.
    • 2~4주정도 단위로 이번 스프린트에 어떤 이슈를 해결할지 정해서
    • 스프린트 기간동안에는 해당 이슈에만 집중하고
    • 기간이 끝난 뒤 회고를 하고, 다시 스프린트에 돌입함
  • 칸반은 스프린트가 따로 없음
    • 전체 이슈들을 상태별로 다 붙여두기만함
    • 그럼 어케 할당된 일을 정하고 해결하지 ?
    • WIP라는 할당량 비율을 책정하는 그게 있는데 그런걸로 개인에게 일정량 이상의 WIP를 부여하지 않도록 함

• 나 오늘 오는 길에 뭔 일 있었다 이런 스몰토크 좀 나눠주고
• 가안단하게 어제 뭐했고 오늘 뭐할거다를 공유
• 최대한 빨리 공유하고 빨리 흩어지는게 목적임, 잡담 길어지고 회의처럼 상세해지면 안되는거임.

• DevOps가 나온 이유?
• 운영팀은 계속 안된다 뭐하고
• 개발팀은 그거에 왜 안되냐 불만가지고
  • 위 그림처럼 운영팀과 개발팀의 계속된 갈등을 해소하고자함

• 그래서 Dev와 Ops를 끊지말고 하나의 연결고리로 해결하자
  • 이게 DevOps임
• DevOps할땐 CI/CD로 배포 자동화하는게 제일 중요하다 생각하는데?
• 원래 기원에 가까운건 개발팀과 운영팀의 갈등을 해결하고자 하나로 합치자! 에 가까움

• 그럼 그 DevOps를 잘 해결하려면?
• 반복적인 작업들을 Tool을 이용해서 자동화하고
• 팀원 모두가 알고있는 하나의 공유된 지표가 필요하다
• 장애나 이슈가 있을 때 혼자만 알지 말고 팀원들과 공유가 필요하다.
• 이런걸 도와주는 Tool이 Jira !

• Jira를 만든 아틀라시안에서 제시한 Devops용 Jira어플 사용추천

SRE

• 한국말로 하면 신뢰성 공학. 신뢰성에 관한 내용임
• DevOps에서 파생된 의문
  • 운영팀은 그럼 무슨 일을 하냐?
  • 그리고 DevOps를 그럼 어떻게 더 신뢰성 있게 할 수 있을까?
• 그래서 보면 class SRE implemnets DevOps로 되어 있음
  • SRE는 DevOps를 더 잘하기 위한 활동이다 라고 생각할 수 있겠다.

How to Jira

Q. 프로젝트 만들기 왜 없냐?

• 허용해주면 프로젝트 무한생성이 돼서 성능 문제가 있어서.. 나중에 팀 별로 프로젝트 하나씩 생성해준다고 함

어떻게 지라를 사용해야하나?

이슈부터 만들어야한다.

• 프로젝트
  • 말그대로 이슈를 적용할 프로젝트
• 이슈 유형 고르기
  • 스토리 : 유저 시나리오같이 사용자와 상호작용 할 것 작성 시에 사용
  • 작업 : Task, 사용자는 전혀 모르지만(또는 전혀 느끼지 못하지만) 우리가 해야 될 작업들, 비품 구매, 소프트웨어 개발 이런거.
  • 버그 : 말 그대로, 일어난 버그
  • 에픽 : Epic, 대 서사, 스토리의 묶음, 스토리를 묶어서 대 서사 하위의 행동들이 잘 이행되고 있는지를 체크
    • 에픽은 기능 단위로 나누면 될거같다!
  • 에픽 > 스토리 / 작업은 별개로 봐도 되고 에픽 안에 같이 들어가도 무관
• 상태
  • ToDo, In Progress, Done
  • 근데 상태는 직접 생성하고 관리하면됨.
  • 필요한 상태를 추가하고 관리할 수 있다.
• 요약
  • 제목을 적어주는 곳
• 컴포넌트
  • UX에 관련된건지, 인프란지 백인지 프론트인지 이런거처럼 카테고라이징 할 수 있는 칸
  • 기능별로 카테고라이징하거나, 주제별로 카테고라이징하거나 개인선택
• 연결된 이슈
  • 어떤 다른 이슈와 연관관계가 있을 경우 삽입
• 수정 버전
  • 패치 버전, 릴리즈 버전같은 느낌
• 보고자는 팀장, 근데 버그같은건 보고자가 가장 먼저 발견한 사람
• 담당자는 말그대로 이 이슈를 담당할 사람
• 레이블은 인스타그램 해쉬태그 같은거
  • 특별한 형식이 없음, 그래서 정리를 잘해주고 규칙이 있어야함
    • 대소문자나 띄어쓰기 같은것들
• Epic Name 항목은 Epic 상위 항목 설정할때 저 이름으로 상위를 설정

컴포넌트

• 이름은 이름
• 설명은 설명
• 컴포넌트 리드는 말 그대로 리더를 선정
• 기본 담당자를 설정하면 추후 이슈를 만들때 담당자가 자동으로 배정됨
  • 담당자란 단어는 Assign으로 많이 이해를 함
• 컴포넌트는 이슈를 만들기 전에 미리 만들어놓고 컴포넌트를 분류하는 것

JQL

• 이슈들을 검색하기 위한 쿼리문

• Jira Query문
• 실제 SQL과 거의 유사하다고 생각하면 됨.

• JQL의 종류는 Basic Quey와 Advanced Query가 있음
• Basic Query는 직접 짜지 않고 버튼 클릭으로 조작해줌
• Advanced Query는 직접 이어서 query를 작성함

• sql과 똑같음
• ~(글자)
  • LIKE와 같은 기능, ‘글자’가 포함됐냐 안됐냐
• is empty와 is null은 기능상 거의 동일하게 사용해도 됨.

• Jira는 날짜관련 기능을 강력하게 제공함
• 1d, 2d 이렇게 일자별로도 구분하지만
• 주 단위도 제공함
  • -7d 대신 -1w를 제공
  • 마찬가지로 월 단위 년 단위도 제공함

• 일의 끝, 일의 시작
• 주의 끝(토욜), 주의 시작(일요일)
• 월의 끝 월의 시작
• currentUser ⇒ assign이가 currentuser인거
  • 즉 지금 현재 로그인 한 사람이 담당자인거
  • 내가 어디어디 담당인지 알아보기에 편함

예시 - 에픽과 그 하위 스토리 & 작업

JQL을 저장해서 활용하는 ..? ⇒ Filter

Filter == JQL문을 저장하는거임

예를들어

• project = DP and assignee = currentUser()라는 쿼리문이 있음
• 이걸 필터로 저장하면?
• 추후 버튼클릭만으로 계속 저 쿼리문을 실행해서 볼 수 있는거임

• 이렇게 확인가능!

대시보드(DashBoard)

이슈에 대한통계를 차트로 확인가능

• 가젯이란걸 추가해서 차트를 확인함

• 필터를 통해서 프로젝트에 대해서 해당 이슈에 대한 통계를 차트로 볼 수 있다는거!

Board

제일 많이 사용하게될껄

기본적으로 스크럼 보드 or 칸반 보드 중 선택해서 생성

• Scrum 보드는 아마 SSAFY에서 플젝만들어줄때 기본으로 만들어줄거임
• 백로그를 관리
  

• 스프린트에 대해서도 관리
  

• 칸반과 스크럼의 차이는 백로그 관리 과정이 없이 그냥 저렇게 백로그들을 쫘르르르륵 모아놔주는 역할만 함
  

• 이슈관리 툴은 Jira를 제일 많이 사용한다