이전 글(1부)에서는 sprint 개념을 사용하지 않은 JIRA의 Kanban보드를 사용하는 법을 중심으로 설명하였습니다. 이번 글에서는 scurm의 sprint 단위로 sprint planning하여 관리하는 JIRA의 scrum보드 활용법을 소개합니다.

• 스크럼(Scrum) 이해하기 참조

https://scrumexplainer.com/scrum/scrum-board/

1. Scrum Board와 Kanban Board

• Scrum 보드
  - Timebox(Sprint)단위로 일감관리를 하는 프로젝트
  - 예) 2주 단위로 sprint planning을 수립후 수행하는 개발 프로젝트
  - scrum 보드에는 전체 일감이 아닌, Sprint내에 할당된 감만 보임
• Kanban 보드
  - Timebox없이 일감관리를 하는 프로젝트
  - 예) 요청(Ticket)이 발생되면 최단시간에 처리해야하는 운영 프로젝트
  - Kanban보드에는 등록된 전체 일감이 보임

2. Scrum board 관리

2.1. Scrum board 만들기

• 보드 만들기 선택

• 스크럼 보드 선택

• 보드 이름 입력
  - 칸반보드와 스크럼보드에 익숙하지 않은 분들을 위해서 저는 보드 종류를 구분하기 위해 스크럼 보드 등의 이름을 넣습니다.

2.2. Scrum보드 환경설정

• Scrum 보드 컬럼명 수정

=

2.3. Scrum보드 확인

• 백로그 확인
  - 아래와 같이 Backlog(백로그)에 일감이 있습니다.

• Scrum 보드 확인
  - 현재는 일감이 Backlog에만 있고, 수행중인 sprint에 할당이 되어 있지 않기때문에 아래와 같이 scrum 보드에 일감이 보이지 않습니다.

3. Sprint 관리

3.1. Sprint 생성

3.2. Sprint Planning

• Backlog에서 일감을 Sprint#1으로 이동
  또는 [이슈 생성] 버튼으로 신규 일감 생성 가능

• 다음과 같이 생성된 일감은 Epic(큰틀)에 Drag&Drop으로 할당 가능

3.3. Story Point 입력

• 일감에 story point를 입력

=

• story point 입력 항목이 보이지 않는 경우 추가 방법
  - 필드 구성에서 Story point 항목을 선택

- 만약 story point 항목이 없다면 아래와 같이 System Admin이 추가 가능

3.4. 작업자 할당

• 담당자 : 실무자, 일감의 상태 현행화 책임자 등
• 보고자 : 작업지시자, Product Owner 등

3.5. 일감량 확인

• 일감에 업무량(story points)을 입력해 놓으면, 할당 된 담당자별 일감량 확인을 통해 업무 분장 가능

4. 버전/배포 계획

4.1. 버전 등록

4.2. 버전 계획

• 개발이 예정된 버전에 drag & drop으로 mapping 가능

5. Sprint 시작

5.1. [스프린트 시작] 버튼 클릭

5.2. Scrum 보드 확인

• scrum 보드는 수행중인 sprint에 할당된 일감만 보입니다.
• 또한 Scrum board 환경설정에서 Swim Lane(수영레인)에그룹핑해서 보여주기 위한 기준 설정이 가능합니다.

• 기본 레인별 그룹핑된 모습들

Epic으로 기본 레인을 설정한 경우

Story(이야기)로 기본레인을 설정한 경우

담당자로 기본레인을 설정한 경우

6. Sprint 완료

6.1. 일감 진행 상태 현행화

6.2. Sprint 완료 처리

• Sprint 완료

• Sprint 계획

• 배포(릴리스) 관리

7. 보고서 및 대시보드 관리

7.1. 보고서

• 보고서 선택

• 번다운 차트(소멸 차트)

• 누적 흐름 도표

7.2. Dash보드 관리

• 대시보드 생성

• 가젯 추가

• 보여줄 항목 편집 (프로젝트 선택 등)

• 완성된 대시보드 보기

함께보면 유용한 글보기

• [Agile] 스크럼(Scrum) 이해하기
• [DevOps] JIRA를 활용한 협업(1부)
• [DevOps] JIRA를 활용한 협업(2부)

들어가기에 앞서

스크럼을 적용하는데 있어서 어디서나, 어떤팀에서나 딱 알맞는 형태의 스크럼은 없습니다.
스크럼의 기본인 ‘점진적 개발’을 목표로 회고를 하며 우리팀의 상황에 맞게끔 스크럼을 점점 변형시켜 나가면서 case by team 으로 맞추어 나가야 합니다.

이 포스팅은 앞서 정리한 scrum을 jira로 관리하기 위한 가장 기본적이면서도 구체적으로 진행할수 있는 방안을 제시해보도록 하겠습니다.

Jira default 이슈 종류

• Epic (큰틀) : 여러 스프린트에 걸쳐서 끝나지 않고, 여러 스토리들의 집합입니다.
• Story : “{사용자} 로써 {무엇}을 하고싶다” 에 대한 액터의 유즈케이스
• Chore : 사용자와는 직접적으로 관계되지 않는 개발 (DB 세팅, 분리 등)
• Task : 구현에는 직접적으로 관련이 없는 업무 (문서작성 등)
• Issue : 이슈 사항 (서버 다운, 클라우드 계약 등)
• Bug : 테스트 엔지니어로부터 버그로 리포팅된 타입
• Sub Task : 스토리 혹은 초어들을 개발하기 위해 진행되는 실제 세부 개발사항들

우리 Jira에 맞춘 이슈 정리

• Epic (큰틀)
• TaskStory : 요구사항 혹은 유저케이스 시나리오
  개발 : 개발 요구사항 (chore)
  버그 : 서비스 버그
  작업 : 개발 구현과는 직접적으로 관련 없는 요구사항
  이슈 : 서비스상의 이슈, 확인, 고려사항
• Sub-task개발 / 버그 / 작업 / 이슈

Example

• Epic : 회원가입/로그인
• Task
  1. (Story) 사내 직원이 어드민 회원가입 할 수 있다.
  2. (Task) DB 인프라 신청
• Sub-task1-1. (작업) Oauth 권한신청
  1-2. (개발) 회원가입 서비스 개발

유의사항

• 지라는 진행 프로젝트마다 별도의 프로젝트로 생성하여 관리합니다.
• Release(버전)는 Epic 단위로 정의합니다. (Epic은 필수 기능을 중심으로 프로젝트 진행의 마일스톤으로 사용합니다.)
• Sprint는 Task단위로 정의합니다. (Task는 최대 3일 이내의 작업기간으로 산정합니다.)
• Release > Epic > Sprint > Task

스크럼 진행순서

1. 제품 백로그 준비
(Project Owner)는 프로젝트 요구사항에 맞추어 Epic(큰틀)들을 생성 합니다.
Epic은 필수기능으로써, 프로젝트의 진행 척도를 나타낼수있는 마일스톤이 될 수 있도록 생성합니다.

2. 릴리즈 계획 수립
(Project Owner)는 [1 단계]에서 생성한 Epic들을 가지고 프로젝트 릴리즈 계획을 세웁니다.

3. 스프린트 계획 수립
3-1. Task 만들기
(Project Owner + Scrum Master) 는 [2단계]에서 수립된 릴리즈 계획내에 포함된 Epic들을 세부 작업 Task로 쪼갭니다.
(Scrum Master)는 만들어진 Task를 적절한 팀원에게 배분합니다
배분받은 (스크럼팀)은 Task의 수행시간을 예측합니다. (최대 3일 이내의 작업으로 Task가 분리되어야 합니다.)

(고려해야할 사항)

• 팀원의 가용 시간
• 각 Task에 대해서 수행 시간 예측
• Task 설정시 구체적인 종결 행위를 기반으로 Task 설정 하는것이 좋습니다.
• Task 설정시 분석,설계 / 구현 / 테스트 → 1:1:1 의 리소스 분배가 좋습니다.
• 주요 Task에 대해서는 어떤 형식으로든지 리뷰를 하는것이 좋습니다.
• Task 기간 설정시 20%의 버퍼를 두는것이 좋습니다.

3-2. 스프린트 만들기
(Scrum Master)는 [3-1단계] 에서 만든 Task를 2주단위의 스프린트로 조합 합니다.
스프린트를 만들때에는 Task의 “긴급도, 난이도”에 따라 우선순위를 두고 Task 작업 순서를 정합니다.

3-3. Task 작업
Task를 할당받은 (스크럼팀)은 할당받은 Task를 실제 작업의 세부 단위로 Sub-task를 작성하여 작업을 진행합니다.

4. 스프린트 관리
스크럼팀은 매일 오전 최대 20분 내의 일일 스크럼을 진행합니다. 일일 스크럼때는 어제 작업내용, 오늘 작업예정 내용 및 Task 종료에 필요한 시간들을 공유하고 (Project Owner)는 이슈사항 발생시 일정조정 및 요구사항의 수정 내용을 백로그에 수정 반영 합니다.
(Project Owner)는 스크럼팀의 작업 진행상황을 확인하고 Task의 상태를 설정 해 줍니다. (완료, 작업중 등..)
스크럼팀은 본인이 작업하는 실제 세부작업인 Sub-task들의 상태를 직접 관리 합니다.

5. 스프린트 종료
제 1의 조건으로 스프린트의 정해진 기간 (2주) 단위로 스프린트를 종료하도록 합니다. 만약 Task의 이슈사항으로인해 정해진 기간내에 마무리가 되지 않았다고 하면, 해당 Task를 다음 스프린트로 넘깁니다.
(스크럼팀)은 본인이 수행한 Task의 구현이 테스트까지 완료되었을때 Task가 종료되어야 합니다.
(스크럼팀)은 스프린트 종료일 오전에는 일일 스크럼대신 스프린트 리뷰를 진행하며 구체적인 테스트 결과및 데모를 수행합니다.
(Project Owner)는 완료된 스프린트의 작업사항들을 종합하여 QA를 진행합니다.

6. 백로그 업데이트
(Project Owner)는 스프린트 리뷰 완료후 리뷰과정에서 나온 추가 요건이나 오류사항, 변경상황을 반영하여 백로그를 업데이트 합니다.

7. 회고
(스크럼팀)은 단순 스프린트 작업에대한 리뷰가 아닌, 스크럼 방법론 자체에대한 리뷰를 진행합니다. 이 과정을 통해 우리 팀에 맞는 더 좋은 스크럼 프로세스를 찾고 개선해나갑니다.

8. 스프린트 재시작
스프린트 계획을 수립하는 [3 단계]부터 재시작 합니다.

출처: Jira를 통해 스크럼 관리하기 (taes-k.github.io)