brunch

You can make anything
by writing

C.S.Lewis

by 보이 May 28. 2023

애자일(Agile)과 스크럼(Scrum)

애자일 기본 다지기

잘 정의된 작업은 프로젝트 착수, 계획, 실행, 감시 및 통제, 종료 프로세스로 진행되지만, 불확실성이 높은 작업은 사전에 체계적인 계획을 수립하기 어렵다. 그리고 대부분의 프로젝트는 불확실성이 존재한다. 때문에 우리는 작게 개발하고 자주 배포(CI/CD)하는 애자일 모델을 조직에 적용해야 한다. 오늘은 애자일이 무엇인지와 애자일에서 자주 사용되는 용어에 대해 이야기하겠다.

Agile

애자일(Agile)의 사전적 의미는 '날렵한', '민첩한'으로 애자일 프로세스 모델은 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론을 말한다. 작고 반복적인 주기들을 통해 제품을 개발하며 각각의 주기들은 하나의 짧은 프로젝트로 본다. 애자일에서는 개발 및 테스트를 반복적으로 수행하고, 테스트에 통과한 것은 바로 릴리즈(Small Release)한다.

애자일 선언문

출처: https://agilemanifesto.org/iso/ko/principles.html

애자일은 가벼운 프로세스 방법론의 공통적인 특성을 정의하는 단어인데, 2001년 1월에 각 방법론의 전문가들이 모인 애자일 연합(Agile alliance)에서 서로의 공통점을 찾아 '애자일 선언문'이라는 공동 선언서를 발표했다. 이때를 기점으로 애자일 프로세스가 주목을 받으면서 여러 회사에서 채택하기 시작했다.

고전적인 개발 방법론(Waterfall Model)에서 '계획'과 '설계'가 지나치게 중시되다 보니 오히려 개발을 방해하는 경우가 많았다. 이러한 고전적인 개발 방법론의 한계를 극복하고자 만들어진 것이 애자일 방법론이다. 때문에 애자일 선언문을 보면 문서(계획/설계)보다 작동하는 소프트웨어(결과물)에 더 가치를 두고 있다.

그렇다고 애자일이 '계획'과 '설계'를 하지 않는 것은 아니다. 실제로 애자일 방법론 중 하나인 Scrum은 2주 주기의 Sprint를 만들고, 이를 하루 단위의 Daily Scrum으로 다시 나누어 관리한다. 이처럼 애자일은 오히려 타이트한 계획 속에 관리된다.

즉, 애자일은 계획과 설계가 실제 제품 개발을 방해하지 않도록 하는데 목적이 있다. 프로젝트 초기에 전체를 무리하게 설계하는 부담을 줄이는 것이라고 볼 수 있다.

Scrum

전 세계에서 가장 많이 사용하는 대표적인 애자일 방법론으로 고객 요구사항을 충족시키는데 초점을 맞추며, 짧은 개발 주기를 갖고 점진적이며 경험적으로 시스템을 지속해서 개발/전달하는 기법이다. 스크럼은 2~4주 주기의 Sprint의 반복이며, 스프린트는 Product Backlog → Sprint Planning → Daily Scrum → Sprint Review → Sprint Retro 로 구성된다.

출처: https://teamhood.com/agile-resources/what-is-scrum/

Product Backlog

Product Requirement를 정의하고 이번 분기의 목표(OKR)가 설정되면, 목표 달성을 위한 개발 Task 목록을 만들고 우선순위에 따라 나열한다. 이 목록이 Product Backlog이며, Sprint를 반복하며 백로그에서 P0 아이템부터 꺼내서 개발한다.

(+) 프로젝트 현황 관리를 위해 Jira Dashboard를 사용하면 Backlog에 쌓여있던 티켓들이 하나씩 줄어드는 재미를 볼 수 있다. Jira Dashboard 만드는 법은 다음 포스팅에서 다루겠다.

Sprint Planning

스프린트가 시작되는 시점(월요일 또는 화요일)에 이번 스프린트에 대한 개발 플래닝을 한다. Backlog에 있던 아이템들 중 이번 스프린트에 진행할 아이템을 꺼내서 담당자를 정한다. 이때 매니저(SDM)가 엔지니어를 지정하는 것은 아니고, "제가 하겠습니다" 문화가 있어서 본인이 할 수 있고, 하고 싶은 업무를 손들고 가져간다.

개인적으로 "제가 하겠습니다" 문화는 굉장히 신선했다. 전 직장은 핀테크 사였지만 금융기관 뺨치는 수직적 문화를 가진 조직이어서 개발 팀장이 업무를 할당하는 구조였는데, 애자일 문화를 가진 기업에서는 엔지니어 본인이 할 수 있고, 하고 싶은 업무를 스스로 찾아서 가져간다. 이렇게 하면 보다 주도적이고 열정적으로 업무에 임하여 좋은 결과를 낼 수 있다.

Daily Scrum

매일 30분씩 스크럼 미팅을 통해 어제 한 일, 오늘 할 일을 리뷰한다. 그리고 프로젝트를 방해하는 요소(이슈)가 있다면 공유하고, 도움이 필요한 일을 이야기한다. 애자일에서는 Stand up 미팅을 추천한다. 불필요한 이야기를 없애기 위해 말 그대로 서서 이야기하고, 1명 당 1~2분 내로 이야기를 끝낸다. 그러나 많은 기업에서 재택근무를 시행하며 스크럼이 비대면으로 진행되는 경우가 많다. 비대면인 경우 Stand up 하라고 하기는 어려우므로 필요한 말만 하고, 시간 내에 미팅을 끝낼 수 있도록 PM이 조절해야 한다.

Sprint Review

스프린트가 종료되는 시점에 완료한 일을 살펴보고, 있었던 일을 떠올리고, 다음 스프린트에 할 일을 리뷰한다.

Sprint Retro

회고는 스프린트가 끝나는 시점마다 진행해도 되고, 개발 착수/테스트/완료 등 특정 주기를 갖고 진행해도 된다. 주기성을 갖고 회고를 진행한다는 조직 문화를 만드는 것이 중요하다. 또한 회고는 문제에 대해 추궁하거나 프로젝트 문제점에 대한 해결 방안을 만드는 자리가 아니다. 프로젝트를 수행하며 느낀점을 공유하고, 개선점(Action Item)을 만들어 다음 기간에 개선/적용하는 것이 주목적이다. 회고에서는 Keep, Problem, Try 세 가지 주제에 대해 돌아가면서 이야기하며, 참석한 모든 사람이 한 가지씩 말하는 것이 중요하다.

Keep

It's based on the good points and what you need to keep going forward with the project.

좋았던 점을 기반으로 도출하며, 앞으로 프로젝트를 진행할 때 계속 유지해야 할 사항

Problem

It is derived based on the disappointment and needs to be improved when carrying out the project in the future.

아쉬웠던 점을 기반으로 도출하며, 앞으로 프로젝트를 진행할 때 개선되어야 할 사항

Try

Based on Problem, what to try with next sprint, but based on action items that can be executed.

Problem을 기반으로 다음 스프린트에 적용해 볼 만한 아이템 (실행할 수 있는 액션 아이템 위주로 이야기)

회고를 진행할 때 프로젝트 팀원들이 진솔한 이야기를 가감 없이 할 수 있도록 이끌어내는 것이 중요하다. 20명의 프로젝트 팀원들과 개발 완료 회고를 진행한 적이 있는데, 1시간 30분 동안 모두의 이야기를 들을 수 있는 소중한 경험이었다. 회고를 준비하고, 진행하는 법에 대해서는 다음 포스팅에서 이야기하도록 하겠다.