칸반이란? (Feat. 애자일)

애자일과 칸반

 

최근에 팀 프로젝트로 협업 툴을 다루어 보면서 개발 방법론에 대해 조사해보게 되었습니다.

부끄럽지만 사실 개발 방법론이라고 해봤자 학부 소프트웨어 공학 시간에 주입식으로 집어넣은게 전부였죠.

애자일이란 말도 들어는 봤지만, 깊이 있게/실전으로 찾아본 적은 없었습니다.

그러다가 애자일을 실현한 도구인 칸반을 먼저 접하게 되었죠.

 

Github Project

제 Github Project 입니다. task들이 여러 개의 파트로 나뉘어져 있죠?

Github Project는 task를 Issue의 개념으로 넣어, 칸반 보드의 역할을 할 수 있습니다.

(Github Project 사용법은 차후에 자세히 포스팅하도록 하겠습니다)

 

계속 언급되는 애자일, 칸반이 뭔지 간단히 알아보면

애자일은 전통적인 개발 방법론인 워터폴(폭포수형 모델)에 대비되어 등장하였습니다.

소프트웨어 공학시간에 배운 폭포수형 모델의 경우 기획,개발,테스트,출시(그 사이에 구현, 설계 등등이 들어가있긴 합니다만)의 순차적인 단계를 밟는 방식이죠.

하지만 대부분이 부정적인(?) 얘기였던 소프트웨어 공학 수업시간을 되돌이켜 보면, 워터폴은 항상 고객의 클라이언트를 100% 충족하는 경우가 없다는 단점이 있더랬죠. 모든 작업이 일련의 과정을 따라 가기 때문에, 도중에 발생하는 문제(Hotfix)와 예측하지 못한 이슈에 대응하지 못하는 점, 또한 프로젝트에 대한 기획이 어긋났을 경우 되돌이키기 힘들죠.

 

따라서 이러한 이러한 결점들이 모여 코드 품질은 떨어지고, 요구사항이 모두 충족되지 않은(100% 구현되지 않은) 결과물이 나오며 예측 정확도도 떨어지게 되죠. 이제 애자일이 나오게 된 배경입니다.

 

 

칸반은 애자일 방법론을 실행하는 방법 중 하나인데요.

칸반 보드

이슈 하나하나를 A부터 순서를 매겨봅시다. 이 이슈는 프로젝트에서 구현해야 할 목표, 혹은 중간에 발생한 Hotfix, 고객의 요구사항을 만족시키기 위한 방안 하나하나를 의미할 수 있겠죠.

 

칸반은 일본어로 '간판'이라는 뜻입니다. 우선 프로젝트의 과정을 프로세스로 나눕니다.

여기서는 포르투갈어로 표시되어있습니다만.. 

과제목록 -> 우선순위 -> 개발(진행중/완료) -> 릴리즈 -> 라이브

 

이런 형식을 주로 띈다고 할 수 있습니다.

 

이러한 칸반 형식을 굳이 사용하는 이유가 무엇일까요?

프로젝트에서 개발팀이 주어진 이슈를 들어오는 족족 처리하여 보내준다면 좋겠습니다만, 대부분

이슈가 과제목록에 쌓이게 되기 일쑤입니다.

칸반에서는 이러한 이슈를 언제까지 해야한다! 라는 정해진 기간은 없습니다만, 우선순위를 정하고 급한 순으로 progress에 넣습니다.

즉, 과제 목록이 하나의 큐로 순서대로 들어가서 처리되는 것이죠.

칸반의 핵심은 대신 이 progress에 넣을 수 있는 작업의 수, WIP(Work In Progress)에 제한을 두는것이 핵심입니다.

팀의 특성을 고려하여 WIP의 수를 정하고, 그 이상의 작업을 동시에 하는 것을 제한하는 겁니다.

 

따라서 칸반의 장점은 다음과 같이 정리할 수 있습니다.

1. 개발자에게 데드라인이 정해져 있지 않고, 압박이 적어 부담을 덜 수 있게 하고, 너무나도 많은 이슈가 동시에 들어와 혼란을 주는 경우를 차단할 수 있습니다.

2. 칸반 보드를 보면 어떠한 작업이 누구에 의해, 어느정도 진행졌는지 시각적으로 볼 수 있습니다.

3. 다음 작업을 위해 무엇이 필요하며, 현재 막히는 구간이 어디이기에 프로젝트가 더뎌지는 것인지 파악할 수 있습니다.

4. 여태까지 해온 작업과 해야 할 작업이 뚜렷하게 나뉘어있어, 개선 방안을 모색하기 편리합니다.

5. Hotfix(예상치 못한 문제)를 다루기 수월합니다. Hotfix도 하나의 이슈카드로 처리되어 우선순위를 고려하여 프로젝트가 끝나기 위해 처리해야할 것으로 남겨놓을 수 있기 때문이죠.

 

중요한 점은 이러한 칸반을 무작위로 어느 경우에나 적용할 게 아니라는 것입니다. 모든 개발방법론은 팀의 특성을 고려하여 결정되어야 합니다. 애자일-칸반이 무조건 옳다! 라고 할 수 없는 것입니다.

칸반이 개발자의 부담을 덜어주고, 방어적인 태도를 줄여 협동심을 향상할 수 있다는 장점이 있으나, 데드라인이 없다는 특성 상 프로젝트의 종료일이 정해져 있지 않고, 지속적인 업무/작은 팀 단위인 경우에 칸반이 어울린다고 할 수 있겠습니다.