Agile

[Agile] 칸반과 스크럼

칸반과 스크럼에 대해서 이해해보자.

* 스크럼과 칸반이란 무엇인가?

출처 : https://plan.io/blog/ultimate-guide-to-implementing-agile-project-management-and-scrum/

스크럼(Scrum)과 칸반(Kanban)은 둘 다 애자일 방법론 중 하나로 일을 조금 더 효과적으로 처리하는데 도움을 주는 프로세스 도구다. 그럼 이 스크럼과 칸반이 무엇이며 어떻게 다른지에 대해서 살펴보도록 하자.

“스크럼은 칸반보다 지켜야 할 규칙이 많다.”

애자일 방법론이 경량 방법론인 것은 기존 전통적인 개발 방법론에 비해 지켜야 할 규칙이 적기 때문이다. 칸반과 스크럼 모두 지켜야할 규칙이 적지만 상대적으로 스크럼이 칸반보다 지켜야할 규칙이 더 많다. 예를 들어, 스크럼은 시간을 짧고 고정된 길이의 이터레이션(통상 1~4주)으로 나누게 되어있지만 칸반은 그렇지 않다. (사실 칸반은 제약 사항이라곤 일의 흐름을 시각화하는 것과 작업 중인 일의 양을 제한하는 것 뿐이기 때문에 모든 것이 열린 상태라고 할 수 있다.)

” 그럼 지켜야할 규칙이 적다고 해서 칸반을 적용하려고 하는데 그럼 스크럼이나 XP와 같은 방법론의 프로세스 도구는 사용할 수 없는건가요??”

얼마든지 필요한 만큼 이것저것 섞어서 사용해도 된다!! 칸반을 하면서 스크럼 실천법인 일일 스탠드업 미팅을 진행해도 되고, 스크럼을 하면서 XP의 테스트 주도 개발이나 짝 프로그래밍을 실천해도 된다. 대신 각 방법론이 가진 제약에 관심을 가져야 한다. 가령 스크럼을 적용하면서 이터레이션이나 기타 스크럼 핵심 기법들을 사용하지 않는다면 스크럼을 적용하고 있다고 말할 수 없을 것이다.

“스크럼은 역할을 규정한다.”

스크럼은 “제품 책임자”, “스크럼 마스터”, “구현 팀” 세 가지 역할을 정의한다.

출처 : https://www.visual-paradigm.com/scrum/how-scrum-team-works/
  • 제품 책임자 : 제품의 비전과 우선순위를 부여
  • 스크럼마스터 : 장애물을 제거하고 프로세스 리더십을 제공
  • 구현 팀 : 제품을 실행하고 전달하는게 가장 큰 역할

하지만 칸반은 어떠한 역할도 정의하지 않는다. 그렇다고해서 이런 역할을 가질 수 없고, 가져서는 안 된다는 의미는 아니다! 꼭 필요한 것이 아니라는 의미일 뿐 스크럼과 칸반 모두 필요한 역할이라면 무엇이든 자유롭게 추가해도 된다. (대신 추가하기 전에 꼭 필요한 역할인지 한 번 더 고민해 보시길 바란다.)

“스크럼은 기간이 고정된 이터레이션을 규정한다.”

스크럼은 시간이 고정된 이터레이션(스크럼에서는 다른 말로 스프린트라고도 부름)에 기반을 둔다. 동일한 이터레이션 길이를 유지함으로써 리듬을 만드는 것으로 이터레이션 길이는 스크럼 적응도나 진행상황에 따라 1~4주 유연성을 가질 수 있다.

출처 : http://scrumreferencecard.com/scrum-reference-card/
  • 이터레이션 시작 : 이터레이션 계획을 수립. 팀은 제품 책임자의 우선순위와 팀이 한 이터레이션 내에 얼마나 완료할 수 있을지를 고려하여 제품 백로그에서 특정 개수의 아이템을 가져온다.
  • 이터레이션 중 : 팀은 완료하기로 약속한 아이템들을 완료하는데 집중한다. 이터레이션 동안에 해야 할 일은 변경되지 않는다.
  • 이터레이션 끝 : 이해관계자들에게 작동하는 코드를 시연한다. 이상적으로 이 코드는 테스트와 모든 준비가 완료되어 잠재적으로 출시가 가능해야 한다. 이후 다음 이터레이션을 좀 더 개선하기 위해 회고를 실시한다.

칸반에서는 시간이 고정된 이터레이션을 언급하지 않는다. 즉 언제 계획을 수립할지, 프로세스를 개선할지, 릴리스를 할지 선택할 수 있다.

“칸반은 워크플로우 상태별로, 스크럼은 이터레이션별로 WIP(Working in Progress) 을 제한한다.”

WIP(Working in Progress)를 제한한다는 건 동시에 개발이 진행될 수 있는 아이템의 수를 제한한다는 것을 뜻한다.

칸반은 WIP를 워크플로우 상태별로 제한을 둔다. 아래 그림을 보면 분석, 리뷰, 배포, 테스트와 같은 각 워크플로우 위에 숫자가 적혀있는 것을 볼 수 있다. 예를 들어 2는 ‘어느 때든 이 열에는 최대 2개의 아이템만 존재할 수 있다’ 는 것을 의미한다. 즉, ‘분석 진행중’ 이라는 워크플로우 상태에는 어느 때든 최대 2개의 아이템만 존재할 수 있는 것이다.

출처 : https://www.scaledagileframework.com/team-kanban/

어떤 워크플로우의 상태에 얼마나 제한을 둘지 결정해야하는데 WIP 제한을 두게 되면 리드 타임, 즉 아이템 하나가 보드를 가로지르는 평균 시간을 측정하고 예측할 수 있게 된다. 예측 가능한 리드 타임을 얻게 되면 SLA(Service-Level Agreement: 서비스 수준 동의) 를 약속할 수 있고 현실적인 출시 계획을 수립할 수 있게 될 것이다. 아이템 크기가 천차만별인 경우 스토리 포인트나 팀 내부에서 정한 아무 단위로든 WIP 제한을 설정해도 된다.

반면에 스크럼에서는 각 워크플로우 상태에 한 번에 모든 아이템을 올려놓지 못하게 막는 규칙은 없다. 칸반처럼 워크플로우 상태별 WIP 제한이 없기 때문이다! 그럼 스크럼에서는 전혀 WIP 제한을 하지 않는 것인가?

스크럼 팀은 이터레이션 당 완료된 아이템이나 이에 상응하는 스토리 포인트 같은 단위가 얼마나 되는지 등을 나타내는 속도(velocity) 라는 지표를 측정한다. 측정된 팀의 속도는 WIP 제한을 위한 가이드라인으로 사용할 수 있다. 평균속도가 25인 팀은 대게 스프린트에 25개 이상의 아이템이나 스토리 포인트를 가져오지 않는데 아래 그림처럼 스프린트당 가져올 수 있는 작업량(백로그)을 제한함으로써 간접적으로 WIP 를 제한하는 것이다.

출처 : https://www.scaledagileframework.com/team-kanban/

필요하다면 아래 그림처럼 백로그 뿐만 아니라 워크플로우 상태별로도 제한을 둘 수 있다.

출처 : https://www.scaledagileframework.com/team-kanban/

정리하자면 스크럼에서는 WIP 를 단위 시간(스프린트) 별로 제한하고, 칸반에서는 워크플로우 상태별로 WIP 를 제한한다. 따라서 스크럼과 칸반 모두 방법만 다를 뿐 WIP 를 제한하는 것이다. (WIP 를 얼마로 제한할 지는 팀에서 실험과 경험을 통해 얻어서 적용해야 할 것이다.)

“스크럼은 이터레이션 내에 변경을 허용하지 않는다.”

스크럼 팀에서 이번 스프린트에 A, B, C, D 의 일을 진행하던 중 누군가 E 를 추가하려고 한다면 어떻게 될까? 스크럼 팀에서는 전형적으로 이렇게 말할 것이다.

출처 : https://www.triology.de/en/blog-entries/scrum-vs-kanban

“죄송하지만 이번 스프린트에는 A, B, C, D 까지만 하기로 승인을 받았기 때문에 안됩니다. 제품 백로그에 E 를 넣어두시고 제품 책임자가 높은 우선순위로 둔다면 다음 스프린트로 처리할 수 있습니다.”

그럼 이와 같은 상황에서 칸반 팀에서는 어떻게 할까?

출처 : https://www.triology.de/en/blog-entries/scrum-vs-kanban

칸반 팀은 “자유롭게 E 를 ‘할 일’에 추가하셔도 됩니다. 하지만 ‘할 일’ 의 WIP 제한이 2이기 때문에 지금 추가하려면 C 나 D 를 제거해야 합니다. 아니면 A 나 B 를 작업하고 있지만 완료되면 ‘할 일’ 에서 가장 우선순위가 높은 아이템을 당겨오겠습니다.” 라고 말할 것이다.

우선 순위 변경에 반응하는데 걸리는 시간을 응답 시간이라고 한다. 칸반 팀의 응답 시간은 여력이 생기는데 걸리는 시간으로 한 아이템이 끝나면 한 아이템이 들어온다는 일반적인 원칙을 따른다. 스크럼에서의 응답 시간은 평균적으로 스프린트 길이의 절반(새로운 스프린트 시작 전날이면 하루, 스프린트 진행 중이면 스프린트 기간만큼 걸리므로)이다. 스크럼에서는 제품 책임자가 스크럼 보드를 건드릴 수 없는데 이는 해당 스프린트 내에 특정 아이템 집합을 진행하기로 팀에 약속을 했기 때문이다. 칸반에서는 누가 보드의 내용을 변경하도록 할 것인지 고유한 기본 규칙을 설정해야 한다.

“스크럼 보드는 이터레이션마다 초기화된다.”

스크럼 보드는 스프린트가 끝나면 모든 아이템을 제거하여 보드를 정리한다(초기화). 새로운 스프린트를 시작하고 스프린트 계획 회의를 마치면 맨 왼쪽 열(백로그, 할 일)에 새로운 아이템들이 있는 새로운 스크럼 보드가 생긴다.

출처 : https://freshservice.com/kanban/kanban-vs-scrum-whats-the-difference-blog/

반면 칸반 보드는 일반적으로 변함이 없다. 스크럼 보드처럼 스프린트 별로 초기화하고 다시 시작할 필요가 없는 것이다.

출처 : https://freshservice.com/kanban/kanban-vs-scrum-whats-the-difference-blog/

“스크럼 백로그 아이템들은 한 스프린트에 맞아야 한다.”

스크럼과 칸반 모두 작업을 작은 조각으로 쪼개어 개발하는 점진적 개발에 기반을 둔다.

스크럼 팀은 한 스프린트 내에 완료할 수 있다고 생각하는 아이템들을 모아 모두 완료해야 한다. 그러기 위해 아이템이 너무 커서 한 스프린트에 맞지 않으면 팀과 제품 책임자는 스프린트에 맞출 수 있도록 아이템을 더 작은 조각으로 나누는 방법을 찾는다. 그러지 못하는 경우에는 스프린트 길이를 늘려야하는데 통상 한 스프린트 기간이 4주를 넘지 않도록 한다.

칸반 팀은 리드 타임을 최소화하고 흐름을 유지하고자 간접적으로 아이템들을 상대적으로 작은 조각으로 나눌 수 있도록 유도한다. 하지만 칸반에서는 스크럼처럼 특정 기간에 맞도록 아이템이 작아야 한다는 명시적인 규칙은 없다. 그렇기 때문에 같은 칸반 보드 내에서도 한 달이 걸리는 아이템도 있고 하루만에 끝나는 아이템들이 존재할 수 있다.

“스크럼은 우선순위가 부여된 제품 백로그를 규정한다.”

스크럼은 우선순위화는 항상 제품 백로그를 정렬하는 것으로 마무리 되며 변경된 우선순위는 현재 진행중인 스프린트가 아닌 다음 번 스프린트에 영향을 미친다. 반면 칸반은 어떤 식으로 우선순위를 매길지 선택하거나 아예 우선순위가 없을 수도 있다. 또한 변경 사항은 WIP 제한 내 여유가 있다면 곧바로 적용할 수 있다.

“스크럼은 일일 미팅을 규정한다.”

스크럼 팀은 일의 진행상황이나 이슈를 파악하기 위해 매일 15분 내외의 짧은 스탠드업 미팅을 가진다. 칸반에서는 일일 스탠드업 미팅을 규정하고 있진 않지만 스탠드업 미팅을 가져도 무방하다.

“스크럼에서는 번다운 차트를 규정한다.”

출처 : https://webgate.ltd.uk/burndown-chart/

스프린트 번다운 차트는 날마다 현재 스프린트에 얼마나 많은 일이 남아있는지를 보여준다. 스크럼에서는 이 스프린트 번다운 차트를 진척도를 추적하기 위한 주요 도구 중 하나로 사용한다. 예를 들어 위 번다운 차트를 보면 7일차까지는 순조롭게 진행되어 왔지만 8일차~12일차까지는 진전이 없다가 13일차에 작업들이 많이 완료된 것을 확인할 수 있다. 이처럼 번다운 차트를 통해 일정보다 지연되고 있는지 아니면 앞서가는지를 쉽고 빠르게 파악하여 대응할 수 있다.

칸반에서는 번다운 차트 뿐만 아니라 어떤 유형의 차트도 명시되어 있지 않다. 하지만 칸반에서도 필요하다면 원하는 어떠한 유형의 차트라도 사용할 수 있다.

마무리

지금까지 스크럼과 칸반에 대한 내용을 몇가지 다뤄보았다. 사실 아래 참고 도서를 읽어보기 전까진 스크럼과 칸반이 다른 거라곤 생각하지 못하고 있었다. 그냥 칸반이라는 건 스크럼을 하기 위한 방법 중 하나 정도로 생각했었다. (책을 다 읽고나서 아 우린 스크럼이 아닌 칸반을 하면서 일일 스탠드업 미팅 등 필요로 한 걸 추가로 적용하고 있는거구나 생각했다..)

혹시 필자처럼 스크럼과 칸반에 대해서 잘 모르고 있던 분들이 계시다면 진행하시는 업무나 상황에 맞는 적절한 방법을 사용하는데 조금이라도 도움이 되었으면 좋겠다.

참고

  • 도서 : 칸반과 스크럼(출판사 : 인사이트, 저자 : 헨릭 크니버그, 마티아스 스카린 / 심우곤,인범진 옮김)

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: