<애자일과 워터폴, 그리고 애자일의 친구들 스크럼과 칸반>

<애자일과 워터폴, 그리고 애자일의 친구들 스크럼과 칸반>

여기서는 방법론의 사전적 정의가 아닌, 개념을 말로 풀어 설명하는 데 의의를 둡니다.
서로가 비슷하여 헷갈리는 애자일, 스크럼, 칸반의 관계를 먼저 정리할 필요가 있습니다.
애자일은 개발 방법론이고, 스크럼과 칸반은 애자일이라는 방법론을 실현하는 도구의 역할을 합니다.
정리 해 보자면

• 애자일 VS 워터폴
• 애자일을 위한 도구들(스크럼, 칸반, XP …etc)
  인거죠.
  애자일은 워터폴 방법론과 대비되어 등장하게 된 개발방법론 입니다.
  워터폴은 전통적인 개발 방법론으로,
  요구분석부터 기획, 개발, 테스트, 출시까지를 순차적으로 진행하여
  마치 폭포가 떨어지는 식으로 순차적인 단계를 밟는다고 하여 폭포수 방식이라고 불리기도 하죠.
  (좀 더 정확한 사전적 정의는 인터넷을 찾아보면 잘 나와 있습니다.)
  그럼,
  워터폴 방식으로 개발을 진행하다 왜 애자일이라는 녀석이 튀어 나왔는지 고민해 볼까요?
  단적으로 말하자면

• 워터폴 방식의 요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하는 경우가 거의 없다는 점
• 개발 단계에서 개발을 하더라도 그것도 역시 예측할 수 없는 이슈들이 터져나온다는 점들이 애자일의 등장배경이라고 할 수 있습니다.
  아무튼
  이러한 이슈들이 처리되지 않은 채로 엉키게 되면 코드 품질은 떨어지고 요구사항은 모두 충족되지 않은 상태의 만족스럽지 않은 결과물이 나오게 됩니다.
  (그러면서도 모두가 힘들죠)

그래서 애자일이 등장합니다.
애자일은 말 그대로 기민하고 민첩하게 요구사항들을 충족, 개발한다.
라는 정도로 이해하면 될 것 같아요.
요구분석, 기획등 전체 프로젝트에 대한 모든 문서를 만들고, 해당 작업들이 모두 끝난 이후 개발에 들어가던 예전 워터폴 방식과는 달리,
애자일은 프로토타입을 기반으로 합니다.
즉, 문서가 아닌 코드로 보여주는 거죠.
좀 더 작은 단위로 개발을 해서, 해당 부분을 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈처리에 대한 기민한 대응을 하자는 거죠.

그럼 애자일을 잘 활용하도록 도와주는 도구들도 중요하겠죠.
여러 도구들이 있지만, 그 중 가장 유명한 2가지를 소개하겠습니다.

바로,
스크럼과 칸반
설명에 들어가기 전에 기억하셔야 할 단어를 알려드릴게요.

스크럼은 “스프린트 기반"
칸반은 “WIP”
스크럼은 스프린트를 기반으로 애자일 방법론을 실행하고,
칸반은 Work In Process를 제한하여 애자일 방법론을 실행합니다.
좀 더 자세히 들어가 볼게요.

스크럼은
스프린트 작업 단위를 부여하고 (스프린트는 보통 2주를 기준으로 하고, 팀의 특성에 맞춰 줄이거나 늘릴 수 있습니다.)
한 스프린트가 시작하는 월요일날 하루에 걸쳐 해당 스프린트 기간 동안 할 작업들을 추산하는 “플래닝"을 진행합니다.또한 해당 스프린트가 끝나는 주의 금요일에는 그동안 플래닝을 통해 진행했던 작업들에 대한 “회고"를 진행합니다.
플래닝은 PO(product owner), 스크럼마스터, 개발자 들이 모여 플래닝 포커를 통해 진행합니다.
(…머지? 이 모르는 단어들..)
PO는 고객을 대변하는 비즈니스 담당자 입니다.
비즈니스의 입장에서 필요한 기능들을 말하는 역할을 담당하죠.
Scrum Master는 개발의 측면에서 PO가 말한 비즈니스 기능들을 개발 가능한 단위로 쪼개고 조율하는 역할을 합니다.
여기서 핵심은 개발 가능한 단위의 분리는 최대한 작은 단위로 쪼개는 것이 좋다는 것입니다.
예를 들면,
관리자 페이지 개발 (bad)
관리자 페이지 내 로그인 부분 개발 (good)
이렇게 쪼개진 각 카드들을 가지고 개발자들이 삼삼오오 모여 앉아 플래닝 포커를 시작합니다. 한 카드에 대해 개발 시간이 얼마나 걸릴 지를 추정하는 작업입니다.
날짜 단위가 적힌 포커카드를 모두 집어 듭니다. (0.5day, 1day, 2day, 3day, 4day, 5day, infinite까지 존재하며, 팀의 특징에 따라 hour로 바뀌기도, point로 바뀌기도 합니다.)
그리고 이슈카드가 등장하죠.(위에서 작성했던 관리자 페이지 내 로그인 부분 개발)
하나, 둘, 셋을 외치고 동시에 모든 개발자들이 포커 게임을 하듯, 남들이 보지 못하게 카드를 냅니다. 본인이 해당 이슈카드를 맡았다고 생각했을 때 걸릴 추정 시간을 포커카드로 제시하는 거죠.(어떤 카드를 누가 맡을 지는 정하지 않습니다)
관리자 페이지 내 로그인 부분 개발 이라는 이슈카드에 대해서,
철수는 3day 순이는 1day 영자는 5day라고 제안했네요.
그럼 가장 길게 추정한 영자와 가장 짧게 추정한 순이가 그 자리에서 바로 본인이 왜 그렇게 추정했는지 사람들을 상대로 설명을 합니다.
그리고 나서 다시 플래닝 포커를 하는거죠.
철수 2day 순이 2.5day 영자 3day
간격이 줄어들긴 했지만 또 일치 하지 않는군요. 그럼 가장 짧은 철수와 가장 긴 영자가 또 이야기를 하죠.
이런 작업이 모든 개발자가 만장일치가 나올 때 까지 진행합니다.
핵심은 모든 이슈카드에 대해 만장일치 입니다.
이렇다 보니 한 스프린트 당 해야 하는 모든 이슈카드에 대해 플래닝을 하는 작업은 생각보다 시간이 많이 들고 꽤 어려운 작업입니다.
그럼에도 불구하고, 꼭 해야하는 가치가 있는 작업이지요.
이렇게 플래닝을 통해 시간이 추정된 모든 이슈카드들을 가지고 개발자들은 한 스프린트 동안 개발을 진행합니다.
카드를 끌어다 in progress 부분에 옮겨두고 작업을 진행하죠.
어떤 카드를 선택할지는 본인 마음입니다. 먼저 선택하는 사람이 본인이 더 하고 싶은 카드를 들고가서 시작하면 됩니다.
이렇게 스프린트를 진행한 후 스프린트 마지막 주의 금요일날 지금까지 스프린트 기간 동안 진행한 작업들을 플래닝 내용을 가지고 회고를 합니다.
잘한 점, 부족했던 점, 아쉬웠던 점, 더 나아졌으면 하는 점 등등
많은 의견들이 오가는 자리입니다.
다과와 커피를 함께하며 스프린트를 진행하는 동안 고생했던 것을 공유하는 무겁지 않은 팀웍다지기 입니다.

칸반은 WIP 제한이 핵심입니다.
매일 오전 데일리 미팅을 진행 해 오늘 할 일을 공유하고 어제 한 일을 간단히 리뷰합니다(15분 정도)
칸반과 스크럼의 가장 두드러지는 차이는 플래닝 포커를 통한 시간 추정 작업이 없다는 겁니다.
프로젝트 기준으로 조금은 긴 작업 단위를 정하고(이 작업단위는 한달이면 한달, 2주면 2주 팀마다 합의를 통해 정기적인 날을 정해둡니다)
프로젝트 첫날 플래닝을 시작합니다.
여기서의 플래닝은 이슈카드를 쪼개는 것까지는 동일하지만, 시간을 추정하지 않습니다.
그 대신 In Progress바에 넣을 수 있는 이슈카드의 갯수가 제한됩니다.(이는 팀의 특성을 고려하여 갯수를 제한하고 WIP에 여유가 있을 시에만 백로그에서 카드를 옮겨올 수 있습니다.)
마지막으로,
HotFix라는 이슈를 다루는 관점에 대한 스크럼과 칸반의 차이입니다.
HotFix란 말 그대로, 예측되지 않았던 요청입니다.
운영되고 있는 서비스라면 고객이 마주친 버그 일 수도 있고, PO가 플래닝 당시에는 미처 정의하지 못했던 급한 business requirement 일 수 있습니다.
스크럼에서는 HotFix는 해당 스프린트에 “절.대.”넣지 않습니다.
스프린트 진행 중 발생하는 모든 HotFix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 업무가 됩니다.(운영중인 서비스라면 개발자가 돌아가며 sustainment업무를 맡기도 합니다)
칸반에서는 HotFix 또한 바로 프로젝트 backlog에 쌓습니다. 쌓여진 Hotfix를 바로바로 처리할 수 있죠. 해당 프로젝트를 끝내기 위해 처리해야 할 이슈카드로 동일하게 취급합니다. 이는 시간추정을 하지 않기 때문에 가능한 일입니다.