이 글은 Atlassian의 『Learn scrum with Jira Software』를 바탕으로 재구성한 것임을 밝힙니다.
여러분은 혹시 애자일 방법론(Agile methodologies) 에 대해서 들어보신 적이 있으신가요? 사실 저는 몇 달 전까지만 해도 잘 모르고 있었습니다. 사실 애자일이란 단어는 어디선가 들어본 적은 있었습니다. 다만 그 지식의 깊이 수준이 ‘개발을 빠르게 할 수 있는 방법’으로만 알 정도로 얕았습니다.
제가 이렇게 애자일에 대해서 추상적인 개념만 가지고 있었던 이유는 뭘까요? 그건 아마도 이러한 개발 매커니즘 자체에 대한 연구와 방법론이 필요할 만큼 큰 프로젝트를 해 본 적이 없었기 때문입니다. 대학교를 다닐 때는 기껏해야 한 학기 정도의 짧은 기간동안 혼자, 아니면 두 명이서 과제나 프로젝트를 하게 되는 게 전부였습니다. 게다가 새로운 기술의 도입도 아니고, 개발하는 방법의 매커니즘을 바꾼다고 해서 효율성을 크게 향상시킬 수 있다는 이야기가 학생의 입장에서는 잘 와닿지 않았습니다.
하지만 회사는 학교와 달랐습니다. 회사에서는 제가 경험한 적 없었던 거대한 프로젝트를 많은 사람들이 참여했습니다. 기획과 디자인, 마케팅 등 다양한 팀의 사람들과도 효율적인 커뮤니케이션이 필요했습니다. 물론 팀 내부에서도 효율적인 프로세스가 필요했죠. 마침 소속되어 있는 개발 팀에서 애자일, 특히 그 중에서도 스크럼(Scrum) 을 도입하게 되어 이번 글을 작성하게 되었습니다.
처음 만나는 애자일 방법론
위키피디아에서는 애자일 방법론의 정의를 이렇게 소개하고 있습니다.
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
한 문장에 써 있어서 내용이 조금 길지만, 애자일 소프트웨어 개발은 Self-organizing(외부의 누군가에 의해 감독받는 것이 아니라 팀원 스스로가 효율적인 업무 분담을 담당하는)팀이나 Cross-functional(서로 다른 기능적 전문성을 지닌 사람들이 공통의 목표를 향해 노력하는)팀이 고객이나 최종 사용자 사이에서 협업의 노력을 통해 요구사항과 해결책을 발전시키는 소프트웨어 개발 방식 정도로 번역할 수 있겠습니다.
정의를 처음 접하시는 분들은 조금 의아하실 수도 있습니다. 왜냐하면 *“소프트웨어를 개발할 때, 팀 단위로 협업하는 건 당연한 것 아닌가?”*라고 생각하실 수도 있거든요. 여기서 잠깐만요! 여러분이 평소에 팀 단위로 협업 할 때의 모습을 한 번 상상해봅시다.
폭포수 모델에서는 하나의 단계가 완전히 끝난 이후에야, 다음 단계의 작업이 진행됩니다.
기획이 끝난 후 디자인이 시작되고, 디자인이 끝난 후 개발이 진행되는 것처럼 개발 프로세스가 완전히 순차적으로 진행되고 있나요? 이러한 순차적인 개발 방법을 폭포수 모델(Waterfall Model) 이라고 부릅니다. 폭포수 모델의 특징으로는 작업의 진행이 폭포수처럼 위에서부터 아래로 흘러내리는 것처럼, 하나의 단계가 완전히 끝날 때까지 다음 단계를 진행하지 않아야 합니다. 이는 전통적인 개발 방법이면서 동시에 이해하기 쉽고 직관적이죠.
하지만 폭포수 모델은 프로젝트의 크기가 커질수록 많은 사전 준비를 필요로 하고, 시간이 오래 걸리며, 요구 사항의 변화에 유연하게 대처할 수 없다는 등의 단점들이 나오게 됩니다. 이런 폭포수 모델의 한계점을 극복하고자, 애자일 방법론이 등장하였습니다.
많은 회사에서 애자일 방법론을 필요로 하면서, 이를 도와주는 소프트웨어 툴도 많이 나오게 되었는데 자주 쓰이는 것으로는 Jira나 Trello, Redmine 등이 있습니다.
스크럼이란?
애자일은 기존의 폭포수 모델의 단점을 극복하고자 만들어진 여러가지 방법론들을 통틀어 일컫는 단어입니다. 즉 애자일에도 여러가지 종류가 있다는 이야기죠. 따라서 우리는 여러 애자일 모델 중에서 특정한 방법론을 선택해 사용해야 합니다.
일반적으로 익스트림 프로그래밍, 스크럼(Scrum), 칸반(Kanban) 등 여러가지 종류가 있는데, 우리는 그 중에서도 가장 대중적인 스크럼 방법론을 선택해보겠습니다. 여기서 애자일 방법론이 등장한 배경을 다시 한 번 상기시켜봅시다. 폭포수 모델이 변화에 유연하지 않은 이유는 바로 기획 단계에서 예측할 수 없었던 문제들이 나타나기 때문입니다. 아무리 꼼꼼하고 철저하게 기획을 세운다고 해도, 앞으로 나올 수 있는 모든 복잡한 경우의 수에 대해서 예측할 수가 없기 때문에 최초의 기획은 점점 일그러지게 됩니다. 그렇다면 프로젝트가 요구 사항의 변화에 따라 유연하게 대처하려면 어떻게 해야 할까요?
우리는 처음부터 완벽한 기획은 나올 수 없다는 것을 스스로 인정해야 합니다. 따라서, 기획에서 미처 생각하지 못했거나 잘못된 기획으로 발생할 수 있는 문제들을 짧은 기간을 주기로 자주 되짚어본다 는 것입니다. 여기서 스크럼의 중요한 개념이 나옵니다. 바로 협업을 일정한 단위로 쪼개 생각한다 는 것입니다.
스크럼에서는 일정한 기준으로 단계를 나누어 순환하는 작업을 지향합니다.
여기에서 일정한 단위는 일정한 주기를 바탕으로 반복되는 개발 주기 를 의미하며, 스크럼에서는 이것을 스프린트(Sprint) 라고 부릅니다.
그럼, 이제 본격적으로 스크럼을 어떻게 활용하는지 살펴보겠습니다.
스크럼 프로젝트 이해하기
1. 백로그에 이슈 만들기
유저 스토리, 태스크, 버그는 스프린트 위를 뛰어다니는 배우들입니다.
우선 프로젝트를 하면서 여러분들이 해결해야 할 이슈들의 목록을 정리합니다. 이슈들은 일반적으로 태스크(Task), 버그(Bug), 유저 스토리(User story) 의 세 가지 카테고리로 구분할 수 있습니다.
- 유저 스토리 : 최종 사용자의 입장에서 무엇이 필요하고, 그것이 왜 필요한지를 설명합니다. 일반적으로 유저 스토리는 ”사용자 역할으로서, 효과를 받기 위해 목표를 원합니다“의 포맷으로 씁니다. 예를 들자면, ”최종 고객으로서, 프로필 사진을 변경하기 위해 수정 버튼이 있었으면 좋겠습니다.” 처럼요.
유저 스토리는 제품 소유자(일반적으로 경영진이나 팀 리더)가 전체적인 요구사항을 정리한 후, 이를 바탕으로 프로젝트 구성원들이 더 자세한 요구 사항을 함께 결정합니다. 이러한 세분화된 작업들은 다가올 스프린트에 대한 구현 항목을 정의하는 데 도움이 됩니다.
이 때, 생성된 이슈들은 밀린 일 들을 모아두는 백로그(Backlog) 에 저장됩니다. 백로그에 이슈들이 쌓이면, 이슈들을 해결하기 위해 새 스프린트를 시작해야 합니다.
2. 새 스프린트를 시작을 위한 미팅하기
*스프린트는 무대, 백 로그는 무대 뒤 편에 있는 대기실입니다. 스프린트를 시작하기에 앞서, 이번 스프린트에 해결해야 할 이슈들이 백로그에 있다면 스프린트에 올립니다.*
새 스프린트를 시작하기 전에, 백로그에 쌓인 각각의 이슈들에 대해 스토리 포인트(Story Point) 를 예측해야 합니다.
- 스토리 포인트 : 일반적인 소프트웨어 개발에서는 개발에 소요되는 시간을 일, 주, 개월과 같은 시간 단위로 예측합니다. 하지만 애자일 방법론에서는 이 단위들을 스토리 포인트라는 추상적인 개념으로 변환합니다. 예를 들어, 어떤 태스크는 해결하는 데 6 스토리 포인트가 걸리겠다 이런 식으로 말이죠.
스토리 포인트를 예측할 때에는 몇 가지 참고해야 할 사항들이 있습니다. 먼저, 이슈의 난이도와 걸리는 시간, 복잡도 등을 종합적으로 고려합니다. 그리고 피보나치 수열 또는 2의 제곱 수열과 같은 일정한 규칙을 가진 수열을 따르는 것이 일반적입니다. 저희 팀의 경우에는 이슈의 난이도를 고려해 30분동안 해결할 수 있는 경우를 1 스토리 포인트로 정의해 사용했습니다.
이런 작업들이 오히려 직관성을 해친다고 생각할 수도 있습니다. 하지만 이슈에 소요되는 시간을 추상화하는 것은 어려운 작업들에 대한 결정을 쉽게 내릴 수 있도록 도와줍니다.
그럼 이 스토리 포인트는 대체 누가 정하는 걸까요? 이 때 플래닝 포커(Planning poker) 라는 방법을 고려할 수 있습니다. 계획을 내리기 위한 포커라는 뜻처럼, 포커 게임과 유사한 방식으로 각각의 이슈에 대한 스토리 포인트를 정할 수 있습니다. 간단히 요약한 방법은 다음과 같습니다.
- 모든 개발 팀 구성원들이 미팅에 참석합니다.
- 이슈를 등록한 사람으로부터, 백로그에 있는 각각의 이슈들에 대해 개요와 설명을 듣고 해당 이슈를 담당할 사람을 정합니다.
- 개발 팀 구성원들은 해당 이슈에 대한 스토리 포인트를 예측하고, 각자의 의견을 동시에 공개합니다. 동시에 공개하는 이유는 먼저 의견을 말한 사람이 다른 사람들의 예측에 영향을 끼칠 수 있기 때문입니다.
- 가장 높고 낮은 스토리 포인트를 제시한 사람들은 왜 그렇게 생각했는지를 설명하고, 모든 구성원들이 동의할 수 있는 스토리 포인트가 나올 때까지 합의 과정을 거칩니다.
모든 이슈들에 대해 스토리 포인트가 정해지면 스프린트의 기간을 설정합니다. 기간은 모든 스토리 포인트의 합 / 팀에서 하루에 소모할 수 있는 스토리 포인트 양 을 고려합니다. 예를 들어, 다섯 명으로 구성된 개발 팀에서 한 명의 개발자가 하루에 8 스토리를 담당할 수 있고, 모든 이슈의 스토리 포인트의 합이 240일 때는 240 / (8 * 5) = 6 일의 스프린트 기간을 둡니다.
3. 스프린트 시작하기
스프린트가 시작되면 각 이슈들을 진행 상황에 따라 해야할 일(To do), 진행 중(In progress), 확인 필요(To check), 완료(Done)로 이동시킵니다.
스프린트가 시작되면, 이슈들을 해야할 일 목록으로 이동시킵니다. 이제 남은 일은 스프린트 기간동안 각자 맡은 이슈들을 열심히 하기만 하면 됩니다!
이 때 개발 팀은 매일 아침마다 간단한 미팅을 가집니다. 미팅에서는 각자 어제 무엇을 했는지, 오늘 무엇을 할 건지, 어떤 어려움을 겪고 있는지 를 설명합니다. 이 미팅을 통해, 스프린트의 전체 진행상황을 파악하면서 어려움을 겪고 있는 팀원이 누구인지 확인할 수 있습니다.
그리고 자신이 담당한 이슈들은 현재 상태에 따라 해야할 일, 진행 중, 확인 필요, 완료 리스트로 이동시킵니다.
4. 스프린트 종료 및 반복하기
스프린트 기간이 끝나면 회고 미팅을 가집니다. 이후 필요에 따라 추가된 새로운 이슈들로 새 스프린트를 만든 뒤 반복합니다.
스프린트 기간이 끝날 때는 지난 스프린트에 대해 회고하는 미팅을 가집니다. 여기에서는 다음과 같은 사항들을 고려해야 합니다.
- 스프린트 기간동안 모든 이슈들을 해결했는가? : 스프린트 기간 내에 정말 불가피한 경우를 제외하고는 모든 이슈들을 해결하는 것을 전제로 합니다.
- 스프린트 기간 도중에 이슈가 추가되거나 제거되지는 않았는가? : 스프린트 중간에 이슈의 변동은 스토리 포인트 예측을 무의미하게 만듭니다.
- 예측한 스프린트 기간이 너무 길거나 짧지는 않았는가? : 이슈의 난이도에 비해 너무 짧거나 긴 스토리 포인트를 주었다면 다음부터는 더 정확한 예측을 해야합니다.
- 만약 그렇다면, 왜 그랬는가? : 각각의 이유를 분석해 스프린트의 정확도를 높이도록 합니다.
이후에는 2번으로 다시 돌아가 같은 방법으로 새로운 스프린트를 시작합니다.
애자일은 무조건 좋다?
Jira를 이용해 스프린트 관리를 하는 모습
이처럼 애자일에서는 짧은 개발 주기를 이용해 유연한 개발을 하자고 강조합니다. 새로운 개발 방식에 흥미를 느끼시는 분들도 많으실 테고요. 저 역시도 애자일 방법론을 처음 접했을 때는, 기존의 낡고 오래된 개발 방식을 벗어난 혁신적이고 만능적인 방법론이라고 생각했습니다.
하지만 직접 경험해보니, 애자일 방법론이 폭포수 모델보다 절대적으로 뛰어나다고는 할 수 없었습니다. 폭포수 모델의 단점을 그대로 갖고 있는 경우도 있었고, 오히려 더 나쁜 경우도 있었습니다. 제가 경험한 단점들은 다음과 같습니다.
- 급한 이슈에 대해서 오히려 유연하지 않음 : 일단 새 스프린트가 시작되고 나면, 스프린트에 새로운 이슈가 추가되거나 삭제되는 것은 원칙적으로 없어야 합니다. 하지만 현실은 그렇게 이상적이지 않아서, 갑작스러운 버그처럼 생각지도 못한 긴급한 이슈가 생기기 마련입니다. 심지어 갑자기 원래 계획에도 없었던 새로운 기능을 추가해달라는 외부의 압박이 들어오기도 합니다.
- 현실과 동떨어진 수동적인 해결책 : 모든 팀원들이 합의 하에 스토리 포인트와 스프린트 기간을 예측했다 하더라도, 실제로 업무를 하다보면 다양한 원인으로 인해 예측과 빗나가는 경우가 많습니다. 하지만 애자일이 말하는 해결책은 회고 미팅을 통해 다음 번에 더 잘 예측하세요!, *다음 번에 더 열심히 하세요!*라는 것이 전부입니다. 정확하게 예측하지 못한다면, 오히려 낭비되는 자원이 더 많습니다.
- 애자일 준비에 많은 시간 소요 : 애자일 방법론 그 자체를 유지하는데에 생각보다 시간을 많이 잡아먹습니다. 스프린트 미팅에서는 모든 이슈들에 대해 모든 팀원들이 의견을 조율하고 합의를 거치는 것을 전제로 합니다. 일반적으로 새 스프린트에는 20~30개 정도의 이슈가 있었는데, 스프린트 미팅에 대략 3시간 정도를 썼습니다. 지속적으로 일정한 시간을 소모한다는 점은 오히려 단점이 됩니다.
- 커질수록 나빠지는 효율 : 모든 팀원들이 함께 커뮤니케이션을 하는 특성 상 인원이 많아지면 효율이 떨어집니다. 5명 전후의 팀원이 가장 이상적이며, 10명을 넘어가면 오히려 모든 팀원들의 의견을 듣는 것이 비효율적일 수도 있습니다.
많은 기업에서 우리는 애자일을 쓰고 있다 고 주장하지만, 시간이 흐를수록 흐지부지 되는 것은 애자일에 대한 깊은 고려가 없었기 때문일 것입니다. 왜냐하면 애자일은 이상적인 경우에 한해서만 높은 효율을 달성할 수 있기 때문입니다. 아무리 개발 팀에서 애자일 방법론을 잘 따른다 하더라도, 외부의 영향에 따라 효율이 반감될 수 있습니다. 따라서 애자일을 도입할 계획이 있으신 분들은 개발 팀 뿐만 아니라, 영향을 받을 수 있는 외부적 요인도 충분히 고려해 도입 여부를 결정하는 것이 좋을 것 같습니다.
물론 가장 좋은 경우는 개발 팀 내부과 외부의 모든 사람들이 애자일 방법론을 이해하고, 존중해주는 문화가 있는 경우이지만 말이죠.
