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

---

 * 출처

 : https://medium.com/@unini/애자일과-워터폴-그리고-애자일의-친구들-스크럼과-칸반-d53c23aadd57

 : http://blog.rightbrain.co.kr/?p=5810

 : https://openbee.kr/434

---

여기서는 방법론의 사전적 정의가 아닌, 개념을 말로 풀어 설명하는 데 의의를 둡니다.

서로가 비슷하여 헷갈리는 애자일, 스크럼, 칸반의 관계를 먼저 정리할 필요가 있습니다.
애자일은 개발 방법론이고, 스크럼과 칸반은 애자일이라는 방법론을 실현하는 도구의 역할을 합니다.

정리 해 보자면
- 애자일 VS 워터폴
- 애자일을 위한 도구들(스크럼, 칸반, XP …etc)
인거죠.

애자일은 워터폴 방법론과 대비되어 등장하게 된 개발방법론 입니다.

워터폴은 전통적인 개발 방법론으로,
요구분석부터 기획, 개발, 테스트, 출시까지를 순차적으로 진행하여
마치 폭포가 떨어지는 식으로 순차적인 단계를 밟는다고 하여 폭포수 방식이라고 불리기도 하죠.
(좀 더 정확한 사전적 정의는 인터넷을 찾아보면 잘 나와 있습니다.)

그럼,
워터폴 방식으로 개발을 진행하다 왜 애자일이라는 녀석이 튀어 나왔는지 고민해 볼까요?

단적으로 말하자면
* 워터폴 방식의 요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하는 경우가 거의 없다는 점 (프로젝트 전체를 대상으로 플래닝을 합니다 -> 플젝 전체에 대한 기획문서가 나온 후 개발에 들어가는 등의 진행방식이죠)
* 개발 단계에서 개발을 하더라도 그것도 역시 예측할 수 없는 이슈들이 터져나온다는 점들이 애자일의 등장배경이라고 할 수 있습니다.

아무튼
이러한 이슈들이 처리되지 않은 채로 엉키게 되면

• 코드 품질은 떨어지고
• 요구사항은 모두 충족되지 않은 상태의
• 만족스럽지 않은 결과물이 나오게 되며
• 시간은 자꾸미뤄지고 종료 예측 정확도가 떨어지죠
• (그러면서도 모두가 힘들죠)
• 
  
• 
  
• 
• 고객이 생각했던 의자와 개발단계를 거치며 변하는 의자(???)
  

그래서 애자일이 등장합니다.

애자일은 말 그대로 기민하고 민첩하게 요구사항들을 충족, 개발한다.
라는 정도로 이해하면 될 것 같아요.

요구분석, 기획등 전체 프로젝트에 대한 모든 문서를 만들고, 해당 작업들이 모두 끝난 이후 개발에 들어가던 예전 워터폴 방식과는 달리,
애자일은 기능단위의 프로토타입을 기반으로 합니다.

즉, 문서가 아닌 코드로 보여주는 거죠.

좀 더 작은 단위로 개발을 해서, 해당 부분을 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈처리에 대한 기민한 대응을 하자는 거죠.

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

바로,
스크럼과 칸반

설명에 들어가기 전에 기억하셔야 할 단어를 알려드릴게요.
스크럼은 “스프린트 기반"
칸반은 “WIP”

스크럼은 스프린트를 기반으로 애자일 방법론을 실행하고, 
칸반은 Work In Process를 제한하여 애자일 방법론을 실행합니다.

좀 더 자세히 들어가 볼게요.

스크럼은
스프린트 작업 단위를 부여하고 (스프린트는 보통 2주를 기준으로 하고, 팀의 특성에 맞춰 줄이거나 늘릴 수 있습니다.)

한 스프린트가 시작하는 월요일날 하루에 걸쳐 해당 스프린트 기간 동안 작업할 수 있는 개발자 개개인의 시간들을 모두 합쳐 총 작업시간을 책정하고, 스프린트 동안 할 작업들을 추산하는 “플래닝"을 진행합니다.또한 해당 스프린트가 끝나는 주의 금요일에는 그동안 플래닝을 통해 진행했던 작업들에 대한 “회고"를 진행합니다.

플래닝은 PO(product owner), 스크럼마스터, 개발자 들이 모여 플래닝 포커를 통해 진행합니다.

(…머지? 이 모르는 단어들..)

PO는 고객을 대변하는 비즈니스 담당자 입니다.
비즈니스의 입장에서 필요한 기능들을 말하는 역할을 담당하죠.

Scrum Master는 개발의 측면에서 PO가 말한 비즈니스 기능들을 개발 가능한 단위로 쪼개고 조율하는 역할을 합니다.
여기서 핵심은 개발 가능한 단위의 분리는 최대한 작은 단위로 쪼개는 것이 좋다는 것입니다. (스크럼마스터는 개발자들 중 돌아가면서 하기도 합니다)

예를 들면,
관리자 페이지 개발 (bad)
관리자 페이지 내 회원가입기능 중 이메일 인증 부분 개발(good)

이렇게 쪼개진 각 카드들을 가지고 개발자들이 삼삼오오 모여 앉아 플래닝 포커를 시작합니다. 한 카드에 대해 개발 시간이 얼마나 걸릴 지를 추정하는 작업입니다.

날짜 단위가 적힌 포커카드를 모두 집어 듭니다. (0.5hour, 1h, 2h, 3h, 4h, 5h, infinite까지 존재하며, 팀의 특징에 따라 day로 바뀌기도, point로 바뀌기도 합니다.)
그리고 이슈카드가 등장하죠.(위에서 작성했던 관리자 페이지 내 회원가입기능 중 이메일 인증 부분 개발)

하나, 둘, 셋을 외치고 동시에 모든 “개발자”들이 포커 게임을 하듯, 남들이 보지 못하게 카드를 냅니다. 해당 기능을 구현하는 데 필요한 고려사항들을 각자 생각하고, 본인이 해당 이슈카드를 맡았다고 생각했을 때 걸릴 추정 시간을 포커카드로 제시하는 거죠.(어떤 카드를 누가 맡을 지는 정하지 않습니다)

관리자 페이지 내 로그인 부분 개발 이라는 이슈카드에 대해서, 
철수는 3h 순이는 1h 영자는 5h라고 제안했네요.
그럼 가장 길게 추정한 영자와 가장 짧게 추정한 순이가 그 자리에서 바로 본인이 왜 그렇게 추정했는지 사람들을 상대로 설명을 합니다.

그리고 나서 다시 플래닝 포커를 하는거죠.
철수 2h 순이 2.5h 영자 3h
간격이 줄어들긴 했지만 또 일치 하지 않는군요. 그럼 가장 짧은 철수와 가장 긴 영자가 또 이야기를 하죠.

이런 작업이 모든 개발자가 만장일치가 나올 때 까지 진행합니다. 
핵심은 모든 이슈카드에 대해 만장일치 입니다.
이렇다 보니 한 스프린트 당 해야 하는 모든 이슈카드에 대해 플래닝을 하는 작업은 생각보다 시간이 많이 들고 꽤 어려운 작업입니다.
그럼에도 불구하고, 꼭 해야하는 가치가 있는 작업이지요.
이렇게 플래닝을 통해 시간이 추정된 모든 이슈카드들을 가지고 개발자들은 한 스프린트 동안 개발을 진행합니다.
카드를 끌어다 in progress 부분에 옮겨두고 작업을 진행하죠.
어떤 카드를 선택할지는 본인 마음입니다. 먼저 선택하는 사람이 본인이 더 하고 싶은 카드를 들고가서 시작하면 됩니다.

“스프린트는 플래닝을 통해 해당 스프린트에 진행할 작업을 정하고 시간을 추정했기 때문에, 플래닝때 정해진 작업을 스프린트 기간 내에 완료하는 것을 목표로 달립니다.”

때문에 스프린트 중간에 들어오는 이슈카드는 무조건 다음 스프린트의 BackLog로 들어가게 되면 해당 스프린트 기간동안 고려하지 않습니다.

(플래닝 할 당시에 고려된 이슈카드들을 기준으로 시간을 산정했고 약속한 기간내에 끝내는 것을 약속했기 때문입니다.)

이렇게 스프린트를 진행한 후 스프린트 마지막날 스프린트 기간 동안 진행한 작업들을 플래닝 내용을 가지고 회고를 합니다.
이슈가 있었던 부분, 잘한 점, 부족했던 점, 아쉬웠던 점, 더 나아졌으면 하는 점 등등 
많은 의견들이 오가는 자리입니다.
다과와 커피를 함께하며 스프린트를 진행하는 동안 발생했던 이슈가 다음스프린트때는 고려될 수 있도록 서로의 경험을 공유하는 무겁지 않은 팀웍다지기 이기도 입니다.

칸반은 WIP (Work In Progress)제한이 핵심입니다.

매일 오전 데일리 미팅을 진행 해 오늘 할 일을 공유하고 어제 한 일을 간단히 리뷰합니다(15분 정도)
칸반과 스크럼의 가장 두드러지는 차이는 스프린트 기간이 정해져 있지 않다는 것입니다. 스프린트처럼 약속된 종료일이 없는거죠.

칸반 또한 이슈카드가 들어올 때마다 데일리 미팅에서 플래닝 포커를 통해 시간 추정 작업을 합니다. 하지만 해당 이슈카드 언제 시작되서 언제 처리될 지는 스크럼처럼 정해진 기간이 없는거죠.

이슈카드는 기한없이 backlog에 쌓이게 되고, 연속적인 일의 흐름에서 급한 작업단위 순서대로 in progress에 이슈카드를 넣고 처리합니다.

그 대신 In Progress바에 넣을 수 있는 이슈카드의 갯수가 제한됩니다. (이는 팀의 특성을 고려하여 갯수를 제한하고 WIP에 여유가 있을 시에만 백로그에서 카드를 옮겨올 수 있습니다.)

주로,
프로젝트같은 종료일이 정해져야 하는 업무가 많이 발생하는 경우는 스크럼,
지속적인 업무를 다루며 프로젝트 개발 및 ops까지 함께 다뤄야 하는 상대적으로 작은 단위의 팀에서는 칸반을 사용하는 것이 효율적입니다.

마지막으로,

HotFix라는 이슈를 다루는 관점에 대한 스크럼과 칸반의 차이입니다.
HotFix란 말 그대로, 예측되지 않았던 요청입니다.
운영되고 있는 서비스라면 고객이 마주친 버그 일 수도 있고, PO가 플래닝 당시에는 미처 정의하지 못했던 급한 business requirement 일 수 있습니다.

스크럼에서는 HotFix는 해당 스프린트에 “절.대.”넣지 않습니다. 
스프린트 진행 중 발생하는 모든 HotFix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 업무가 됩니다.(운영중인 서비스라면 개발자가 돌아가며 sustainment업무를 맡기도 합니다)

칸반에서는 HotFix 또한 바로 프로젝트 backlog에 쌓습니다. 
쌓여진 Hotfix를 바로바로 처리할 수 있죠. 해당 프로젝트를 끝내기 위해 처리해야 할 이슈카드로 동일하게 취급합니다. 이는 시간추정을 통해 이슈카드를 언제까지 처리할지 약속하지 않기 때문에 가능한 일입니다.

---

프로젝트 방법론, 이상과 현실사이(1) – 워터폴 vs 애자일

일상적이고 익숙한 워터폴 모델(Waterfall Model)

우리가 가장 흔하게 쓰고 있고 어쩌면 당연하다고도 생각 될 만큼 익숙한 프로젝트 수행 방식이 ‘워터폴 모델’ 입니다.
요구분석 → 설계 → 디자인 → 코딩 → 개발 순으로 순차적으로 이어지는 흐름이 마치 폭포수처럼 아래로 이어져 보인다 하여 이름 붙여졌습니다.

  

[워터폴 모델 도식화, 출처. http://slidehunter.com/]

고객과의 의사소통을 중시하는 애자일 모델(Agile Model)

애자일 모델은 정확히 말하면 어느 특정한 개발 방법론을 지칭하고 있지 않습니다.
‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말입니다.

예전에는 애자일 개발 프로세스를 경량(Lightweight) 프로세스 라고 불렀다고도 합니다.
애자일 모델이 다른 방법론과 구별되는 가장 큰 차이점은 Less Document-Oriented, 즉 문서를 통한 개발이 아니라 Code-Oriented, 실질적인 코딩을 통한 방법론이라는 점입니다.

[ 애자일 모델 도식화, 출처. http://slidehunter.com/ ]

---

Agile Scrum Kanban Waterfall

Scrum?

Scrum은 Agile을 구현하는 가장 보편적 인 방법 중 하나입니다. 스크럼은 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델입니다. 

Kanban?

일본에서 '시각적 기호'또는 '카드'를 의미하는 Kanban은 Agile을 구현하는 시각적 프레임 워크입니다. 현재 시스템에 대한 작고 지속적인 변경을 촉진합니다. 그 원칙은 다음과 같습니다 : 워크 플로우를 시각화하고, 진행중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상시킵니다.