블로그 리스트
이 블로그 포스트는 시리즈로 작성되어 있습니다. 다른 내용을 확인하고 싶으신 분들은 아래에 링크를 참고하시기 바랍니다.
- 목차
- (1) 스크럼, 칸반 그리고 도구
- (2) 역할, 이터레이션 그리고 WIP 제한
- (3) 고유의 프로세스, 할일 추가, 보드 초기화
- (4) 교차 기능 팀, 작업 쪼개기, 측정하라 그리고 예측하라
- (5) 일일 미팅, 업무 프로세스의 최적화, WIP 제한을 잘 이용하자
- 칸반과 스크럼을 읽고 나서
역할 정의
스크럼과 칸반에서는 다음과 같이 역할을 정의하고 있다.
스크럼에서 역할 정의
스크럼에서는 다음과 같은 역할을 정의하고 있다.
- 제품 책임자: 제품의 비전과 우선순위를 부여
- 스크럼 마스터: 장애물을 제거하고 스포세스 리더십을 제공
- 제품 구현 팀
칸반에서 역할 정의
칸반은 어떠한 역할도 정의하지 않고 있다.
스크럼과 칸반에서의 역할
칸반에서 어떠한 역할도 정의하지 않고 있다고 해서, 칸반에서 제품 책임자 역할이 필요 없고, 이런 역할을 해서도 안된다는 의미는 아니다.
스크럼과 칸반 모두 필요한 역할이라면 무엇이든 자유롭게 추가할 수 있다. 하지만 역할을 추가할 때는 조심해야 한다. 추가한 역할은 가치를 창출해야 하고 프로세스의 다른 요소들과 충돌해서는 안된다.
스크럼과 칸반의 공통적인 마음가짐은 간결할수록 좋다이다. 그러므로 확신이 들지 않는다면 최대한 작게 시작하자.
예를 들어 프로젝트 관리자 역할은 대규모 프로젝트에 알맞은 역할일 수 있다. 프로젝트 관리자가 다수의 팀과 관리자들을 동기화하는데 도임이 될 수 있기 때문이다. 하지만 소규모 프로젝트에서는 프로젝트 관리자 역할이 쓸모없거나, 마이크로 매니지먼트를 초래하여 상황을 더 악화시킬 수 있다.
이터레이션
스크럼과 칸반에서 이터레이션이 어떻게 활용되는가 확인해 보자.
스크럼에서 이터레이션
스크럼은 시간이 고정된 이터레이션에 기반을 둔다. 이터레이션의 길이는 상황에 맞게 정할 수 있지만, 한번 이터레이션을 정하면 얼마 동안은 이 이터레이션을 유지함으로써 리듬을 만드는 것이 일반적이다.
- 이터레이션 시작: 제품 책임자의 우선순위와 팀이 생각하기에 한 이터레이션 내에서 얼마나 완료할 수 있을지에 따라 제품 백로그에서 특정 개수의 아이템을 가져온다.
- 이터레이션 중: 제품 구현 팀은 이터레이션 시작에서 결정한 아이템들을 완료하는데 집중한다. 이터레이션 중에는 할 일은 변경되지 않는다.
- 이터레이션 끝: 팀은 이해관계자들에게 작동하는 코드를 시연한다. 이상적으로는 이 코드는 출시가 가능한 상태, 즉 테스트와 출시를 위한 준비가 모두 끝난 상태여야 한다. 그리고 팀은 자신들의 프로세스를 토론하며 개선하기 위해 회고를 실시한다.
칸반에서 이터레이션
칸반에서는 시간이 고정된 이터레이션은 언급되지 않는다. 그러므로 언제 계획할지, 프로세스를 개선할지, 릴리스할지 선택할 수 있다.
이러한 일들을 정기적으로 수행할지, 그때 그때 수행할지 결정할 수 있다.
그러므로 스크럼에서 사용하는 이터레이션을 활용할 수 도 있고, 다음과 같이 다른 이터레이션도 구성할 수 있다.
- 세 개의 이터레이션을 사용
- 매주 릴리스할 준비가 된 것들을 릴리스
- 2주마다 계획 수립 회의를 하고 우선순위와 릴리스 계획들을 갱신
- 4주마다 프로세스를 수정하고 개선하기 위한 회고 실시
- 이벤트 기반 이터레이션
- 해야할 일이 떨어질 때 쯤, 계획 수립 회으를 실시
- 릴리스할 준비가 된 MMF(Minimum marketable Feature Set: 판매 가능한 최소 기능 집합)들이 있을 때마다 릴리스
- 같은 문제를 두번 겪을 때마다 자발적인 품질 사이클을 작동
- 4주마다 심도 있는 회고 실시
WIP 제한
스크럼과 칸반에서 WIP(Work In Process)를 제한하는 방법에 대해서 알아봅시다.
스크럼과 칸반 모두, 스크럼 보드, 칸반 보드를 사용하여 아이템을 추적하고 워크플로 상에서의 진행 사항을 파악한다. 진행 사항을 파악하기 위해 “할일 / 진행중인 일 / 완료한 일”과 같이 세 가지 상태로 나눌 수 있지만, 원한다면 어떤 상태든 추가할 수 있다. 예를 들어 통합, 테스트, 출시 등과 같은 상태도 원한다면 추가할 수 있다.
이렇게 얼마든지 상태를 추가할 수 있지만 간격할수록 좋다라는 원칙을 잊지 말자.
스크럼과 칸반의 WIP 차이
책에서 발췌한 위에 그림을 보면 칸반 보드에는 “진행 중” 항목 밑에 숫자 “2”를 확인할 수 있다. 이는 칸반에서 “진행 중” 상태에는 최대 2개 아이템만 존재할 수 있음을 의미한다.
스크럼에서는 “진행 중” 열에 한 번에 모든 아이템을 올려놓지 못하게 막을 수 있는 규칙이 없다. 하지만 이터레이션 자체에 업무 범위가 한정돼 있다는 암묵적인 제한은 있다. 책에서 발췌한 그림에서 스크럼 보드에 4개 아이템이 존재하므로 한 열당 최대 아이템 수는 암묵적인 제한은 4개가 된다.
따라서 칸반은 WIP를 직접 제한하는 데 반해 스크럼은 간접적으로 WIP를 제한한다.
스크럼 팀에서는 진행중인 아이템이 너무 많으면 나쁘다라는 것을 점차 학습하게 되며, 새로운 아이템을 시작하기에 앞서 현재 아이템을 끝마치려 노력하는 문화가 생성된다. 심지어 WIP를 명시적으로 제한하기도 한다.(스크럼 보드가 칸반 보드가 되는 순간!)
스크럼과 칸반 모두 방법만 다를 뿐 WIP를 제한하고 있다.
스크럼 팀에서는 속도(Velocity)라는 지표를 측정하여 WIP를 제한한다. 속도는 이터레이션당 완료된 아이템 또는 이에 상응하는 “스토리 포인트” 같은 단위를 얼마나 많은 완료했는지를 나타낸다. 스크럼 팀이 자신들의 속도를 안다는 것은 WIP 리밋 또는 최소한의 가이드 라인을 알고 있다는 것을 의미한다. 예를 들어 평균 속도가 10인 스크럼 팀은 한 스프린트에 10개 이상의 아이템 또는 스토리 포인트를 가져오지 않는다.
칸반에서는 책에서 발췌한 사진처럼 워크플로에서 “진행 중”인 상태에만 제한을 둘 수 도 있지만, 모든 상태에도 제한을 둘 수도 있다. 칸반에서는 모든 워크플로 상태에 WIP 제한을 두는 것이 일반적이다. 즉, 발췌한 사진에서 “할 일”에도 WIP 제한을 둘 수 있다는 이야기이다. WIP를 설정하면 리드 타임, 즉 아이템 하나가 보드를 가로지르는 평균 시간을 측정할 수 있고, 예측할 수 있게 된다. 이렇게 예측 가능한 리드 타임을 얻게 되면 SLA(Service Level Agreement, 서비스 수준 동의)를 약속할 수 있고, 현실적인 출시 계획을 수립할 수 있게 된다.
이렇게 스크럼에서는 WIP를 시간 단위로 제한을 두고 칸반은 WIP를 워크플로 상태별로 제한한다. 중요한 것은 이런 제한을 통해 팀의 속도를 측정과 리듬을 만드는 것이라고 생각한다.
또한 아이템 크기가 제각각이면, 이런 WIP 제한과 예측에 들어가는 시간이 많이 들게 된다. 이런 시간 소모를 줄이기 위해 아이템들을 비슷한 크기로 쪼개는데 노력을 기울이는 팀들도 있다. 아이템이 거의 동일한 크기라면 좀 더 예측 가능하고 부드럽게 흘러가는 시스템을 만들 수 있다.
인사이트
- 스크럼에는 지정된 역할이 있고, 칸반에는 지정된 역할이 없다. 하지만 모두 역할을 자유롭게 추가할 수 있다.
- 스크럼에서는 이터레이션의 상태들이 정해져 있고 칸반에서는 정해져 있지 않다. 하지만 둘다 상태를 자유롭게 추가할 수 있다.
- 역할도 상태도 자유롭게 추가할 수 있지만, 간결할수록 좋다라는 정식을 잊지 말아야한다.
- 스크럼과 칸반 모두 WIP를 제한하고 있다.
- WIP 제한을 통해 팀의 속도 예측과 리듬을 만드는 것이 중요하다.