스크럼의 핵심 개념에 대해 배웠으니, 이번엔 실제로 사용해볼 단계이다. 스크럼 같은 애자일 방법론을 사용하여 프로젝트를 관리할 땐 툴을 사용하는 것이 좋다.
스크럼 관리를 도와주는 툴은 여러가지 있지만, 우리 팀은 Jira를 통해 프로젝트를 관리하기로 하였다.

Jira Software

Atlassian에서 개발한 Jira는 스크럼의 철학을 완전히 탑재한 프로젝트 관리 도구다. 백로그, 칸반, 스프린트, 번다운 차트 등 스크럼을 하기 위한 도구들이 포함되어 있고, 자유도가 높다. 팀에 맞게 잘 커스텀한다면 꽤 괜찮은 스크럼 프로세스가 세팅된다.

우리팀은 스크럼을 어떻게 진행했는지 살펴보자.

팀 구성

지금은 프론트엔드 개발자 2명(본인 포함), 백엔드 개발자 1명, 디자이너 1명으로 총 4명이다. 스크럼에 대한 이해도가 제일 높은 다른 프론트엔드 개발자 한 분이 스크럼 마스터를 맡으셨다. 나는 해당 프로젝트 기획에 가장 많이 관여했어서 프로덕트 오너를 맡아 백로그를 작성했다.

일일 스크럼

우선 Jira에서 일일 스크럼 미팅 형식을 직접적으로 지원하는 기능은 없다. 우리는 평일 오전 11시에 구글 미팅을 통해서 15분 동안 스크럼을 진행한다. 각 인원이 빠르게 3가지를 공유하고 끝낸다.

• 지난 스크럼부터 이번 스크럼까지 한 일
• 이번 스크럼부터 다음 스크럼까지 할 일
• 방해 요소

Notion 활용

스크럼을 기록하기 위해 노션에 템플릿을 만들어 활용하고 있다. 각자 스크럼 전에 미리 텍스트로 회의록에 적고 미팅 시간에 구두로 공유한다.

회의록 이름은 진행 중인 스프린트 넘버[DUT-3]와 날짜(6.17)를 조합하여 만든다.

벌금

일일 스크럼 미팅이 원할하게 진행되기 위해서 벌금을 정했다. 지각 5,000원 결석 10,000원이다. 스크럼 시간이 15분 밖에 되지 않기 때문에 지각이 결석으로 이어질 확률이 높다. 스크럼 시작 시간은 1분도 지체되지 않고 시작되기 때문에 모든 인원이 정해진 시간에 항상 다 모이기 위한 장치를 마련했던 것이고 실제로 벌금 시스템 덕분에 일일 스크럼 미팅이 더 잘 진행되고 있다.

스프린트

우리 팀은 첫 스크럼이고, 첫 스프린트이며, 프로젝트의 기간도 길지 않기 때문에(12월 까지) 스프린트 주기가 1달이면 리스크가 너무 크다고 판단했다. 우리는 스크럼 초보니까 빠르게 시행착오를 겪고, 검토하고, 멘토님께 피드백 받는 주기로 1주일이 적당하다고 판단했다.

1주일

해당 프로젝트는 소프트웨어 마에스트로 14기 과정에서 진행한 프로젝트이다. 6월부터 12월까지라는 짧은 기간과 현업에 대단한 멘토님들께 매주 멘토링을 받을 수 있다는 특수성을 고려하여 1주일 단위로 매 스프린트마다 피드백받고 개선하자는 취지로 기간을 정하였다.

스프린트 계획 회의

스프린트 계획 회의는 2단계로 진행했다.

• 스프린트 목표를 정하고 각 팀원의 가용 시간 및 총 가용 시간을 추정한다. 그리고 스프린트 기간 동안 예상되는 방해요소를 팀원들끼리 공유한다.
• 스프린트 목표에 맞는 스프린트 백로그를 작성한다.

스프린트 검토 회의

스프린트 마지막날 담당 멘토님께 스프린트 결과를 공유하고, 팀원들 끼리 3Ls(Liked, Lacked, Learned)로 지난 스프린트를 리뷰한다. 아래는 첫번 째 스프린트 검토 회의에서 얘기한 내용이다.

티켓 범위 설정하기

우선 티켓은 Jira와 같은 프로젝트 관리 소프트웨어에서 사용되는 용어로, 어떤 작업이나 이슈를 말한다. 백로그에 들어가는 각각이 티켓이다.

스토리, 에픽

스토리는 사용자의 관점에서 기능이나 요구사항을 설명하는 용어이며 Jira에서는 티켓의 한 종류로 취급된다. 우리는 기능 명세서에 상세 기능 단위로 스토리를 백로그에 추가했다.

에픽은 관련된 스토리들을 그룹화 한 상위 구분이다. 각각 스토리나 태스크들에는 에픽을 추가할 수 있다. 초록색 아이콘과 제목이 스토리, 옆에 보라색 글씨가 에픽이다.

태스크

스프린트 계획회의를 할 때 정해진 이번 스프린트 동안 어떤 스토리를 해결할지 정하고 스토리를 완수하기 위해 해야하는 태스크들을 추가했다.

하위 태스크

어떤 태스크는 추정 시간이 길고, 그 안에서 하위 태스크를 만들어야 할때도 있다. 다만 하위 태스크 단위보다 더 잘개 쪼개진 않는다.

워크플로 설정

모든 티켓들은 워크플로우 프로세스를 통해 관리된다.

작업이 완료되면 바로 Done으로 가는 것이 아니라, In Review 단계에서 Reviewer에게 검토를 받는다. 검토 대상은 코드가 될 수도 있고(Pull Request), 디자인, 기획이 될 수도 있다. 물론 리뷰를 받을 필요가 없는 것들은 개인의 판단하에 Done으로 바로 보낼 수 있다. 번다운 차트가 정확하게 그려지려면 In Review 상태에 있는 다른 팀원들의 작업을 빠르게 리뷰해줄 필요가 있고, 리뷰를 받을 필요가 없는 것들은 바로 Done으로 보내야 한다.

앞으로

프로젝트 기간동안 계속 Jira를 사용하면서 우리 팀, 프로젝트에 맞게 개선할 예정이다. 현재는 3번 째 스프린트를 진행 중이며 앞으로 계속해서 블로그에 어떻게 진행하고 있는지 정리하려 한다.