블로그 리스트
이 블로그 포스트는 시리즈로 작성되어 있습니다. 다른 내용을 확인하고 싶으신 분들은 아래에 링크를 참고하시기 바랍니다.
- 목차
- (1) 스크럼, 칸반 그리고 도구
- (2) 역할, 이터레이션 그리고 WIP 제한
- (3) 고유의 프로세스, 할일 추가, 보드 초기화
- (4) 교차 기능 팀, 작업 쪼개기, 측정하라 그리고 예측하라
- (5) 일일 미팅, 업무 프로세스의 최적화, WIP 제한을 잘 이용하자
- 칸반과 스크럼을 읽고 나서
교차 기능 팀
스크럼 팀은 교차 기능 팀으로 이터레이션 내에 모든 아이템을 완료하는 데 필요한 기술을 전부 보유하고 있다. 칸반에서는 교차 기능 팀은 선택 사항이다. 예를 들어 칸반에서는, 개발을 집중하는 팀과, 테스트와 릴리스에 특화된 팀을 가질 수 있다.
스크럼을 실행하기 위해서는 팀원들의 능력과 지속적인 통합이 가능한 환경을 구성해야 한다. 간단히 생각하면, 모든 개발자가 풀스택 개발자(Full stack developer)여야 하고 데브옵스(Dev-ops)가 가능한 환경이어야 한다.
칸반에서는 교차 기능 팀에 대한 제한 사항이 없으므로, 자유롭게 팀을 구성할 수 있다. 하지만 소수의 멤버로 운영된다면, 그 팀은 교차 기능 팀과 같은 기능을 해야할 것이다.
작업 쪼개기
스크럼과 칸반은 모두 작업을 작게 쪼개어 개발하는 점진적 개발 방식에 기반을 두고 있다.
스크럼 팀은 경험적인 결과로 얻은 완료 기준에 의거하여 한 이터레이션 내에 완료할 수 있다고 생각하는 아이템들만 하기로 약속하게 될 것이다. 아이템이 너무 커서 한 이터레이션에 끝 낼 수 없다면, 팀과 제품 책임자는 스프린트에 맞출 수 있게 아이템을 작게 쪼개는 방법을 찾으려 할 것이다. 작게 쪼갠 아이템이 여전히 크다면, 이터레이션 길이를 조절할 것이다.
칸반 팀은 이터레이션이 없기 때문에, 리드 타임을 최소화하고 흐름을 유지하려고 노력한다. 리드 타임을 최소화하고 흐름을 유지하기 위해 간접적으로 아이템들을 상대적으로 작은 조각으로 쪼개게 된다. 하지만 칸반에서는 특정 기간안에 아이템을 완료해야 한다는 명시적인 규칙이 없다. 따라서 같은 칸반 보드에서 한 아이템은 완료하는데 한 달이 걸리고 다른 아이템들은 하루가 걸릴 수 도 있다.
여기서 중요한 것은 반복적으로 실험을 하여 현재 하고 있는 업무가 예측 가능한 상태를 만들어야한다. 스크럼에서는 반복적인 실험으로 이터레이션 기간과 기간 내에 끝낼 수 있는 아이템, 그리고 새로 추가한 아이템을 쪼갬으로써 남은 아이템들을 언제 어느정도 끝낼 수 있는지 예측할 수 있게 해야한다. 칸반에서도 리드 타임을 최소화 시키고, WIP 제한에 걸리지 않도록 업무 흐름을 유지하기 위해서 아이템들을 작게 쪼갤 것이며, 이렇게 쪼갠 아이템들의 리드 타임을 통해 업무에 걸리는 시간을 예측할 수 있게 될 것이다.
측정과 예측
스크럼 팀에서는 각 아이템을 상대적인 크기(업무의 양)로 추정한다. 그리고 스프린트 종료 시점에 완료된 아이템의 크기를 합산하여 속도를 산출한다. 이 속도는 팀의 역량에 관한 지표로, 해당 팀이 스프린트당 일을 얼마나 많이 할 수 있는지 알 수 있게 해 준다. 이렇게 팀의 평균 속도를 알게되면, 팀이 완료할 수 있는 아이템들에 대한 현실적인 예측이 가능해지고, 결국 현실적인 출시 계획을 수립할 수 있게 된다.
칸반에서는 특별히 추정에 대한 규정이 없다. 따라서 칸반 팀은 어떻게 예측성을 제공할 것인지 결정할 필요가 있다. 어떤 칸반 팀에서는 스크럼처럼 추정하여 속도를 측정할 수도 있고, 다른 팀들은 추정은 생략하고 단위 시간당 얼마나 많은 아이템을 완료했는지를 통해 속도를 측정할 수도 있다.
앞에서도 이야기했지만, 스크럼과 칸반을 통해서 우리는 업무를 예측 가능한 상태로 만들어야 한다. 이런 예측 가능한 업무 상태를 만들지 않는다면, 언제 출시가 가능한 상태인지 알 수 없고, 프로젝트는 무기한 연장될 것이다.
스크럼은 규정이 있으므로 해당 규정을 통해, 팀의 속도와 업무를 예측하면 된다. 칸반은 특정한 규정이 없으므로, 팀내에서 어떤 방식으로 속도를 측정할 것이고, 그를 통해 전체적인 업무를 어떻게 예측할 수 있는지에 대해 고민해야 한다.
동시 개발
스크럼에서는 동시에 여러 제품 개발이 가능하다. 따라서 스크럼의 “제품 백로그”는 모든 아이템이 제품 하나에 대한 것이어야 한다는 의미를 담고 있기 때문에 다소 적합하지 않은 이름일 수 있다.
어떻게 한 팀이 여러 제품을 개발할 수 있을까? 예를 들어 두 제품이 있고, 스크럼 팀이 하나라면, 두 제품에 관한 백로그를 하나로 합친 후, 우선 순위를 아이템을 나열하고 해 당 팀의 이터레이션에 해야 할 일들을 결정하면 된다.
이때, 스크럼 팀은 한 스프린트에는 하나에 제품에만 집중하여 스프린트를 진행할 수도, 한 스프린트에 여러 제품을 동시에 진행할 수 도 있다.
칸반에서도 동일하다. 칸반 팀도 여러 제품을 개발할 수 있으며, 여러 제품에 대한 아이템을 한 칸반 보드에 추가한 후, 우선 순위를 결정하고 WIP 제한을 이용하여 진행하면 된다.
하지만 동시에 여러 제품을 진행하기 앞서 우리는 스크럼 또는 칸반 팀의 평균 속도와 업무에 대한 예측이 가능한 상태를 만들어야 한다. 그렇지 않으면 각 제품에 대한 출시 계획을 세울 수 없어 프로젝트는 실패로 돌아갈 것이기 때문이다.
린과 애자일
스크럼과 칸반은 다음과 같이 린하고 애자일스럽다.
- JIT(Just In Time): 스크럼과 칸반은 당김 스케줄링 방식을 사용하며 이는 린의 원칙인 JIT(Just In Time) 재고 관리 방식에 해당한다. 이 말은 외부로부터 일을 넘겨받기 보다는 팀이 언제 얼마나 많은 양의 일을 할지 결정하고 준비가 되었을 때, 일을 당겨와 수행한다는 것을 의미한다.
- 카이젠: 스크럼과 칸반은 지속적이며 경험주의적 프로세스 최적화 기반을 두고 있다. 이는 린의 원칙인 카이젠에 해당된다.
- 변화의 대응: 스크럼과 칸반은 계획을 따르기보다는 변화에 대응할 것을 강조한다. 이는 애자일 선언의 네가지 가치 중 하나에 해당한다.
스크럼은 기간이 고정된 이터레이션에서 계획된 아이템만을 처리하기 때문에 린 방식처럼 보이지 않을 수 있으나, 기존 방식처럼 1년에 2~4번 정도 제품을 통합하고 출시하는 프로세스와 비교하면, 스크럼은 린에 가깝다. 또한 이터레이션을 점점 짧게 유지해 간다면 그것은 칸반 방식에 근접해 지는 것이고 이는 이터레이션이 필요없음을 의미할 수도 있다.
그러므로 스크럼을 사용하던, 칸반을 사용하던 여러분 팀에 맞게 프로세스를 최적화하는 것에 집중하라.
인사이트
- 스크럼과 칸반을 운영하려면 멤버와 개발 프로세스가 적합한지 확인해야 한다.
- 경험적 실험을 통해, 아이템을 쪼개고, 업무의 걸리는 시간을 예측할 수 있게 해야 한다.
- 측정하라 그리고 예측하라
- 동시 개발은 가능하다. 하지만 그 전에 팀의 평균 속도와 업무에 대한 예측이 가능한 상태를 만들자.
- 스크럼과 칸반은 린하고 애자일스럽다.
- 스크럼과 칸반은 지속적이며 경험주의적 프로세스 최적화 기반을 두고 있다. 그러므로 끊임없이 실험하여 프로세스를 최적화하도록 노력하자.