[Software Engineering] 애자일 개발 방법론 그리고 스크럼을 경험하자 (Agile Software Development and Experience of Scrum)

애자일 프레임워크. 스크럼

 

 

 

 

해당 포스트는 경기대학교 소프트웨어 공학 강의의 도움을 바탕으로 작성되었습니다.

 

소프트웨어는 개발은 팀을 만들고 인원들이 서로 협업하면서 이루어집니다. 이러한 소프트웨어 개발을 위하여 다양한 방법론이 제시됩니다. 구조적 방법론, 객체 지향 방법론, CBD 개발 방법론 등 필요에 따라 알맞은 방법론을 선택할 수 있습니다. 이번 포스트에서는 애자일 개발 방법론에 대하여 알아보고 K-scrum을 통한 실제 경험을 공유해 보겠습니다.

 

---

Agile Software Development

 

출처 : https://kruschecompany.com/agile-software-development/

 

애자일 개발 방법론이란 이름 뜻 그대로 재빠르게(Agile) 최소한의 실행 가능한 제품(minimum viable product)을 출시하는 것을 기본으로 합니다. 이후 유저의 행동이나 피드백을 받아서 제품을 수정하고 기능을 추가하면서 개발이 이루어집니다.

 

그 유명한 폭포수 모델(Waterfall method)과 정 반대의 성격을 가지고 있습니다. 폭포수 모델은 개발을 시작하기 전 매우 구체적인 요구 사항과 설계도를 만듭니다. 그리고 개발을 진행하여 '완전한' 제품을 출시합니다. 이러한 특징 때문에 개발하고자 하는 제품이 복잡해질수록 설계 과정에 소모하는 시간이 급격히 늘어나게 됩니다.

 

 

 

출처 : https://management.org/waterfall-methodology

 

 

현재 소프트웨어 산업의 특성상 원하는 제품을 빠르게 개발하는 것이 중요합니다. 실제로 개발을 진행할 때도 처음부터(Scratch) 만들기보다는 이미 만들어진 틀에서부터 시작하는 경우도 많다고 합니다. 또한 개발되는 제품은 날이 갈수록 복잡해지고 있기 때문에, 애자일 개발 방법론이 주목받는 것은 당연한 상황이 되었습니다.

 

---

 

Scrum

 

출처 : https://theartofgoalkeeping.com/product/rugby-scrum-design/

 

럭비 경기를 보신 적이 있다면 스크럼에 대해 들어본 적 있을 것입니다. 경기를 재개할 때마다 양 팀의 선수들이 한 장소에 모여서 공을 차지하기 위해 경쟁합니다. 이러한 스크럼이 애자일 프레임워크(Agile Framework)에서 소프트웨어 개발 용어로써 사용됩니다.

 

스크럼의 두드러진 특징으로 스크럼 마스터(Scrum Master)와 프로덕트 오너(Product Owner)의 존재가 있습니다. 이들은 스크럼팀(개발자, 디자이너, QA 그리고 테스팅 등)을 조직하고 관리하는 역할을 합니다.

 

출처 : https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/

 

 

---

 

Sprint

스크럼은 여러 번의 스프린트(Sprint)를 거치면서 진행됩니다. 하나의 스프린트는 약 2주간 진행되는데, 그동안 정해진 양의 작업을 완료하게 됩니다. 이러한 스프린트의 특징은 애자일 원칙의 "빠른 제품 배포 간격" 그리고 "계획의 변화를 수용"에 부합한다고 볼 수 있습니다.

 

출처 : https://www.cybermedian.com/what-is-a-sprint-in-scrum/

 

 

스프린트의 진행 과정은 아래와 같습니다.

1. 스프린트 전 회의를 통하여 프로덕트 백로그를 스프린트 백로그로 변화시킵니다.
2. 스프린트 기간 동안은 미리 정한 목표를 완수합니다.
3. 데일리 스크럼을 진행합니다. 15분 이내의 짧은 시간 동안 진행하는 미팅으로 팀의 작업상황을 확인합니다.
4. 스프린트가 끝나면 다음 스프린트를 준비합니다.

 

 

---

 

K-Scrum

경기대학교 소프트웨어 공학 강의에서 이러한 스크럼의 진행 과정을 실제로 경험할 수 있었습니다. 이는 K-scrum으로 불리는 학생 교육용 경량화 스크럼을 통하여 진행되었습니다.

 

먼저 팀을 구성한 후 각자 역할을 프로덕트 오너(Product Owner), 스크럼 마스터(Scrum Master), 개발 팀(Develop Team)으로 나누었습니다. 글쓴이는 스크럼 마스터의 역할을 맡게 되었습니다. 앞으로 제품 개발 과정에서 작업을 잘 할당해 주고 개발 팀을 관리하는 일을 하게 됩니다.

 

개발 주제는 Movie Lens를 통한 영화 추천 웹사이트의 개발이었습니다. 스프린트는 0부터 3까지 진행되며 각 스프린트는 2주간의 기간을 가지게 됩니다.

 

아래부터는 각 스프린트의 리뷰와 최종 결과에 대한 후기를 서술하겠습니다.

 

출처 : https://www.scrum.org/resources/what-scrum-module

 

 

---

 

스프린트 0

스프린트 0은 본격적인 개발을 시작하기 전 팀원들 간의 아이스 브레이킹을 위한 시간으로 구성되었습니다. 개발 과정에서 팀원들 간의 협업을 위해서는 신뢰가 바탕이 되어야 합니다. 목표를 향해 달려가기 전 각자의 능력과 역할을 다시 한번 파악하는 시간을 가졌습니다. 

 

작업을 위해 디스코드와 카카오톡으로 소통했습니다. 그리고 앞으로 따라야 할 깃 전략을 시각화하여 미리 공유했습니다.

 

Main을 루트로 Release branch를 만들었습니다. 그리고 Backend와 Frontend 브랜치 두 개로 나누어 작업을 구분했습니다. 각자 역할에 맞게 Frontend와 Backend 브랜치에서 자신의 작업 브랜치를 만들어 수행한다면, 누가 어떤 작업을 얼마나 했는지 확인하기 용이하다고 생각했습니다.

 

---

 

스프린트 1

가장 먼저 2주간의 스프린트 동안 2번의 미팅을 하도록 정했습니다. 스프린트를 시작하기 전 작업을 분배하는 미팅, 작업을 잘 수행했는지 확인하는 미팅이었습니다.

 

K-scrum은 실제로 실무에서 만나는 것처럼, 팀원 대부분이 처음 보는 인원이었습니다. 이러한 상황에서 작업을 알맞게 분배하고 어떻게 참여를 유도할지 스크럼 마스터로서 고민하게 되었습니다.

 

우선 개발팀의 인원들은 생각보다 작업에 미숙한 상황이었기 때문에 PO와 함께 작업에 적극적으로 참여해야겠다는 계획을 세웠습니다.

 

피그마로 구성한 제품 UI

 

그리고 개발팀을 위하여 먼저 틀을 잡아야겠다고 생각했습니다. 피그마를 통해서 제품의 UI를 구성한 다음 개발팀과 공유했습니다. 작업을 지시하기 위해서 시각적으로 목표를 보여준다면 쉽게 따라올 수 있을 것이라 생각했습니다.

 

---

 

스프린트 2

스프린트 1에서 제작한 틀에 숨을 불어넣는 시간이 되었습니다. 스프린트 2에서는 추천 기능을 제외한 기능들을 모두 구현하고자 생각했습니다. 사이트에서는 영화의 리스트를 화면에 보여줍니다. 그리고 영화에 댓글을 달거나 좋아요를 표시할 수 있고, 그것만 모아서 확인하는 기능을 생각했습니다. 그러기 위해서는 현재 정적인 웹 사이트를 동적으로 바꿀 방법이 필요했습니다.

 

문제는 Developer Team에서 서버와 DB를 다룰 수 있는 인원이 없었기 때문에 난감한 상황에 빠졌었습니다. 다행히 PO가 DB에 관한 역량을 가지고 있었기에 어떻게든 진행할  수 있었습니다. 이에 따라 기존의 HTML에서 PHP를 사용하도록 계획을 변경하였습니다.

 

Movie Lens Database

 

---

 

스프린트 3

스프린트 2에서 추천 기능을 제외한 기능을 모두 구현했지만 아직 부족한 점이 많았습니다. UI가 매우 미숙한 상태였으며, 추천 기능 또한 아직 전혀 구현되지 않았었습니다.

 

개발하고자 한 추천 기능은 정렬 알고리즘을 통한 방법입니다. 사용자는 장르, 연도, 정렬 기준을 선택합니다. 이를 바탕으로 가장 적합한 영화를 추천해 주도록 하였습니다.

 

다만 이렇게 만들면 계속해서 추천되는 영화만 추천이 될 가능성이 높기 때문에 차후에 개선할 필요성이 있다고 생각합니다.

 

마지막 스프린트부터는 글쓴이 또한 개발에 적극적으로 참여하게 되었습니다. 사이트의 전반적인 버그를 수정하고 UI 개선에 힘을 쏟았습니다. 마지막으로 PO와 함께 추천기능을 개발하여 웹 사이트를 릴리즈 하였습니다.

 

GitHub - boroboro01/SoftwareEngineeringProject: Kyonggi University Software Engineering Project Repository. The website recommen

 

 

그렇게 마지막 스프린트가 종료되었습니다.

 

 

---

후기

소프트웨어 공학 수업 또한 막바지를 향해 달려가고 있습니다. 3학년이 되면서 짧은 시간에 많은 팀 프로젝트를 수행하게 되었습니다. 외부 공모전까지 합치면 4개가 넘는 프로젝트에 참여하면서 최근 정말 많은 성장을 하고 있다고 느끼고 있습니다.

 

이러한 상황에서 특히나 소프트웨어 공학 수업의 중요성이 두드러진다고 생각합니다. 지금까지 학교에서 배운 수업은 개발 자체에 대한 내용이었습니다. 하지만 개발자라면 당연하게도 팀을 이루어야 하는 상황에서 '어떻게 개발 협업을 잘 수행할까?'에 대한 내용을 제시히고 있기 때문입니다.

 

개발자에게 팀워크는 중요한 역량입니다

 

 

K-scrum을 통하여 이러한 과정을 이론뿐 아니라 실습으로 배워볼 수 있어 좋았습니다. 스크럼 마스터의 역할을 수행하면서 팀을 이끌고 개발팀과 대응하는 방법을 경험하는 것은 쉽게 해 볼 수 없었던 경험이라고 생각합니다.

 

하지만 스크럼 마스터의 역할을 잘 수행했느냐? 하면 아쉬움이 남는 것은 사실입니다. 스프린트 막바지에는 PO와 글쓴이 두 명이서 개발을 도맡아 하게 되었습니다. 그렇게 되면서 스프린트 3에 업무가 과중되는 문제가 생겼습니다.

 

개발팀의 역량이 부족했다고 무작정 탓을 할 수도 있지만, 그러한 상황에서 데일리 스크럼을 통해 개발팀의 참여를 잘 유도하여 작업을 수행했더라면 진행이 조금 더 수월했으리라 생각합니다.

 

글쓴이는 팀장 역할을 맡아 팀을 이끄는 것을 좋아합니다. 앞으로도 수많은 프로젝트를 진행하게 될 텐데, K-scrum의 경험은 이러한 상황에서 필요한 능력을 얻어가는 좋은 기회였다고 다시 한번 회고합니다.

---