Project Management

# 전체내용 둘러보기(Overview) – Link

먼저 지라(Jira)를 소개하기 위해서는 소프트웨어 개발 방법론에 대한 개략적인 이해가 필요하다. Jira에 계정을 바로 만들고 프로젝트를 만들어 이슈를 등록하여 업무를 처리하면 된다. 그러나 Jira안에 어떠한 소프트웨어 개발 방법론이 녹여져 있고 왜 필요한 것인지에 대한 이해가 없다면 지라(Jira)를 좀더 효율적으로 사용할 수 없을 것이다.

[ALM이란?]

ALM(Applicaion Lifecycle Management) : 어플리케이션 생명주기 관리라는 말로서 소프트웨어의 거버넌스, 개발, 유지보수를 포함하는 생명주기 관리를 말하며, 요구사항관리, 소프트웨어 아키텍쳐, 프로그래밍, 소프트웨어 테스팅, 소프트웨어 유지보수, 변경관리, 지속적인통합, 프로젝트 관리, 릴리즈 관리를 포함하는 말이다.

[Agile ALM 이란?]

Agile ALM : Agile ALM은 ALM을 진행할 경우 어려울 수 있는 문제점을 해결할 수 있는 솔루션으로 조직에서 실제적으로 필요한 ALM영역을 도출하고 각 영역에 다양한 Agile Practice를 도입하여 점진적 도입 및 협업과 커뮤니케이션을 통해 조직의 참여와 내재화를 이끌어 낼 수 있도록 해준다.

[Agile 방법론이란?]

Agile(애자일) 방법론 혹은 Agile(애자일)개발 프로세스라 불리우는 방법론을 이해하기 위해서는 전통적인 소프트웨어 개발 프로세스의 종류와 어떠한 단점이 있는지 이해해야 한다. 전통적인 소프트웨어 개발 프로세스 모델에는 아래와 같은 것들이 있다.

폭포수(waterfall)
프로토타입(prototype)
나선형(Spiral)
반복&점증(Iteration&Incremental Development)

위와 같은 개발 프로세스 모델은 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행한다. 이러한 방법은 이해하기도 쉽지만 때로는 계획대로 진행되지 않는 부작용이 발생한다. 예를 들어 소프트웨어 납기 전 야근, 지연, 고객 요구 미충족과 같은 부작용이 자주 발생한다. 이러한 부작용은 개발 프로세스 접근법의 차이에서 나타난다. 전통적인 개발 프로세스들은 공업이나 제조업과 같은 곳에서 사용되는 정형적 프로세스 모델에 기반하고 있다. SW등을 포함하는 전반적인 IT개발에서는 불확실성을 포용하는 방법으로 소프트웨어 개발을 지향하는데 이를 경험적 프로세스 모델이라고 한다. 애자일 개발 프로세스는 이와같은 경험적 프로세스 제어모델에 기반하여 개발프로세스를 관리하는 것이다.

애자일 개발 프로세스 모델로 불리우는 개발 방법론에는 다시 여러가지가 존재한다.

익스트림 프로그래밍(Extreme Programming, XP)
스크럼(Scrum)
기능주도개발(Feature-Driven Development)
적응형 소프트웨어 개발(Adaptive Software Development)
익스트림 모델링(Extreme Modeling)

애자일 개발 프로세스들은 서로 다른 특징과 범위가 있으며, 서로 조합도 가능하다. 이를 통하여 각기 다른 소프트웨어 개발 프로젝트에 적용하여 개발 속도와 품질을 향상 시킬 수 있다.

[스크럼(Scrum)이란 무엇인가?]

바로 위의 애자일(Agile)개발 프로세스의 한 방법론인 Scrum을 다시 언급하고자 한다. Agile의 대표적인 Best Practice인 스크럼(Scrum)은 소프트웨어 개발 프로젝트 관리를 위한 방법론을 말한다. 원래 스크럼은 럭비에서의 스크럼을 의미한다. 아래 그림은 럭비의 스크럼에 대한 사진인데 럭비의 스크럼은 선수들이 함께 협력하여 허들(Huddle)을 형성하고 공을 한 번에 몇 걸음씩 상대팀 진영 끝으로 옮기는 럭비 기술중에 하나이다.

럭비의 스크럼

그렇다면 애자일(Agile) 개발 프로세스에서의 스크럼은 무엇을 의미할까? 아래 그림은 애자일에서 스크럼의 기본 도식도이다. 무언가 비슷한 점이 있는가? 애자일 프로세스의 스크럼도 소프트웨어를 개발하는 팀원이 다같이 협력하여 기획-> 개발 -> 가공 -> 출시 -> 회고 같은 일련의 소프트웨어 개발 프로세스를 효율적이고 빠르게 진행하고 다시 또다른 스크럼을 진행하여 빠르게 변화하는 요구사항과 우선순위에 대응할 수 있도록하는 소프트웨어 개발 방법론을 의미한다.

애자일 프로세스의 스크럼

Scrum에 포함된 주요 컨셉에는 아래와 같은 것들이 존재한다.

제품 백로그(Product Backlog)
제품 백로그는 일종의 제품 요구사항 혹은 사용자 스토리(User Story)의 집합이라고 볼 수 있다. 개발을 통해 어떠한 기능 혹은 디자인을 추가할 것인지 결정된 기능들을 백로그라 한다. 그러나 프로젝트를 진행하다보면 요구사항 외에도 여러가지 업무, 출시된 제품에는 버그 등이 등록될 수 있는데, 이러한 모든 이슈들도 제품 백로그에 해당한다.
스프린트
스프린트는 일종의 릴리즈라고 볼 수 있다. 하나의 릴리즈는 1개의 스프린트 혹은 1개 이상의 스프린트로 이루어 질 수 있다. 프로젝트의 크기 및 목표에 따라 보통 2주~5주 단위로 나눌 수 있다. 스크럼에서는 각 스프린트 마다 실행가능한 제품을 배포하는 것을 목표로 하고 있기 때문이다. 그리고 스프린트는 기본적으로 To-do, In progress, Done의 개별적인 Swim Lane을 가져서 Issue를 처리해 나간다. 스프린트의 To-do에 넣은 제품 백로그는 모두 Done으로 옮겨 하나의 스프린트를 완성시킨다.
스프린트 계획
스프린트 계획은 이번 스프린터에서 출시가능한 제품을 만들기 위해 제품 백로그를 선택하는 과정이다. 팀의 크기와 속도에 따라 스프린터에 구현할 백로그를 적절하게 선택해준다. 이러한 스프린트 회의 매 스프린터 마다 진행되며 거듭될 수 록 정확한 팀의 속도를 알 수 있게 된다.
스프린트 백로그
제품 백로그에서 우선순위가 높은 기능을 선정, 기능을 구현하는데 필요한 작업으로 나누어 봄(이를 스프린트 백로그라함), 스프린트 백로그 상위 스프린트 계획에서 선택된 스프린트를 위한 제품 백로그이다.
데일리 미팅(=일일 스크럼 회의)
스프린트가 시작되면 매일 팀원들과 데일리 미팅을 가지며, 스프린트 진행의 문제가 없는지를 파악
스크럼에서는 매일 아침 일일 미팅을 진행하면서 팀에 문제가 없는데, 이슈가 무엇인지, 오늘 할일은 무엇인지 등을 얘기하게되는데 이를 일일 스크럼 회의하고 한다.
실행가능한 제품 배포(Shippable Product)
매 스프린트는 실행가능한 제품을 만들어 배포하는 것을 목표로 한다. 고객은 2주 ~ 5주 단위로 변해가는 소프트웨어를 평가하고 피드백을 빠르게 줄 수 있으며, 수정사항이나 변경사항은 다음 스프린트에 반영될 수 있다.
스프린트 리뷰
실제로 실행시킬수 있는 기능을 만들어 본 이후 어떤 기능이 추가되었고 어떤 기능이 누락되었는지를 리뷰, 직원 모두가 플레이하면서 피드백 전달
회고(Retrospective)
스프린트 완료후 이번 스프린트의 잘한 점과 잘못한 점을 회고함 향후 방향을 개선하기 위해 모색한다.
번다운 차트(Burn-down chart)
스프린트가 어떻게 흘러가는지 한눈에 볼수 있으며, 그래프가 급락하면 팀이 일을 잘 처리하는것이므로 과소평가, 그래프가 계속 떨어지지 않으면 병목이 걸리므로 일을 줄여야 함
애자일 스크럼에서의 핵심 보고서 중의 하나는 Burndown 차트이다. Burndown 차트는 프로젝트가 진행될 수 록 백로그 수가 줄어들어 최종적으로 0이 되는 차트로 이슈 수 혹은 스토리포인트로 생성할 수 있다

위의 개념들중 지라에서 많이 사용되는 스프린트는 주로 하나의 Release에 하나의 Sprint로 이해하며 업무를 진행할 수도 있으며, 기능이 큰 Release같은 경우는 여러개의 Sprint로 나누어 처리할 수도 있다. 예를 들어 새로운 Release기능이 4개월 정도의 가량 예측되는 기능이라면 이를 스프린트의 업무 단위인 2주~5주 단위로 자르게 되는데 만약 4주단위의 스프린트로 나누어 처리하게 된다면 하나의 Release를 위하여 4개의 스프린트가 필요하게 되는 것이다.

스크럼회의(Scrum Meeting)

스크럼 기반으로 소프트웨어를 개발하게 되면 스크럼회의라는 것을 매일 하는것이 좋다. 이는 아래와 같은 단계로 진행된다.(길게 할필요 없다.짧고 간결하게)

Step1 : 매일 아침업무 시작전 매일 10분~15분 가량 진행한다.(시간적여유가 된다면 Confluence에 해당일에 대한 간단한 회의록이 남길수 있다면 더 좋다.)
Step2 : 각자의 현재 스프린트에서 작업 진행 상황을 간단하게 팀원과 공유, 이때 스크럼 회의에서 Under Review 상태의 이슈를 Resolved할것인지 Closed 할것인지 결정
Step3 : 이후에는 아래와 같은 내용을 간략하게 공유
어제 처리한 Task,
오늘 진행할 Task,
이후의 Task,
Task 처리중 발생한 이슈, 원인, 해결방안
어제 Task처리중 갑자기 발생하여 처리한 긴급대응(Hotfix)이슈에 대한 내용 공유
Step4 : 공유가 모두 되었을 경우 회의 마치고 회의록 정리하고 일한다. 끝.

[지라(Jira)는 무엇인가?]

지라는 Atlassian에서 개발된 이슈 트랙커(Issue Tracker)용 소프트웨어를 말한다. 이중에서도 Agile방법론의 대표적인 Best Practice인 스크럼(Scrum)프로젝트를 관리할 수 있는 Tool이다. 이를 통하여 소프트웨어 개발을 여러명의 구성원과 함께 진행하면서 발생하는 이슈들을 효과적으로 관리하는 용도로 사용되는 하나의 Tool이다. 이중에서도 Atlassian에서 개발된 JIRA는 일반 프로젝트 관리부터 소프트웨어 개발까지 다양한 유형의 프로젝트를 관리할 수 있다. JIRA에는 Core와 Software 두가지 버전이 있으며 Software에는 Agile 소프트웨어 방법론을 지원하는 기능이 포함되어 있다.

[지라(Jira)의 기능]

JIRA를 통하여 프로젝트를 진행할 경우 백로그를 작성하고 스프린트 계획, 버전 관리, 릴리즈 관리를 수행할 수 있다.

애자일 계획과 추적 : 스토리, 업무를 생성하고 스프린트를 계획하고 팀을 할당, 할당된 업무를 다시 우선순위를 정하여 배분할 수 있다.
릴리즈와 실시간 보고 : 릴리즈에 필요한 정보를 파악하고 이를 통항 실시간으로 정보를 확인하고 성능을 향상
워크플로우(Workflow)관리 : 조직의 팀마다 서로 다른 프로세스를 가질 수 있으므로 팀마다 워크플로우를 커스텀하여 관리할 수 있는 기능을 제공

[지라(Jira) 시작전 프로젝트 참조]

지라 소프트웨어 시작하기 : https://confluence.atlassian.com/get-started-with-jira-software/setting-up-jira-software-937185123.html
소프트웨어 시작하기 : https://confluence.atlassian.com/get-started-with-jira-software/start-a-software-project-937185129.html
소프트웨어 팀 설정 : https://confluence.atlassian.com/get-started-with-jira-software/set-up-your-software-team-937185135.html
소프트웨어 프로젝트 설정 : https://confluence.atlassian.com/get-started-with-jira-software/configure-your-software-project-937185140.html
지라 소프트웨어의 3가지 보드 종류 : https://confluence.atlassian.com/get-started-with-jira-software/three-common-jira-software-boards-937185142.html

[지라(Jira)에 사용되는 주요 개념]

# 프로젝트(Project)

Project는 상품별로 혹은 릴리즈가 이루어지는 채널별로 만드는 것이 좋다. 예를 들어 업무가 Web 개발, iOS개발, Android 개발로 나뉘어져 동시에 작업이 되고 있는 환경이라면 Web 프로젝트, iOS 프로젝트, Android 프로젝트 들도 나누어 개별적인 Release를 분류하고 각각의 Release에 맞게 스프린트를 계획하면 되는것이다.

# 이슈(Issue)

오류, 버그 및 새로운 기능, 태스크 요청등 제품개발에 관련하여 회사서 대화의 대상이 되는 모든것

# 이슈타입(Issue Type – Epic, Story, Task, Sub-Task)

프로젝트 내에서 하나의 릴리즈버전을 출시하는 과정에서 여러가지 이슈를 등록하여 업무를 처리한다. 이러한 이슈를 등록시 Issue Type을 지정하는데 크게는 아래와 같이 구조를 잡아서 업무를 처리할 수 있다. 하나의 프로젝트안에서 여러개의 Epic을 등록할 수 있지만 이를 소프트웨어가 업데이트되어야 하는 하나의 Release개념으로 여러개의 Epic을 묶어서 업무를 진행할 수도 있다.

프로젝트를 구성하는 Level 방식1

프로젝트를 구성하는 Level 방식2

Jira내에서 이슈등록시 이슈 구조는 아래와 같은 레벨로 나누어 등록

Level1 : Epic
Level2 : Story, Chore Bug, Hotfix(3개 모두 동일한 레벨)
Level3 : Task
Level4 : Sub-task

위와 같은 Issue Type에는 기본적으로 생성되는 Bug, Epic, Story, Task, Sub-Task가 있으며, 업무특성에 따라 Issue Type을 추가하여 처리할 수 있다. 이때 주의할 점은 Epic, Story는 PM(ProjectManager), EM(Engineering Manager)만이 생성하고 Task, Sub-Task는 일감을 할당받는 사람이나 담당자 스스로 만들수 있다.

Epic(에픽)
Epic의 개발단위는 기본적으로 2주를 기점으로 잘라서 등록
Story(스토리)
Story는 부서와 상관없이 모두가 이해할 수 있는 말로 서술하여 등록한다. 대개 “as a {user}, I want to {do something}(사용자로서 어떠어떠한 것을 하기를 원한다 or ~를 할 수 있다.)” 라는 구조로 사용자가 직접적으로 사용하는 기능에 대해서 서술한다. Story는 구조상 항상 Epic하위에 속해야 하지만 개발자가 특정 Release가 아니더라도 스스로 개선해야 하는 부분이라고 생각된다면 Epic에 속하지 않는 Story와 Task를 생성할 수 있으며, Story가 등록되면 ProjectManager나 Engineering Manager가 이를 확인후 연관성이 있는 Epic으로 묶어 낼수 있으며, 연관성이 없으면 등록된 Story 그대로 놔두어도 된다.
또한 Story는 Story Point라는 것을 입력할 수 있는데 이는 개발에 걸리는 시간 또는 난이도 등으로 지정한다. StoryPoint는 1~10까지있고, 2주동안 진행한 point를 합산하여 100포인트가 적절하다.
Chore(쵸어)
Chore는 사용자에게 직접적으로 보이거나 사용되지는 않지만 서비스나 성능향상을 위하여 개발되어야 하는 업무를 의미한다. 데이터베이스 서버 업그레이드, 웹서버 부하분산 등과 같은 작업들이 해당된다. Chore는 Story와 마찬가지로 Story Point를 줄 수 있다.
Task(태스크)
Task도 Story와 마찬가지로 부서와 상관없이 모두가 이해할 수 있는 쉬운 말로 서술하여 등록한다.
Sub-Task(서브 태스크)
Sub-Task는 개발, 디자인, 마케팅등 해당 부서에서 담당자가 직접 진행할 업무의 단위를 의미하며 이러한 Sub-Task는 전문적인 용어와 각 팀별로 이해할 수 있도록 세부적으로 기술해도 무방하다. Sub-Task는 개발,디자인, 마케팅 등 각 부서의 구성원이 실제 진행가능한 업무의 모듈 단위(Sub-task는 최소 2시간이나 Max 1day의 작업 단위로 세분화한다. 평균적으로 최소2시간 ~ 최대 4시간)
Bug(버그)
소프트웨어의 기능을 저해하는 문제
Hotfix(긴급)
현재 스프린트 계획에 없었거나 긴급하게 발생한 것들은 Hotfix Issue로 등록, 기존 계획에 없었지만 현재 스프린트에 추가한 뒤, 해당 이슈에 대해 다음 스프린트 회고 때 얘기
~~Improvement~~ : 기존의 기능 향상(크게 사용하지는 않음)
~~New Feature~~ : 신규 기능(크게 사용하지는 않음), 실제적으로 New Feature나 Epic이나 같은 의미로 보고 진행

사용자 스토리를 만들고 사용자 스토리의 중요도는 주로 기획자가 선정하며, 스토리 포인트를 산정할때는 개발자가 주도적인 역할을 하여 산정한다.

# 스토리 포인트(Story Point)와 속도(Velocity)

Story Point : 애자일 개발에 있어 스토리 포인트는 소프트웨어의 기능과 요구사항과 같은 사용자 스토리들을 추정하는데 주로 사용되며 유사한것과의 상대적인 크기를 표시하기 위해서 사용되는 임의의 측정 도구이다.
스토리 포인트는 개발팀이 주어진 기능을 구현하기 위해서 시간이 얼마나 걸리는지 정확하게 측정할 수는 없지만 결과물의 특정 기능이 다른것보다 어느 정도 더 복잡한 지를 파악하여 이러한 기능 구현에 더 많은 스토리 포인트를 할당할 수 있게 해준다.
스토리 포인트를 사용하는 것이 익숙해지면 시간이 지남에 따라 각각 반복주기 동안 완료할 수 있는 것이 무엇인지 확실해진다.
백로그에서의 스토리들도 스토리 포인트에 할당되기 때문에 제품 소유자는 스토리 포인트 대비 최상의 기능들에 대한 우선순위를 정할 수 있다.
스토리 포인트는 팀이 합의/동의하는 기준을 찾아서 정해야 한다.
스토리 포인트로 팀별 비교, 개인별 비교는 할 수 없는 데이터 임을 인지해야 하며 처음 스토리 포인트를 잡는것이 어려울 때는 0.5로 지정하는 것이 무난하다.
그러나 이론적으로는 위와 같지만 실제적으로는 Story Point의 개념을 해당 이슈를 해결하는데 걸리는 예상 시간으로 많이 사용한다. 1 Point = 1 Hour / 1 Day = 8 Hours / 1 Week = 5 Days / 주당 Story Point Max = 40과 같은 개념으로 많이 사용하고 있다.
Velocity : 팀에서는 얼마나 많은 스토리 포인트를 반복주기 동안 완료할 수 있는 가를 추적하여 속도(Velocity)를 결정하게 된다.
평균 속도 : 진행한 스프린트의 속도(Velocity) 합 / 진행한 스프린트 수
일별 속도 : 현재 진행한 스프린트의 속도(Velocity) / 현재 진행한 스프린트의 작업일
개인 속도 : 일별 속도 / 팀멤버수
Capacity : 스프린트에서 팀이 처리할 수 있는 스토리포인트(Story Point) Size
Load : 현재 진행중인 스프린트에서 팀이 처리한 스토리 포인트(Story Point) Size

스토리 포인트의 장점

모든 상황에 적합하지는 않지만 스토리 포인트는 절대 사이즈 추정치보다 상대 사이즈 추정에 적합하며 특히 프로젝트를 수행함에 있어 미지수가 있을 때 유용하다
스토리 포인트를 사용하여 일정기간 동안 속도를 추적할때 팀은 수행가능한 작업의 양을 더욱더 잘 예측할 수 있게 된다.
소프트웨어 팀이 계획의 목적에 스토리 포인트를 적용할 수 있고, 속도를 결정하기 위해 스토리 포인트를 사용할 수 있기 때문에 사용하는 것이 좋다.

스토리 포인트의 단점

스크럼 프로젝트의 경우 스토리 포인트가 생산성의 척도로 사용되는 경우 그 원래의 의도와 뒤바뀔수 있다. (해당 스토리가 다른 스토리보다 얼마나 더 복잡한지 여부를 추정해 보는것이 원래의 목적)
스토리 포인트를 상대적 측정으로 각각의 방법으로 스토리 포인트를 사용
(예를 들어 디자인 업무가 스토리 10점을 부여하고 개발 업무가 스토리 5점을 부여하면 실제적으로 시간과 속도가 디자인 업무에서 더 빠르고 효율적으로 나오는 것처럼 보이지만 실제적으로는 그냥 더 많은 스토리 포인트를 사용하고 있는것밖에 되지는 않으므로 의미가 없다. 이를 위해서는 하나의 스토리에 해당하는 스토리 포인트를 지정할때는 여러 팀이 같이 모여 서로가 동의하는 스토리 포인트를 부여하는것이 적절하다.)

# 우선순위 레벨(Priority Level)

우선순위 레벨은 Issue를 등록할 경우 긴급한 순위에 따라 아래와 같이 레벨을 지정할 수 있다. 아래와 같이 높은 우선순위에서 낮은 우선순위로 지정할 수 있다.

Blocker (긴급) : 전체 프로젝트의 진행을 막고 있는 가장 우선적으로 처리해야 할 이슈의 우선순위 레벨
Critical (심각) : 데이터 손실, 심각한 메모리 결함과 같은 치명적인 문제를 발생시키는 이슈의 우선순위 레벨
Major (높음) : 기능 수행 자체에 영향을 주는 이슈 우선순위 레벨
Minor (보통) : 기능의 최소한의 손실이나 간단한 문제점을 발생시키는 이슈의 우선순위 레벨
Trivial (낮음) : 철자오류나 텍스트의 조정 불량과 같은 표면적이며 기능자체와 직접적인 연관은 없는 사소한 문제를 발생시키는 이슈의 우선순위 레벨

# 이슈 상태(Status)

이슈는 이슈별로 고유의 상태를 가지고 있으며 이러한 이슈들의 상태에 따라 업무가 시작, 진행, 종료의 과정을 거치게 된다. 기본적으로 이루어지는 개발 과정은 아래와 같다.

Backlog(기획중) —-> Selective for Dev(기획 및 디자인 완료) —-—> In Progress(개발단계) ——> QA(품질검수) —-> Done(최종완료) —> Release(서비스 배포)

Backlog(백로그) : 해당 이슈가 백로그로만 등록되어 있는 상태
Open(개설) : 이슈가 Open된 상태(최초)
Selective for dev : 실제 개발을 진행하기 위하여 기획, 컨텐츠, 디자인등이 완료된 상태
In Progress(진행중) : 담당자가 배정되어 해당 이슈가 작업이 검토 혹은 수정이 이루어지고 있음
Resolved(해결) : 개발자가 해당 이슈를 해결하고 보고자나 QA담당자로부터 해당이슈가 해결되었음을 확인한다. 확인후 해당 이슈가 재수정이 필요할 경우 다시 오픈되어지며 최종적으로 완료될 경우 해당 이슈는 종료되고 Closed 처리가 된다.
QA : 해당 이슈를 적절하게 완성되었는지 품질 검증
Reopened(재개설) : 해당 이슈가 한번 Resolved 처리가 되었지만 정확하게 해결되지 않았을 경우 해당 이슈는 다시 Re-open처리
Closed(종료) : 해당 이슈의 개발, 디자인, 테스트가 모두 완료되어 정확하게 해결되었을 경우 처리되는 상태(최종 완료)

# 이슈해결상태(Resolution)

이슈를 백로그에 등록하고 처리하면서 Sprint의 최종적으로 Done상태로 왔다면 이를 최종적으로 해결된 상태로 변경시켜주어야 한다. 이때 사용하는 것이 이슈 해결 상태이다. 이슈해결 상태는 아래와 같은 종류들이 있다.

Cannot Reproduce(재현불가) : 이슈를 재현하기 위한 정보가 불충분하거나 이슈를 재현하기 위한 모든 시도가 실패되어 자세한 정보가 나와 이슈를 재현가능할때 해당 이슈를 재오픈 필요
Duplicate(중복) : 해당이슈는 기존 이슈와 중복되어 있으며, 이 해결책을 처리하기 위해서 중복된 Issue에 link할 것
Fixed(수정) : 해당 이슈가 처리 완료
Incomplete(정보부족) : 이슈에서 작업할 정보가 불충분
Won’t Fix(수정불가) : 해결할 수 없는 이슈일 경우
Done(완료) : 해당 이슈 최종완료

이슈가 resolved 되었다면 Resolution 필드는 위 상태중 하나를 가지게 된다.

# 워크플로우(Workflow)

Jira Default Workflow : Open, In Progress, Under Review, Resolved, Closed, Reopened

Jira의 가장 큰 특징 중의 하나가 상당히 많은 부분에 대해서 Customization이 가능하다는 것이다. 그 중에서 강력한 기능중의 하나가 워크 플로우 기능이다. 지금까지 설명한 프로세스는 To do/In progress/Closed와 같은 일반적인 스크럼 기반의 워크 플로우지만, bug나 feature, test case와 같은 Issue 타입에 따라서 워크 플로우가 다를 수 있다. jira에서는 이렇게 각각 다른 Issue 타입에 대해서 다른 워크 플로우를 정의 및 정의할 수 있도록 지원한다. 지라에서 기본적으로 제공되는 워크플로우(Workflow)는 Open, In Progress, Under Review, Resolved, Closed, Reopened의 6단계이며, 최초에 이슈를 백로그에 등록할시 Open 상태가 된다. 스프린트 회의를 통해 우선순위와 담당자, Story Point, 추정 시간등이 할당된뒤 담당자가 작업을 시작하면 In Progress 상태가 된다. 이때 본인이 작업한 시간을 Task 작업기록에 남기도록 한다. 이슈가 해결되면 Under Review 상태로 해당 이슈를 변경한다. 이슈가 완전히 Resolve 하거나 Close 된것은 스크럼 회의를 진행하면서 최종적으로 확인을 받는다. 종료된 이슈를 다시 open 해야할 경우 reopen으로 보내면 된다.

# 구성요소(컴포넌트, Component)

컴포넌트(Component)란 프로젝트를 세분화 시킬 수 있는 단위로서 소프트웨어를 구성하고 있는 각각의 단위 요소를 의미한다. 예를 들어 Web, iOS, Android, Database와 같은 것을 의미하며 구체적으로 웹서비스라면 유저인터페이스(UI), 컨텐츠, 프론트엔드(Frontend), 백엔드(Backend), 데이터베이스 서버 등을 의미한다. 해당 이슈가 특정 컴포넌트와 관련된 이슈일 경우 추가해주며, Jira에서 사용언어를 한국어로 설정할 경우 컴포넌트 탭에서 목록이 뜨지 않은므로 가급적 영어로 설정하여 사용하는 것이 좋다.

추가적으로 컴포넌트는 1 Depth로만 생성할 수 있으며, 컴포넌트의 하위 컴포넌트를 추가할 수 없다. 만약 하위 컴포넌트를 추가하고자 한다면 아래에서 플러그인을 구매하여야 한다.
Configuration Management Toolkit – https://marketplace.atlassian.com/plugins/com.deniz.jira.versioning/server/pricing
Subcomponent Sample – https://denizoguz.atlassian.net/wiki/spaces/CBSV/pages/45067466/Grouping+of+Components+Inside+a+JIRA+Project+Subcomponents

# 레이블 (Lable)

일종의 SNS에서 태그와 같은 기능으로 해당 이슈가 어떤것과 세부적으로 연관되어 있는지 보기 위하여 추가하는 레이블이다. Frontend, Backend, AWS, EC2, Vue.js등과 같은 것을 넣을수 있으며 이는 나중에 특정 키워드와 관련된 이슈를 찾는데 도움이 된다.

# 스크린(Screen)

스크린(Screen)이란 워크플로우(workflow)와 관계된 이슈를 생성하거나 수정 및 보기를 할 때 나오는 화면 자체를 말한다. 스크린(Screen)의 수정시 필드(Field)와 스크린(Screen)의 수정을 함께 하는 것이 좋다. 아래는 스크린(screen)에서 변경가능한 부분이다.

해당 스크린에 해당하는 목록 수정
이슈(Issue)가 생성되고 수정될때 보여지는 스크린 지정(Screen Schemes 메뉴 이용)
특정 이슈 타입에 스크린 스킴(Screen Scheme) 지정(Issue Type Screen Schemes 메뉴에서 Configure로 설정)

# 필드(Fields)

필드(Field)란 지라에서 여러 스크린(Screen)에 나타나는 목록의 정보들을 말한다. 만약 “Resolve Issue” 스크린을 열면 보이는 ‘Resolution’, ‘Fix Version’, ‘Asignee’ 등의 필드등이 해당된다. 필드(Field)를 수정할 시 필드(Field)와 스크린(Screen)을 함께 수정하는 것이 좋다.

# 버전(Version)

버전(Version) 메뉴를 사용하여 각 프로젝트에 해당하는 소프트웨어의 버전을 정의할 수 있다.

# 칸반

칸반(Kanban)에는 개별적으로 추진할 업무를 모두 등록한다. 애자일 스크럼 팀에서 칸반보드를 사용하는 것을 종종 볼 수 있다. 벽면의 포스트잇으로 할일을 붙여두고 할일, 진행중인일, 완료된일을 구분하곤하는데 JIRA에서는 이를 위해 칸반보드를 두가지 타입으로 제공하고 있다. 첫번째는 제품 백록그를 모두 볼 수 있는 칸반보드이고 두번째는 현재 진행중인 스프린터 만을 위한 칸반보드를 보여준다. 추가적으로 칸반으로 구성된 업무는 업무를 시각화하고 팀간 워크플로우를 최적화하는데 사용된다. (이것들을 보고 PM이 Epic으로 묶어낼수도 있고 그냥 task로 남겨둘수 있다. 대신 등록시 PM에게 자신이 등록한 업무에 대해서 업데이트를 해줘야 epic으로 묶어낼수 있다. )

지라의 프로젝트에서는 생성할 수 있는 보드가 2가지 타입(스크럼, 칸반)이 있는데 칸반 방법론은 기본적으로 스크럼과 기본적인 개념은 공유하지만 접근 방식이 다르므로 같은 것이 아니다.
스크럼 : 정기적이고 시간이 고정된 스프린트(즉, 2주)를 기반으로 사용자에게 배포하고자 하는 기능을 빠르게 개발하여 전달하는 것이 목적
칸반 : 정기적인 시간의 구분없이 칸반의 swimlane안에서 지속적안 흐름으로 기능을 배포하는 것이 목적( i.e 컨베이어벨트)
(참조자료 : https://ko.atlassian.com/agile/kanban)

# 스프린트 생명주기(Sprint Lifecycle)

스프린트 생명주기라는 거창한 의미를 부여했지만 실제로는 하나의 릴리즈만을 위하여 혹은 하나의 릴리즈를 하기 위해서 복수의 스프린트들이 순차적으로 시작하고 이슈를 처리해 나가면서 최종적으로 스프린트를 종료함으로써 벌어지는 스프린트 생명주기는 아래와 같다.

[1] 기획, 컨텐츠, 운영, 개발, 디자인, 마케팅등에서 각 팀원이 필요한 기능을 유저 스토리(User Story) 형식으로 지라 백로그에 등록한다. 등록시 상세한 기술이나 개발내용, 디자인, 기획등이 반드시 나와야 될 필요는 없으며 추후 Comment로 기록해 두거나 Sub-Task로 만든다. 위에서 스토리를 서술하는 정의를 참조하면 스토리는 “as a {user}, I want to {do something}(사용자로서 어떠어떠한 것을 하기를 원한다 or ~를 할 수 있다.)” 형태로 정의되어야 한다.
예1) 신규조회 기능 => 에픽(Epic)
예2) [사용자]로서 웹사이트내 자신이 쓴 글을 조회할 수 있다. => 스토리(Story)
예3) [기획팀]으로서 사용자가 최적화된 조회조건이 무엇인지 파악해야 합니다. => 스토리(Story)
예4) [개발팀]으로서 데이터베이스 서버의 성능을 향상시켜야 합니다. => 쵸어(Chore)
예5) [마케팅팀]으로서 제휴관련 내일까지 급한 쿠폰 발급건이 필요합니다. => 긴급(Hotfix)
예6) [사용자]로서 웹사이트가 갑자기 동작하지 않습니다 => 버그(Bug)
[2] 스프린트 회의 시 기존 진행한 스프린트에 대해서 리뷰를 하고 최종완료 처리를 한다. (완료하지 못한 이슈는 Backlog로 이동 처리)
스프린트 리뷰를 진행시 Problem, Keep, Actions는 Confluence 회의록에 남겨둔다.
[3] 신규 스프린트가 시작되면 회의를 통하여 백로그에 있는 이슈들의 우선순위(Priority)를 지정한다. 팀원은 개별적으로 백로그에서 할일을 선택하여 스프린트에 넣으며 팀원들이 서로 합의를 통하여 스토리 포인트(Story Point)를 설정한다. Sub Task가 발생하지 않을 것 같은 이슈라면 예상작업시간(Estimated time)을 스토리 포인트(Story Point)와 같게 설정해주고, Sub Task가 발생될것으로 예상되면 원본 이슈(Issue)에는 예상 작업 시간(Estimated time)을 설정하지 않는다. 왜냐하면 시간을 예측하려면 Sub Task의 예상시간까지 모두 합산되기 때문이다.
[4] 긴급(Hotfix) 이슈가 등록되면, 정말 긴급한 이슈인지 여부를 확인하고 진행해야 되는 이슈라면 담당자를 지정해준다. 긴급 이슈는 현재 진행중인 스프린트에 등록하며, 다음 스프린트 회의때 리뷰한다.
[5] 스프린트 회의가 [1] ~ [4]의 과정을 거쳐 모두 등록 및 정제가 되었다면 스크럼 보드에 스프린트의 이슈들이 표시된다.
[6] 스프린트에 등록된 이슈(Issue)들이 모두 진행되고 릴리즈가 이루어지거나 혹은 다음 스프린트로 넘어가야 된다면 현재 스프린트를 종료한다.(Jira에서는 “Complete Sprint”로 수행)
[7] 스프린트를 종료후 새로운 다음 Sprint를 바로 시작할 수 있는데 가급적 이때 스크럼 회고(Retrospective)를 진행하면서 지난 Sprint에서 잘한 것, 못한것 그리고 개선해야 할 것을 논의하면서 프로세스를 개선해나가는 것이 좋다. 프로세스 개선을 위한 의견들을 논의하고 다음번 스프린트를 진행하는데 반영하는 것이 좋다. 또는 회고중 나온 내용을 Confluence에 정리한다. 회고가 끝난후에, 앞서 진행했던 [1]의 과정부터 다시 수행한다.

# 백로그(Backlog)

스프린트(Sprint)의 Overview 역할을 하며 Estimate은 시간단위로 대개 2,4시간 단위이며 1일이 넘어갈 경우 sub-task로 쪼개야 한다.

[지라(Jira)와 Conflence 연동]

Atlassian Confluence에서 다이어그램을 작성하기 위해 Gliffy Diagrams, Draw.io Diagram, Lucidchart Diagram과 같은 플러그인 설치가 필요하다. 각 다이어그램의 기능성은 상대적으로 비슷하며, 다이어그램의 모양, 사용자 인터페이스와 같은 개인의 취향에 맞는 플러그인을 사용할 수 있다.
RefinedWiti(Plugin) – https://marketplace.atlassian.com/plugins/com.refinedwiki.confluence.plugins.theme.original/server/pricing

[지라(Jira)와 Slack연동]

지라에서 이슈나 특정한 이벤트들이 발생하였을때 Slack 채널에 알림을 받을수 있다.

Jira Server Alerts : https://slack.com/apps/A0F7YS3MZ-jira-server-alerts

위의 링크를 접근하여 Install 처리를 하게 되면 “https://hooks.slack.com/services/~~~~”로 시작하는 WebHook URL을 얻을수 있다. 이 URL을 아래와 같이 Jira의 “System” > “Webhook”메뉴에 들어가 WebHook URL을 입력하여 트리거에 맞는 알림을 받을수 있도록 처리할 수 있다.

[지라(Jira)와 Bitbucket 연동]

https://confluence.atlassian.com/display/JIRA/Integrating+with+a+Source+Control+System

Github 커밋 메시지에 Issue Number를 붙임으로써 이슈의 개발 필드에 나타낼 수 있다. 커밋 메시지를 “#PL-13 #PL-24 Issue resolved. ” 라고 넣어서 Push하게 된다면 Jira와 연동되는것이다.
Commit/Push 직후 바로 JIRA에 체크되지는 않고 시간이 조금 걸린다.

Likes 1