프로젝트 요구사항 분석&플래닝 연습하기

개요

지금까지 해온 프로젝트들을 돌이켜보면 제각기 다양한 계획을 거쳤습니다. 소프트웨어 공학을 배우고 유스케이스니, 시퀀스 다이어그램이니 잔뜩 회의하고 구상했던 기억이 납니다. 그런데 하나같이 공통점이 있었는데, 상황에 따른 목적이나 필요도를 따지지 않고, 그저 배운 내용을 기계처럼 따라했을 뿐이었다는 겁니다. 그래서 후반부에 다다르면 대뜸 UI/UX를 설계 해버린 뒤 구현을 시작하곤 했습니다. 기획/설계는 물론 Git도 제멋대로, 가진 지식이 허용하는 데까지만 사용했습니다. 그러니 프로젝트 결과물은 언제나 기대치에 떨어질 수밖에 없었습니다.

 

이번 솔로 프로젝트에서 프로젝트 요구사항 분석&플래닝 과정을 배우게 되었습니다. 지금까지 대충 진행한 프로젝트 과정의 이상적인 버전이었습니다. (단 소프트웨어 설계라기 보다는 전체적인 프로젝트 관리 방법까지만)

 

아래 실습은 기획 단계에서 어느정도 요구사항 명세서가 작성된 이후에 진행되는 분석/설계 단계라고 보면 됩니다.

 

 

 

애자일 방법론 구체화 과정

애자일 방법론을 활용하기 위한 도구들에는 여러가지가 있습니다. 그 중 가장 많이 사용하는 도구인 스크럼(Scrum)을 사용하여 프로젝트를 기획해보려 합니다.

 

스크럼 이란, 스프린트를 기반으로 애자일 방법론을 실행하는 개발 프로세스입니다. 일련의 원칙을 바탕으로 작업을 구조화 하고 관리할 수 있게 도와줍니다.

 

스프린트 란, 팀이 일정량의 작업을 완료하는 시간을 정한 짧은 기간을 말합니다. 보통 2주를 기준으로 하며 팀의 특성에 맞게 줄이거나 늘입니다.

 

어쩐지 개념적으로 접근하면 애매한 기분이 들지만 직접 경험하면 아주 간단하게 느껴집니다.

 

 

첫 번째 단계, 플래닝

1) 하나의 스프린트가 시작하는 월요일, 해당 스프린트 기간 동안 작업할 수 있는 시간을 모두 합쳐 총 작업 시간을 책정다.

 

하나의 "스프린트" 날짜 단위 동안 작업할 수 있는 시간을 계산합니다.

 

예시는 이렇습니다.

 

만약 평균 9시간 근무라고 가정했을 때, 예상할 수 없는 미팅 시간 등을 임의로 배제하고, 개발자가 온전히 "개발 작업"에만 집중할 수 있는 시간을 추정합니다. 약 5시간 정도로 추정한다고 생각해 봅시다. 만약 2주간 작업에 참여하게 된다면, 개발자 한 명에 대한 총 작업 시간은 (5 × 스프린트 기간) 이 됩니다.

 

 

2) 스프린트 동안 할 작업들을 추산하는 플래닝을 진행한다.

 

프로젝트 작업은 Backlog - Todo - In Progress - Done 4가지로 분류됩니다.

 

아래 화면은 Github Projects를 활용하여 작업을 정리한 모습입니다. (Jira도 많이 사용된다고 하네요)

 

 

Github Projects 스크럼

 

• Backlog : 프로젝트 기능 분석에 따라 도출된 이슈(카드)들. 프로젝트에 필요한 모든 기능
• Todo : 한 스프린트(약 일주일) 동안 진행할 이슈들
• In Progress : 스프린트 기간 동안 현재 진행되고 있는 이슈들
• Done : 스프린트 기간 동안 완료된 이슈들

 

일단 프로젝트 기간 동안 해야하는 모든 작업(기능)을 모읍니다. 이를 Backlog 라고 합니다. 기능을 정리했으면 각 기능별 상세 구현 계획을 세워야 합니다. 어떤 기술을 사용하여 구현할 것인지 구체적으로 정해 놓아야 어떤 팀원이 해당 기능을 담당하게 되었을 때 혼선이 없습니다.

 

각 기능을 어떻게 구현할 것인지 정했다면, 개발자가 모두 모여 각 기능에 대한 작업 시간을 측정합니다. 이를 플래닝 포커라고 하는데, 아래에서 더 자세히 설명하겠습니다. 작업 시간이 측정된 후에는 자신이 작업할 기능을 골라 Todo로 옮깁니다.

 

구현이 시작되면 In Progress로 옮기고, 구현이 끝난 기능은 Done으로 이동합니다.

 

이렇게 하나의 스프린트가 종료됩니다.

 

아, 구현 기간 동안 매일 아침 약 15분 정도 데일리 미팅을 진행하여 개인별 오늘 할 일을 공유하고 어제 한 일을 리뷰한다고 하네요.

 

 

3) 가능한 작은 단위로 쪼개진 각 카드들을 가지고 개발자들이 모여 한 카드에 대해 개발 시간이 얼마나 걸릴 지 추정하는 플래닝 포커 작업을 시작한다.

 

일단 칸반에 Backlog 까지만 기능을 정리했다고 가정했을 때, 다음 단계인 플래닝 포커를 진행해야 합니다.

 

예시는 이렇습니다.

 

[Header 기능 개발] 이라는 작업이 있다고 합시다. 개발자들은 만약 자신이 'Header 기능 개발'을 진행한다면, 얼마의 시간이 걸릴지 각자 계산합니다. 그리고 추정 시간을 동시에 제시합니다.

 

날짜 단위는 0.5h, 1h, 2h, ..., infinite까지 존재하며 팀에 따라 day나 point를 쓰기도 합니다.

 

서로 제시한 시간이 맞지 않으면 가장 긴 시간을 제시한 사람과 가장 짧은 시간을 제시한 사람이 그 이유를 설명한 뒤, 다시 플래닝 포커를 진행합니다. 이 작업은 모든 개발자가 만장일치가 나올 때까지 반복합니다.

 

 

4) 플래닝을 통해 시간 추정이 완료된 이슈카드들은 Backlog 에서 Todo로 옮겨진다. Todo에 있는 모든 카드는 해당 스프린트 동안 완료해야 하는 목표가 된다. 개발자들은 Todo에 있는 이슈 카드를 In Progress에 옮겨두고 개발을 진행한다.

 

스프린트 중간에 들어오는 이슈카드는 무조건 다음 스프린트를 위한 Backlog의 상단으로 들어가게 되며 해당 스프린트 기간 동안에는 고려하지 않습니다.

 

또한, 스크럼에서 Hotfix(실제 돌아가는 서비스에 배포를 내보내야 하는 시점에 생긴 긴급한 버그나 오류 이슈)를 해당 스프린트에 절.대. 넣지 않습니다.

 

매출에 직접적인 영향을 미치는 Top Priority급이 아니라면 무조건 다음 스프린트의 Backlog로 쌓이게 되고, 다음 스프린트의 업무가 됩니다.

 

 

5) 해당 스프린트가 끝나는 주의 금요일에는 그동안 플래닝을 통해 진행했던 작업들에 대한 회고를 진행한다.

 

제가 제일 좋아하는 회고 시간입니다. 하나의 스프린트를 끝낸 뒤 하는 회고는 어떨지 궁금하네요.

 

 

프로젝트 요구사항 분석 단계

사실 요구사항 분석은 플래닝 전에 기초적으로 이루어져 있을 것입니다. 그걸 바탕으로 기능을 분류하고, 스크럼에 이슈를 등록하겠다. 하지만 분석은 기획부터 설계, 구현 중에도 계속 이루어지는 게 애자일 방법론의 특징입니다. 요구사항 계획서는 어느 타이밍에 얼마든지 변할 수 있고, 중간에 추가 되거나 삭제 되는 일이 빈번합니다.

 

그러니 지금 이루어지는 요구사항 분석은 스크럼에 정리한 이슈들에 대해 세부적으로 어떤 기능이 들어갈 것인지 분석하는 단계라고 볼 수 있습니다.

 

위에서 하나의 스프린트가 시작되고 끝나기 까지의 과정을 보았습니다. 그렇다면 스프린트가 시작되고 Todo에 들어가기까지 요구사항을 분석하는 과정을 알아보겠습니다.

 

1. 기능 및 페이지 선정

스프린트 기간 동안 진행할 수 있는 대략적인 기능 및 페이지를 선정합니다. 구현할 페이지를 기준으로 해당 페이지의 디자인 목업을 참고하여 해당 페이지의 기능을 분석합니다.

 

만약 메인 페이지를 구현하게 되었다면, 대표적으로 아래와 같은 기능을 뽑아낼 수 있습니다.

 

• Header
• Footer
• 상품 리스트 섹션
• 북마크 리스트 섹션

 

2. 각 기능을 구체화

앞선 단계에서 메인 페이지를 큰 단위로 구분시켰으면 이제 각 기능들을 단위 별로 세부적으로 구체화 해야합니다.

 

예시는 이렇습니다.

 

 

Github Projects 스크럼 카드에 구체적으로 정리한 모습

 

위 화면과 같이 Github Projects를 사용하여 구체적으로 뽑아낸 요구사항을 정리합니다. 이를 통해 작업 기간 동안 모든 요구사항을 올바르게 놓치지 않고 구현할 수 있으며, 다른 개발자가 나의 작업 내용을 확인하며 검토할 수 있습니다.

 

 

3. 이슈 티켓 생성 및 플래닝 포커

이제부터 애자일 방법론 구체화 단계에서 배운 순서를 진행하면 됩니다.

 

Backlog에 이슈 티켓화 작업 이후 우선순위를 기준으로 위에서 아래로 정리하고, 팀원들과 각 티켓별 플래닝 포커를 진행합니다.

 

 

Backlog에 이슈 티켓을 등록하고 플래닝포커를 진행한 모습

 

 

4. 스프린트 범위 설정 단계

스프린트 기간 동안 하루에 집중 가능한 총 작업시간을 계산합니다. 회의 및 휴식 시간 등을 제외하고 온전히 집중 가능한 시간만 총 작업 시간으로 설정해야 합니다.

 

각 티켓의 예상 작업 시간이 플래닝 포커를 통해 결정되고, Todo로 옮겨질 때마다 스프린트 기간 총 작업 시간에서 해당 티켓의 작업 시간을 뺍니다.

 

그리고 스프린트 기간 동안 가용 가능한 총 작업 시간이 0시간이 되었을 때 플래닝을 마칩니다.

 

 

 

프로젝트 초기 구조화 작업

이제 본격적으로 구현을 시작하기 전에, 대표자가 프로젝트 구조화 작업을 진행합니다.

 

프로젝트 초기 구조화 작업에는 아래 4가지가 있습니다.

 

• 깃허브 레포지토리 생성 ― 이건 가장 먼저 했다고 가정
• 프로젝트 폴더링 구성 및 생성
• 초기 README 도큐먼트 작성
• 코딩 컨벤션 정리 및 문서화

 

이러한 구조화 작업 또한 스프린트 기간 내 업무로 추적해 관리합니다.

 

 

 

이렇게 하루 동안 프로젝트가 애자일 방법론에 따라 어떻게 진행되고 관리되는지 알게 되었습니다. 이런 과정들을 배우고 나니 지나온 프로젝트들이 무척 아쉽게만 느껴집니다.