학생 친화적인 교육용 스크럼 프레임워크

2.1 스크럼

스크럼은 사람, 팀 및 조직이 복잡한 문제에 대해 적응형 솔루션을 통해 가치를 창출할 수 있도록 지원하는 경량화 된 프레임워크로 정의한다[3]. 스크럼은 애자일 방법론 중 하나이며 한 스프린트는 보통 2주간으로 구성되며 그림 1과 같이 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고의 활동을 반복적으로 수행한다. 스크럼은 주로 팀을 지속적으로 개선하거나 변화에 대해 빠르게 적응하기 위해 만들어졌다.

Fig. 1.

Integration of scrum process and tool chain

스크럼은 제품의 가치를 관리 및 극대화하는 제품 소유자(Product owner), 스크럼이 조직 내에서 잘 수행되도록 이끌어나가는 스크럼 마스터(Scrum master), 구성된 스프린트를 수행하는 개발팀(Development team)으로 팀이 구성된다[3].

2.2 SAFe

애자일 프레임워크 SAFe(Scaled Agile Framework)는 대기업에 맞춰 확장될 수 있도록 고안되었다[4]. 대기업일수록 스타트업처럼 유연하지도 수평적인 관계를 갖지 못하는 경향이 있다. 이러한 요인들은 애자일 방법론의 도입을 어렵게 한다. 그러나 애자일 방법론을 도입함으로서 얻을 수 있는 이점을 포기하지 못하는 대기업을 위해 설계된 것이 바로 SAFe 이다. 이를 위해서 SAFe는 개발, 운영, 제조, 법률, 마케팅, 재무 등 기술 기반 솔루션을 제공하여 린 혹은 애자일 기법을 적용한다[5].

3.1 툴 체인

툴 체인은 그림 1과 같다. 프로젝트 관리를 위해 노션을 사용하고 형상관리를 위해 깃허브를 사용하며 지속적 통합·배포를 위해 젠킨스와 메이븐을 사용한다. 프로젝트는 이클립스를 통해 개발된다.

이렇게 구성된 툴 체인은 학생들이 쉽게 학습할 수 있도록 사용하는 방법을 설명한 도구 가이드를 제작하였다. 도구 가이드는 툴 체인의 구성요소인 노션, 깃허브, 젠킨스 그리고 메이븐에 대한 매뉴얼이 수록되어있다. 각 도구들의 설치 및 환경설정과 스크럼 프로세스에 맞게 도구를 사용하는 방법에 대해 단계별로 사진과 함께 서술되어있다.

3.1.1 노션

프로젝트 관리를 위해서는 대표적인 도구인 레드마인(Redmine)이나 지라(Jira) 등 여러 도구들이 많다. 그러나 본 프레임워크에서는 프로젝트 관리를 위해 노션을 사용하였다. 우선 레드마인은 항상 작동하는 서버에 탑재하여 언제든 접속할 수 있도록 환경을 구성해주어야 하지만 학교에서는 서버를 제공해주지 못하기 때문에 학생들이 언제 어디서든 접속하여 프로젝트를 관리하기 어렵다는 단점이 있다. 그에 비해 지라는 레드마인과 달리 서버가 필요 없다. 깔끔한 사용자 인터페이스와 칸반보드, 번다운 차트 등 다양한 기능을 제공하지만 그렇기 때문에 초반에는 사용법을 익히기 어려울 수 있으며 다른 도구들과 연동하기 위해서는 복잡한 절차를 거쳐야한다. 그러나 노션은 깔끔한 인터페이스와 처음 접해보는 사람도 쉽게 사용할 수 있을 만큼 접근성이 좋다. 그리고 다른 도구들과 연동하기도 비교적 쉽기 때문에 프로젝트 관리 도구로 노션을 선정하였다. 노션에 구현된 템플릿의 요소는 표 1과 같다.

Table 1.

Project management template with notion

프로덕트 백로그 DB는 사용자 스토리 및 프로덕트 백로그를 저장 및 관리하는 페이지이다. 이곳에서 개체를 생성하면 해당 개체의 사용자 스토리의 아이디가 자동으로 발급되고, 담당자와 상태(진행 예정, 진행 중, 완료), 우선순위(낮음, 중간, 높음)를 설정할 수 있다. 생성 일시는 사용자 스토리를 처음 만든 당시로 고정된다. 그리고 스프린트 항목을 통해 해당 사용자 스토리가 속한 스프린트를 설정할 수 있다. 하위 태스크를 일감 DB로부터 할당이 가능하고, 이 하위 태스크들의 완료 여부에 따라 해당 사용자 스토리의 진행률을 확인할 수 있다.

일감 DB는 사용자 스토리를 분해한 결과인 태스크를 저장하고 관리하는 페이지이다. 프로덕트 백로그 DB와 마찬가지로 개체를 새로 생성하면 태스크 아이디는 자동으로 발급되고, 담당자, 상태, 우선순위를 설정할 수 있다. 자신이 속한 사용자 스토리와 현재 진행 중인 스프린트를 지정할 수 있다. 깃허브의 풀 리퀘스트와 실시간 연동이 가능하여 현재 개발 상황을 파악할 수 있고, 각 요구사항이나 태스크로부터 어느 부분이 개발이 되었는지 추적가능하다.

Master DB는 사용자 스토리 및 태스크 ID의 자동 발급을 위한 페이지이다. 노션에는 숫자를 순차적으로 발급해주는 기능이 없기 때문에 이를 보완하기 위해 추가하였다. 따라서 프로젝트 진행 시 학생들은 이 부분은 따로 수정하거나 추가할 필요가 없다.

GitHub PR은 깃허브를 연동하고 연결된 저장소의 풀 리퀘스트 현황을 보기 위한 페이지이다. 이 페이지는 깃허브에서 변동사항이 있을 때마다 자동으로 업데이트한다. 해당 페이지에서는 지금까지 생성된 풀 리퀘스트 목록과 상태(open, closed, merge) 여부, 생성자, 생성 일시 등을 확인할 수 있다.

종합 보드는 사용자 스토리, 태스크 현황, 체크 리스트를 한 번에 보기 위한 게시판이다. 사용자스토리와 관련 태스크 현황을 칸반 보드를 통해 한눈에 볼 수 있으며 각 스프린트마다 필터를 설정하여 해당 스프린트의 작업 내용만을 확인할 수 있기 때문에 가시성이 좋다. 이 페이지에서 사용자 스토리와 태스크의 개체를 생성할 수도 있기 때문에 사실상 이 페이지만 사용해도 충분하다. 체크 리스트는 프로젝트를 진행하며 각 스프린트 마다 수행되어야할 목록으로 진행상황과 다음 수행 단계를 쉽게 파악할 수 있다.

3.1.2 깃허브

형상관리와 코드, 나아가서는 스프린트 관리를 위해 사용하였다. 이 깃 플로우 모델은 논문[6]에서 고급 플로우 전략을 차용하였다. 이 깃 플로우 모델을 따르면 크게 (task, sprint), (sprint, master) 브랜치의 관계로 나눠진다. 여기서 브랜치란 분기를 생성하여 다른 분기에 영향을 주지 않고 병렬적으로 개발을 수행하기 위해 사용된다[7]. 이러한 특징을 활용하여 task, sprint, master 브랜치를 생성하였다.

그림 2는 베이스 프로젝트를 진행한 결과이다. 제일 위쪽에 있는 검은 선이 master 브랜치, 바로 아래에 있는 파란색 선이 sprint 브랜치, 나머지 브랜치들은 모두 task 브랜치이다. task 브랜치는 개발을 수행하기 위한 브랜치로 각 태스크마다 하나의 task 브랜치를 갖는다. sprint 브랜치는 개발한 코드들을 병합하는 브랜치이다. 마지막으로 master 브랜치는 한 스프린트가 종료될 때마다 sprint 브랜치로부터 병합대상이 되는 브랜치이다.

Fig. 2.

Git branch network graph of base project

먼저 (task, sprint)의 관계는 개발 단계이다. 개발팀은 할당된 태스크 브랜치로 개발을 진행하고 완료되면 스프린트 브랜치에 병합 요청을 한다. 그 후 스크럼 마스터는 검토 후 스프린트 브랜치에 병합을 승인하거나 거부한다. 이때 스크럼 마스터가 병합을 승인한다는 것은 한 태스크가 완료되었음을 의미한다.

(sprint, master)의 관계는 한 스프린트의 완료를 의미한다. 한 스프린트가 완료되면 스크럼 마스터는 sprint 브랜치를 master 브랜치에 병합시킨다. 이를 통해 한 스프린트가 끝날 때 마다 릴리스 버전이 마스터 브랜치에 표시되는 것을 관찰할 수 있다. 그림 2를 보면 sprint 브랜치에서 master 브랜치로 향하는 화살표를 찾을 수 있는데 이 부분이 바로 한 스프린트가 완료된 시기이다.

3.2 베이스 프로젝트

베이스 프로젝트는 교육용 스크럼 프레임워크에 포함되어 같이 배포되는 프로젝트이다. 학생들은 이 프로젝트를 기반으로 스크럼을 진행한다. 베이스 프로젝트에서 개선하거나 추가하고 싶은 기능들을 선정하여 세 번의 스프린트 동안 구현한다.

베이스 프로젝트는 교육용 스크럼으로 진행한 사례연구[8]를 스크럼 프레임워크의 프로세스에 맞춰 개발되었다. 이렇게 개발된 프로젝트는 깃허브에 업로드 된다. 이 프레임워크를 사용하는 학생들은 각 팀의 스크럼 마스터가 스크럼 가이드에 수록된 프로젝트 URL에 접속하여 자신의 개발환경으로 복사하거나 포크(Fork)를 하여 프로젝트를 시작할 준비를 한다.

이 프로젝트는 도서관 웹 페이지를 주제로 개발되었으며 총 6개의 페이지로 그림 3과 같다. 기본이 되는 홈 페이지를 기준으로 관리자 로그인 페이지, 도서 등록 페이지, 도서 리스트 페이지, 도서 상세정보를 볼 수 있는 페이지, 마지막으로 유효하지 않은 접근 혹은 잘못된 URL 접근으로 인한 404 에러 등을 처리하기 위한 예외 페이지로 구성된다.

Fig. 3.

Configuration of base project

3.3 스크럼 가이드

교육용 스크럼 프로세스에 대해 이해하고 프레임워크를 사용하기 위한 방법에 대해 수록되어 있다. 가이드의 구성은 다음과 같다.

• • 프레임워크에 내재된 교육용 스크럼에 대해 설명한다. 이 스크럼의 구성, 각 역할의 행동과 주차별 일정에 대해 정의한다.
• • 교육용 스크럼을 기반으로 제작된 프레임워크에 대해 설명한다. 이 프레임워크에서 사용되는 툴 체인과 베이스 프로젝트에 대해 소개한다.
• • 총 9주차 동안 활동해야할 내역에 대해 설명한다. 이 목록은 주차 별 각 역할의 행동에 대해 설명하고, 한 눈에 보기 쉽도록 체크리스트와 함께 수록되어있다.

각 주차에 대한 활동 구성은 표 2와 같다. 1, 2주차에서는 프로젝트를 시작하기 위한 준비를 하는 시간을 가지고, 3주차부터 8주차 까지는 2주차씩 스프린트를 세 번 진행한다. 마지막으로 9주차에서는 수행한 프로젝트를 발표한다.

Table 2.

Steps of educational scrum process

팀이 랜덤하게 구성되기 때문에 1주차에는 서로를 알아가고 프로젝트의 목표를 세우기 위해 킥오프 미팅을 진행한다. 킥오프 미팅이란 프로젝트를 성공적으로 수행하기 위해 팀을 구성하고 앞으로의 계획을 수립하기 위해 프로젝트를 시작할 때 진행하는 첫 미팅이다[9]. 이를 통해, 소통을 중시하는 스크럼의 특징을 반영하기 위해 킥오프 미팅을 통해 낯선 팀 내에서도 원활한 소통을 진행할 수 있도록 유도한다. 역할은 스크럼 마스터 1명, 제품 소유자 1명, 나머지는 개발 팀으로 분담한다. 스크럼 마스터를 맡게 된 학생은 빌드 및 산출물을 관리하기 위해 자신의 로컬 환경에 툴 체인을 세팅한다. 팀원들은 베이스 프로젝트에 대해 파악하고 각 팀에게 필요한 개발 공부를 선행한다. 1주차의 체크리스트는 표 3과 같다.

Table 3.

Checklist of week 1

2주차에는 고객 요구사항에서 사용자 스토리를 추출하고 우선순위를 할당하는 활동을 한다. 고객과 소통하며 제품의 품질을 담당하는 제품 소유자가 이 활동을 주도적으로 이끈다. 그러나 교내 실습에는 실제 고객이 없기 때문에 제품 소유자는 아이디어 회의를 통해 세 번의 스프린트 동안 진행할 고객의 요구사항을 가장하여 선정한다. 선정된 요구사항을 사용자 스토리로 가공하고 우선순위를 할당한다. 그 이후 각각의 사용자 스토리에 인수 조건을 정의하고 노션의 “프로덕트 백로그 DB”에 업로드하며 마무리한다. 2주차의 체크리스트는 표 4와 같다.

Table 4.

Checklist of week 2

3~8주차에는 2주씩 세 번의 스프린트를 진행한다. 하나의 스프린트는 스프린트 회의, 개발 및 데일리 미팅, 인수 테스트, 스프린트 리뷰 및 회고로 이뤄진다. 스프린트 회의에서는 스크럼 마스터의 주도로 해당 스프린트에서 개발할 사용자 스토리를 결정하고 사용자 스토리로부터 태스크를 추출하여 노션의 “일감 DB”에 업로드 한다. 개발 단계에서는 추출된 태스크를 기반으로 개발을 진행한다. 그리고 SNS 등 채팅도구를 통해 매일 자신의 진행상황을 간략히 보고하는 데일리 미팅을 수행한다. 인수 테스트 단계에서는 개발된 기능이 2주차에서 계획한 인수 조건에 부합하는지 테스트를 한다. 부합하지 않는다면 태스크를 추가적으로 추출하여 개발을 다시 진행한다. 스프린트 리뷰 단계에서는 하나의 스프린트를 통해 만들어진 제품인 war 파일을 노션에 업로드하고 제품을 시연하여 피드백을 주고받는다. 마지막으로 스프린트 회고를 통해 스프린트를 진행하면서 겪은 문제점을 논의하고 개선점을 찾는다. 3~8주차의 체크리스트는 표 5와 같다.

Table 5.

Checklist of week 3 through week 8

9주차에는 완료된 프로젝트를 발표한다. 이때 프로젝트의 평가는 일반적인 소프트웨어 개발 프로젝트와는 달리 완성도뿐만 아니라 “얼마나 스크럼을 잘 수행하였는가?”에도 중심을 둔다. 예를 들어 세 번의 스프린트 동안 세 번의 제품을 추출하였는지, 매 스프린트 마다 적어도 하나 이상의 사용자 스토리를 진행하였는지, 팀원 들의 참여도 등을 평가하게 된다.

3.4 적용 사례

스크럼 프레임워크의 툴 체인과 스크럼을 이용하여 모바일 애플리케이션을 제작한 사례를 소개한다. 프로젝트 초반에는 프레임워크의 프로세스를 따르기 위해 매번 가이드를 살피고 행동하여 진행 속도가 더뎠다. 그러나 시간이 지남에 따라 프레임워크의 프로세스에 대해 익숙해져서 더 이상 가이드가 없더라도 그림 4와 같이 스스로 다음 단계를 밟는 모습을 관찰할 수 있었다. 이를 통해 이 프레임워크는 베이스 프로젝트뿐만 아니라 다른 프로젝트에도 충분히 적용할 수 있으며 스스로 스크럼 프로세스를 학습하고 내재화하여 사용하는 역량을 키우는 것에 효과가 있었다는 것을 알 수 있다.

Fig. 4.

Git branch network of case study