애자일 방법론과 스크럼, 칸반
애자일 개발 방법론 🤗
애자일 방법론(Agile Methodology)은 어떻게 보면 폭포수 모델보다 우리에게 더 익숙한 용어일 수 있습니다. 현재 많은 회사에서 조직 문화를 애자일하게 전환해 나가고 있으며, 이를 더 잘 활용하기 위해 깊이 연구하고 있습니다. 애자일도 폭포수 모델과 동일하게 소프트웨어 개발 생명 주기를 어떻게 활용할지를 고민하여, 프로젝트를 더 효율적으로 진행해서 높은 품질의 소프트웨어를 개발하기 위해 등장했습니다.
애자일(Agile)의 사전적 의미는 날렵한, 민첩한, 재빠른입니다. 그 의미에 맞게 정해진 계획만 따르기보다는 개발 생명 주기 또는 개발 환경에 따라 그때그때 유연하게 대처해나가는 소프트웨어 개발 방법론입니다.
위 그림처럼 애자일 방법론은 폭포수 모델과 동일하게 소프트웨어 개발 생명 주기를 따라 소프트웨어를 만들어나갑니다. 다만 애자일은 소프트웨어 개발을 생명 주기 한 사이클에 끝내지 않고, 소프트웨어가 완성될 때까지 N회 반복합니다. 애자일의 최우선적 목표는 최대한 빠르게 소프트웨어를 개발해서 고객에게 제공하고, 요구 사항이 있을 때마다 반영해서 반복적으로 수정하고, 지속적으로 제공하는 것입니다. 정리하면 애자일은 작은 생명 주기 사이클을 반복하여 최소 기능만을 가진 제품(MVP: Minimum Viable Product)을 빠르게 만들어 진화시켜 나가는 것입니다.
애자일은 문서 중심이 아닌 소프트웨어. 즉, 코드 그 자체로 보여주는 것입니다.
애자일을 적용한 곳은 정말 많은데, 대표적으로 아래 기업들이 있습니다.
애자일하게 일하기 위한 여러가지 방법론 📝
애자일 개발 방법론은 위에서 소개한 것처럼 반복적인 개발을 통해 잦을 출시를 목표로 합니다. 그리고 이런 애자일을 잘 활용할 수 있도록 도와주기 위한 방법론들이 정말 많습니다. 본문에서는 정말 유명한 방법론이면서, 인기가 많은 스크럼(Scrum)과 칸반(Kanban)에 대해서 소개하겠습니다.
스크럼 (Scrum)
스크럼은 스프린트(Sprint)라고 부르는 업무 주기를 반복하는 애자일 방법론이며, 이때 업무의 기본 단위는 유저 스토리(User Story)입니다. 유저 스토리는 사용자의 요구 사항을 한 문장으로 정리한 것으로, 예를 들어 "무엇 무엇을 위해서, 무엇 무엇을 원한다."와 같은 표현이 담긴 것입니다. 이렇게 유저 스토리가 하나씩 스토리 보드에 추가되고, 스프린트 플래닝 기간을 통해 이들 중에서 백로그(Backlog)를 정합니다. 하나의 스프린트는 보통 2~4주 내외를 기준으로 일정을 잡으며, 백로그를 바탕으로 소프트웨어를 개발해나갑니다. 스프린트 중간에 추가되는 요구 사항은 다음 스프린트의 백로그로 들어가게 되며, 스프린트의 모든 진행 상황은 스크럼 보드를 통해 한 눈에 볼 수 있습니다.
그리고 스프린트 기간 동안에는 매일 약속된 시간에 일일 스크럼 회의(Daily Scrum Meeting)를 진행하여, 작업 목록이 잘 개발되고 있는지, 오늘 할 일은 무엇인지 등을 간단히 체크합니다. 마지막으로 스프린트가 끝나면 회고 시간을 갖게 되는데, 그동안 스프린트의 작업 목록을 개발한 것을 되돌아 보면서 개선점이 있는지 검토해 볼 수 있습니다. 회고에도 여러가지 방법론이 있는데, 그 중 Keep / Problem / Try 세 가지의 관점에서 돌아보는 KPT 회고 방법론을 함께 소개합니다.
회고란 실패했다면 왜 실패했는지 분석하고, 성공했다면 다음에도 성공하기 위해 분석하는 것입니다.
Keep
- 현재 만족하는 부분
- 계속 이어갔으면 하는 부분
Problem
- 불편하다 느끼는 부분
- 개선이 필요하다 생각되는 부분
Try
- Problem의 해결 방안
- 다음 회고 때 판별 가능하고, 바로 실천 가능한 부분
세 가지 관점 모두 중요하지만, KPT 회고 방법론에서 제일 중요한 것은 Try입니다. 회고 중에 Problem이 나왔다면, 그것은 프로젝트 진행에 문제가 있다는 것입니다. 그렇기 때문에 말만 하고 넘어가면 안 되고, 확실히 개선할 수 있도록 Try를 제안해야 합니다. 이는 개인이 아닌 팀 모두가 적극적으로 참여해야 하는 부분입니다. 이렇게 회고를 통해 나온 내용들은 다음 스프린트에 적용됩니다.
이런 이유에서 스크럼을 경험적 관리 기법이라고도 합니다.
칸반 (Kanban)
칸반은 연속적인 업무의 흐름을 보여주는 보드를 이용한 프로젝트 관리 기법입니다. 칸반에서 사용하는 보드를 칸반 보드라 부르는데, 이러한 보드가 있기 때문에 업무가 어떻게 진행되고 있는지 직관적으로 확인할 수 있습니다. 그리고 스프린트 중심이던 스크럼과 달리 칸반은 WIP(Work In Process)라는 것을 중심으로 진행합니다. 또한 언제까지 마무리해야한다 등의 정해진 기간이 없기 때문에, 언제든지 새로운 이슈를 백로그에 쌓을 수 있습니다. 대신 칸반의 각 컬럼마다 WIP Limit(동시에 진행될 수 있는 항목을 제한)을 걸어, WIP에 여유가 있을 때만 카드를 옮겨와 작업할 수 있게끔 합니다. 이런 식으로 하면 병목이 어디서 발생하는지 파악하기 쉽고, WIP 안에 있는 작업에만 집중할 수 있습니다.
이처럼 칸반은 작업 규모가 스크럼에 비해 제한적이지 않으며, 대신 WIP를 중심으로 업무 수용 범위에 제한을 두면서 작업합니다. 그리고 스크럼처럼 역할을 꼭 정할 필요도 없고, 일일 회의도 따로 진행하지 않아 비교적 자유로운 편입니다. 마지막으로 스크럼은 스프린트 기간이 끝나면 스크럼 보드를 초기화하지만, 칸반은 초기화 과정 없이 해당 보드에서 모든 것을 처리합니다.
스크럼 vs 칸반. 어떤 것이 더 좋을까? 🤔
깊게 들어가면 차이가 있지만, 스크럼이나 칸반 둘 다 경험적 관리 기법을 바탕으로 업무를 개선하며 소프트웨어를 릴리즈하는 것에 목표를 두고 있습니다. 그렇기에 이 주제는 사실 정답이 없습니다. 식사를 하는데 숟가락을 쓰는 것이 좋을지, 젓가락을 쓰는 것이 좋을지를 고민하는 것과 같달까요? 본인의 기호에 맞게 혹은 팀이 정한 것을 따라 특정 방법론을 적용하거나, 둘 모두 같이 사용하면 됩니다.
참고 자료 📖
'💻 컴퓨터공학 > 소프트웨어 공학' 카테고리의 다른 글
서로 다른 조직이 연계하여 협력하는 문화. DevOps (0) | 2021.10.11 |
---|---|
폭포수 모델 (Waterfall) (0) | 2021.10.11 |
소프트웨어 공학이 필요한 이유 (0) | 2021.10.10 |
댓글
이 글 공유하기
다른 글
-
서로 다른 조직이 연계하여 협력하는 문화. DevOps
서로 다른 조직이 연계하여 협력하는 문화. DevOps
2021.10.11 -
폭포수 모델 (Waterfall)
폭포수 모델 (Waterfall)
2021.10.11 -
소프트웨어 공학이 필요한 이유
소프트웨어 공학이 필요한 이유
2021.10.10