칸반과 스크럼

스크럼과 칸반이라는 책을 읽고 있습니다.
스크럼은 무엇인지, 칸반은 무엇인지, 각각의 프로세스는 어떻게 사용하는지에 대해 공부합니다.

책에서 나온대로 설명을 적어보고 다른 자료에서는 어떻게 설명하는지 참고하려합니다.

스크럼

• 조직을 작고, 교차 기능적이며 자기 조직적인 팀으로 쪼개라.
• 일을 출시 가능한 작은 단위의 목록으로 나누라. 목록을 우선순위에 따라 정렬하고 각 항목에 대해 상대적인 노력을 추정하라.
• 시간을 짧고 고정된 길이의 이터레이션으로 나누고, 이터레이션을 마칠 때 잠재적으로 출시 가능한 코드를 시연하라.
• 출시 계획을 최적화하고, 매 이터레이션 이후 결과물을 검토하면서 얻어진 지식(통찰력)을 바탕으로 고객과 협업을 통하여 우선순위를 수정하라.
• 이터레이션을 마칠 때마다 회고를 실시하여 프로세스를 최적화하라.

소규모 팀에서 짧은 시간 동안 작은 것을 만들도록 한다.
단, 전체적인 모습을 볼 수 있게 정기적으로 통합한다.

칸반

• 일을 작은 조각으로 나누고, 카드에 각 항목을 기입한 후 벽에 붙인다.
• 이름이 부여된 열을 사용하여 각 항목이 작업 흐름의 어디에 있는지 표시한다.
• WIP(작업 중인 일, Work In Progress) 개수를 제한하라. 각 작업 흐름 상태(단계)별로 작업 중인 항목을 얼마나 허용할 것인지 확실한 수치를 부여한다.
• 리드 타임(한 항목을 완료하는 데 소요되는 평균시간, 사이클 타임)을 측정하고, 리드 타임을 가능한 짧고 예측 가능하게 만들 수 있도록 프로세스를 최적화한다.
• 참고: http://www.crisp.se/kanban

스크럼과 칸반의 연관성

스크럼과 칸반은 둘 다 프로세스 도구

스크럼과 칸반은 무엇을 해야 하는지 알려줌으로써 일을 어느정도 더 효과적으로 처리하는 데 도움을 주는 프로세스 도구다.

비판 No, 이해를 통해 도구를 비교하자

포크, 나이프, 젓가락과 같이 밥을 먹기위해 사용하는 도구들이다.
도구 사용 목적에 비유하여 설명하기를 다 각각에 맞는 상황이 있기 때문에 비판이 아닌 이해를 통해 도구를 비교해야 한다고 설명하고 있다.

완전한 도구도, 완벽한 도구도 없다

다른 도구들과 마찬가지로 스크럼과 칸반 역시 완벽하지도, 완전하지도 않다.
필요한 모든 것을 알려주지 않고 단지 제약 조건과 지침을 약간 제공할 뿐이다.

스크럼은 칸반보다 규범적이다

규범적이라는 말은 지켜야할 규칙이 많다라는 말이다.
반대로, 적응적이라는 말은 지켜야할 규칙이 적다를 의미한다.

스크럼과 칸반 둘다 적응적이지만, 상대적으로 스크럼이 칸반에 비해 더 규범적이다.

규범적인 순서대로 나열을 해본다면, 아래와 같이 설명할 수 있다.

RUP »»» XP » 스크럼 > 칸반 > 멋대로

• RUP라는 프로세스 도구는 제약이 엄청나게 많다. (약 120개 이상)
• XP(eXtreme Programming)는 스크럼에 비해 상당히 규범적이다. 스크럼 + TDD + Pair Programming과 같이 구체적인 기술적 실천법을 포함하고 있다.
• 스크럼은 XP에 비해 덜 규범적이다. (기술적 실천법이 규정되어 있지 않음)
• 칸반은 거의 모든 것이 열린 상태. 제약 사항이라고는 일의 흐름을 시각화하라, 작업 중인 일의 양을 제한하라 정도.

스스로를 한 가지 도구에 제한하지 말라!

필요한 만큼 도구를 이것저것 섞어 사용하자. 우리에게 맞는 것이라면 무엇이든 취하는 것이 좋다.
대신 각 도구의 제약에 관심을 기울이자.

스크럼의 핵심기법인 기간이 고정된 이터레이션, 작은 결과물 보여주기, 지속적인 통합을 하지 않고서는 스크럼을 적용하고 있다고 말할 수 없다.

각 도구에서 필요한 제약이 있는 이유를 고민해보는 것이 좋을 것 같다.

스크럼은 역할을 규정한다

스크럼은 세 가지 역할을 정의한다.

• 제품 책임자 (Product Owner): 제품의 비전과 우선순위를 부여
• 제품 구현팀 (Team): 제품을 구현
• 스크럼 마스터 (Scrum Master): 장애물 제거 및 프로세스 리더십 제공

칸반은 어떠한 역할도 정의하지 않는다.

스크럼과 칸반의 공통적인 마음가짐은 간결할수록 좋다는 것.

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

스크럼은 시간이 고정된 이터레이션에 기반을 둔다.
얼마 동안은 동일한 이터레이션 길이를 유지함으로써 리듬을 만드는 것이 일반적인 아이디어.

• 이터레이션 시작: 이터레이션 계획이 만들어짐. 제품 백로그에서 특정 개수의 아이템을 가져옴.
• 이터레이션 중: 팀은 하기로 약속한 아이템들을 완료하는 데 집중한다. 이 동안 해야 할 일은 변경되지 않는다.
• 이터레이션 끝: 팀은 작동하는 코드를 시연한다. 이상적으로 이 코드는 잠재적으로 출시가 가능해야만 한다. 그 후에 팀은 자신들의 프로세스를 토론하며 개선하기 위한 회고를 실시한다.

스크럼 이터레이션은 시간이 고정된 하나의 리듬으로, 계획하기, 프로세스 개선, 릴리스의 세 가지 다른 활동으로 구성된다.

이터레이션 예시

1. 스크럼 이터레이션
   • 앞서 설명한 이터레이션
2. 서로 다른 세 개의 리듬
   • 회고는 4주마다, 계획 수립은 2주마다, 릴리스 리듬은 1주마다
3. 이벤트 기반
   • 일이 다 떨어지기 시작할 때마다 계획 수립, 4주마다 회고

칸반은 워크플로우 상태 별로, 스크럼은 이터레이션 별로 WIP을 제한한다

• 칸반은 진행 중인 일에 WIP 제한을 하고 스크럼은 이터레이션 별로 간접적으로 WIP를 제한한다.
• 스크럼과 칸반은 방법만 다를뿐 WIP를 제한한다.
• 스크럼 팀은 속도(velocity)라는 지표를 측정한다.
  • 이 속도는 이터레이션당 처리한 일의 수(또는 스토리포인트)를 의미한다.
• 칸반은 각 상태에 WIP를 제한하고 일의 처리를 관리한다.

둘 다(칸반 & 스크럼) 경험적이다

프로세스를 실험해보고 환경에 맞게 수정하기를 기대하기 때문.

• 스크럼은 교차 기능 팀을 운영해야 한다고 말한다. 그렇다면 누구를 어떤 팀에 배치해야 하는가? 알 수 없다. 실험해 봐야 안다.
• 스크럼은 한 스프린트에서 해야 할 일의 양을 팀이 선택한다고 말한다. 그렇다면 얼마나 가져가야 할까? 알 수 없다. 실험..
• 칸반은 WIP을 제한해야 한다고 말한다. 그렇다면 얼마로 제한해야 할까? 알 수 없.. 실험!

피드백 루프가 중요!

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

• 스크럼에서 스프린트 중에 태스크가 추가되는 것을 제한한다. 대신에 제품 백로그에 남겨두고 다음 스프린트에 하는 과정으로 진행한다.
• 칸반은? 할 일 컬럼에 추가해주세요~ 하지만 WIP 제한되었다면 있는 할 일에 있는 일 중에 빼고 그것을 넣어주세요~, 이렇게 진행한다.
• 스크럼에서는 제품 책임자가 스크럼 보드를 건드릴 수 없다. 왜냐하면 해당 스프린트 내에 특정 아이템 집합을 진행하기로 팀에 약속했기 때문이다.
• 일반적으로 제품 책임자는 할 일, 준비, 백로그, 제안 같은 맨 왼쪽 컬럼을 할당 받는다. 이 컬럼은 원할 때마다 변경할 수 있는 곳이다.
• 스크럼에서의 응답 시간은 평균적으로 스프린트 길이의 절반이다.
• 칸반에서의 응답 시간은 여력이 생기는 데 걸리는 시간으로, 한 아이템 빠져나감 = 한 아이템 들어옴 이라는 일반적인 원칙을 따른다.

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

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

보드를 초기화하는 과정을 통해 뭔가를 이루고 마무리 지었다는 좋은 기분!
고생스럽긴 하지만 하고 나면 개운한 느낌이 든다.

칸반에서 보드는 일반적으로 변함이 없다. 즉 초기화하고 다시 시작할 필요가 없다.

스크럼은 교차 기능 팀을 규정한다

• 스크럼 보드는 정확히 특정 스크럼 팀에 속한다.
• 스크럼 팀은 교차 기능 팀으로 이터레이션 내에 모든 아이템을 완료하는데 필요한 기술을 보유.
• 스크럼 보드는 관심 있는 사람이라면 누구든지 볼 수 있지만, 보드 소유권을 갖는 스크럼 팀만 수정할 수 있다.
• 스크럼 보드는 팀이 이터레이션 동안 하기로한 일을 관리하는 도구다.

칸반에서는 교차 기능 팀이 선택 사항이며 보드를 특정 팀만 소유할 필요도 없다. 보드는 특정 워크플로우와 연관된 것, 특정 팀에 속한 것이 아니다.

칸반에서는 누가 어떻게 보드를 사용할 것인지에 대한 몇가지 기본 규칙을 설정, 규칙이 흐름을 최적화하는지 실험할 필요가 있다.

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

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

스크럼 팀

• 한 이터레이션 내에 완료 기준에 의거하여 완료할 수 있다고 생각하는 아이템들만 하기로 약속.
• 아이템이 너무 커서 한 스프린트에 맞지 않으면, 팀과 제품 책임자는 작은 조각으로 나누는 방법을 고민.
• 아이템들이 커질 수 밖에 없다면 이터레이션 길이가 길어져야함.
• 하지만 통상 4주를 넘지 않아야 한다.

칸반 팀

• 리드 타임을 최소화하고 흐름을 유지.
• 이 흐름이 간접적으로 아이템들을 작은 조각으로 쪼개도록 유도함.
• 하지만 칸반에서는 명시적으로 특정 기간에 맞게 짧아야한다는 규칙이 없음.
• 같은 보드에서 한 아이템은 완료하는데 한 달이 걸리고 다른 아이템은 하루가 걸릴 수도 있음.

스크럼은 추정과 속도를 규정한다

스크럼

스크럼에서 팀은 하기로 한 각 아이템을 상대적인 크기로 추정한다.
매 스프린트의 종료 시점에 완료된 아이템 각각의 크기를 합산한 것이 속도다.

속도는 역량에 관한 지표인데 스프린트당 일을 얼마나 많이 할 수 있는지를 나타낸다.
평균 속도를 알면 다음 스프린트에서 완료할 수 있는 아이템들에 대한 현실적인 예측을 할 수 있고, 현실적인 출시 계획을 수립할 수 있기 때문에 팀의 평균 속도를 아는 것이 좋다.

칸반

칸반에서는 추정을 규정하고 있지 않다. 따라서 약속을 원한다면 어떻게 예측성을 제공할 것인지 결정해야한다.

• 스크럼처럼 추정을 하고 속도를 측정
• 추정 생략, 단위 시간당 얼마나 많은 아이템을 완료하는지 속도 측정. (아이템을 거의 같은 크기의 조각으로 쪼갬)
• 아이템들을 최소 판매 가능 기능으로 그루핑, MMF 당 평균 리드 타임 측정.

구체적인 기법이 명시되어 있지 않으니 자신의 상황에 적합한 것을 찾기 위해 다른 기법들을 시도해보는 것이 좋다.

둘 다 여러 제품의 동시 개발을 허용한다

스크럼에서 ‘제품 백로그’는 다소 적합하지 않은 이름이다. 모든 아이템이 제품 하나에 대한 것이어야만 한다는 의미라서.

한 팀이 여러 개의 제품을 개발할 수 있기 때문에 아래와 같은 상황이 생길 수 있다.

• 스프린트 당 각각 다른 제품을 개발
• 한 스프린트에 두 제품의 기능을 개발

칸반도 위와 같이 작업이 가능하다. (스윔 레인을 나눠서 두 제품을 개발)

둘 다 린(Lean)하고 애자일(Agile)하다

스크럼과 칸반은 모두 린과 애자일의 원칙과 가치에 잘 부합한다.

• 스크럼과 칸반은 모두 당김 스케줄링 방식이며 이는 린의 원칙인 JIT(Just In Time) 재고 관리 방식에 해당. 이 말은, 언제 얼마나 많은 양의 일을 할지 팀이 정한다는 뜻이며 외부로부터 일을 넘겨 받기가 아닌 팀이 준비가 되었을 때 일을 당겨온다는 것이다.
• 스크럼과 칸반은 지속적이며 경험주의적 프로세스 최적화에 기반을 두고 있다. 린의 원칙인 카이젠에 해당한다.
• 스크럼과 칸반은 계획을 따르기보다 변화에 대응할 것을 강조한다. 이는 애자일 선언의 네 가지 가치 중 하나에 해당한다.

우리에게 맞는 것을 찾을 때까지 계속 실험해보고 그 실험을 지속하여 최적화하자.

사소한 차이점

• 스크럼은 우선순위가 부여된 제품 백로그를 규정한다.
• 스크럼에서는 일일 미팅을 규정한다. (일일 스탠드업은 칸반 팀도 대부분 함)
• 스크럼은 번다운 차트를 규정한다. (칸반에서는 명시되어있는 것은 없어서 어떤 차트라도 사용가능)

조직들은 대부분 빨리 마치기를 원한다. 많은 조직이 이를 위해 많은 사람을 투입하거나 초과 업무를 시키지만, 큰 함정.

대개 작업을 더 신속하게 끝내기 위한 효과적인 방법은, 작업 흐름에 방해되지 않게 하고 수용 능력에 맞게 일을 제한하는 것이다.

스크럼 보드와 칸반 보드: 간단하지만 의미 있는 예제

스크럼에서 스프린트 백로그는 팀이 이번 스프린트에 어떤 일을 하느지를 보여주는 그림의 한 부분에 불과하다. 그 그림의 나머지 부분은 제품 책임자가 향후 스프린트들에서 완료되기 원하는 일의 목록인 제품 백로그다.

제품 책임자는 스프린트 백로그를 볼 수만 있고 건드릴 수는 없다. 진행 중인 작업을 변경할 수는 없다.

스프린트가 종료되면, 팀은 제품 책임자에게 ‘잠재적으로 출시 가능한 코드를 전달’해야 한다.

(예제에 대한 내용은 책에 잘 나와 있음.)

WIP 리밋은 어떠해야 하는가?

• 너무 낮은 WIP 리밋 -> 한가한 사람들 -> 낮은 생산성
• 너무 높은 WIP 리밋 -> 쌓이는 일들 -> 긴 리드 타임

WIP 리밋은 얼마나 엄격한가?

엄격하게 지킬 것이냐 가이드라인으로 둘 것이냐는 우리에게 달려 있는 것.

스크럼과 칸반 비교 요약

비슷한 점

• 린하고 애자일하다.
• 당김 스케줄링을 사용한다.
• WIP 제한을 둔다.
• 투명하게 공정 개선을 이끌어낸다.
• 출시 가능한 제품을 자주, 일찍 배포하는 데 집중한다.
• 자기 조직화된 팀을 기반으로 한다.
• 일을 작은 단위로 쪼갤 필요가 있다.
• 출시 계획은 경험적인 자료(속도, 리드 타임)에 기반을 두고 지속적으로 최적화한다.

다른 점

1부 끝

2부 에서는 사례 연구에 대한 이야기를 공부할 예정이다.