(5) 일일 미팅, 업무 프로세스의 최적화, WIP 제한을 잘 이용하자

블로그 리스트

이 블로그 포스트는 시리즈로 작성되어 있습니다. 다른 내용을 확인하고 싶으신 분들은 아래에 링크를 참고하시기 바랍니다.

• 목차
• (1) 스크럼, 칸반 그리고 도구
• (2) 역할, 이터레이션 그리고 WIP 제한
• (3) 고유의 프로세스, 할일 추가, 보드 초기화
• (4) 교차 기능 팀, 작업 쪼개기, 측정하라 그리고 예측하라
• (5) 일일 미팅, 업무 프로세스의 최적화, WIP 제한을 잘 이용하자
• 칸반과 스크럼을 읽고 나서

스크럼과 칸반의 차이점

스크럼과 칸반은 다음과 같은 차이점들을 가지고 있다.

우선 순위

칸반은 어떤 식으로 우선 순위를 정할지 팀이 결정할 수 있고, WIP 제한에 여유가 생기면 바로 적용이 가능하다. 스크럼과 같이 백로그에 우선 순위가 매겨져 있을 수 있도 있고, 우선 순위가 아예 없을 수도 있다. 따라서 칸반에서는 다음과 같이 팀에서 우선 순위를 결정하는 방법을 정해야 한다.

• 항상 맨 위에 아이템을 가져간다.
• 가장 오래된 아이템을 가져간다.
• 아무 아이템이나 가져간다.
• 대략 20%는 유지 보수 항목을, 80%는 신규 기능에 관한 아이템을 가져간다.
• 여러 제품을 동시에 개발할 때에는, 팀의 역량을 제폼 A와 제품 B에 거의 동등하게 분할한다.

스크럼는 백로그를 정리하는 것으로 우선 순위를 결정하며, 우선 순위를 변경하는 것은 현재 스프린트가 이나라 다음 스프린트에 영향을 미친다. 스크럼에서도 칸반과 비슷한 방법으로 우선 순위를 결정할 수 있다. 백로그 크기에 제한을 둘 수 있고, 우선 순위를 어떻게 부여할지 규칙을 만들 수 있다.

칸반을 사용하던, 스크럼을 사용하던 우선 순위를 매기는 방법에 대해서 정할 필요가 있다.

일일 미팅

스크럼에서는 매일 같은 시간, 같은 장소에서 짧은 미팅(최대 15분)을 한다. 이 미팅의 목적은 일이 어떻게 진행 중인지에 대한 정보 교환과 오늘 할 작업에 대한 계획, 중대한 문제가 있는지 파악하기 위함이다. 이 미팅은 보통 서서 진행하기 때문에 일일 스탠드업 미팅이라고 부른다.

스크럼의 일일 미팅은 사람을 중심으로 진행되며, 한 사람, 한 사람씩 돌아가면서 보고한다.

칸반에서는 일일 미팅에 대해 정의하고 있지 않다. 하지만 대부분의 칸반 팀에서는 스크럼과 같은 일일 스탠드업 미팅을 진행한다. 일일 스탠드업 미팅은 어떤 업무 프로세스와 관계없이 매우 유용하다.

칸반의 일일 미팅은 칸반 보드를 중심으로 진행된다. 병목 지점이나 눈에 보이는 문제들에 초첨을 맞추어 회의를 진행한다. 이는 스크럼의 일일 미팅과는 다르게 모든 사람이 돌아가며 보고를 할 필요가 없으며, 병목 지점이나 문제들에 관해서 보고하면 된다. 물론, 칸반에서는 이렇게 회의를 하라고 정의하지 않고 있으므로, 스크럼과 같은 방식으로 회의를 진행해도 문제없다.

중요한 것은 스크럼을 사용하던, 칸반을 사용하던, 다른 프로세스를 사용하던 일일 미팅을 하는 것이 유용하다는 것이다.

번다운 차트

스크럼에서는 스프린트 번다운 차트를 사용하여 날마다 현재 이터레이션에 얼마나 많은 일이 남아있는지를 확인한다. 이 번다운 차트는 이터레이션의 진척도를 추적하는데 사용되며, 일정보다 지연되는지 아니면 앞서가는지를 쉽고 빠르게 파악할 수 있도록 도와준다.

칸반에서는 어떠한 차트도 정의하고 있지 않다. 이 말은 번다운 차트 등 어떠한 종류의 차트도 사용할 수 있음을 의미한다. 칸반에서는 누적 흐름도(Cumulative FLow Diagram) 등도 많이 사용된다. 중요한 것은 WIP 제한과 리드 타임을 실험하고 측정하면서 최적화에 도움이 된다면, 어떠한 차트를 사용해도 좋다는 것이다. 반대로 WIP 제한과 리드 타임 예측을 잘하고 있다면, 어떠한 차트도 사용하지 않아도 된다는 의미이기도 하다.

대부분의 조직들에서 일을 빨리 끝내기를 원한다. 안타깝게도 대부분의 조직들은 이를 위해 많은 사람을 투입시키거나, 초과 업무를 시킨다. 하지만 업무를 신속하게 끝내기 위한 가장 효과적인 방법은 사람을 더 투입 시키거나, 초과 근무를 시키는 것이 아니라 작업 흐름에 방해가 되는 것을 제거하고, 수용 능력(Capacity)에 맞게 일을 제한하는 등, 업무 프로세스의 최적화를 시키는 것이다.

아무것도 측정할 수 없고, 예측할 수 없는 상태에서 사람을 투입하고 초과 업무를 시킨다고 해서, 좋은 결과를 가져올지, 나쁜 결과를 가져올지 알 수 없다. 우선 측정하고, 예측할 수 있는 상태를 만들고, 업무를 최적화한 후, 사람을 투입시켜 해결될 문제인지, 시간을 투입하면 해결될 문제인지를 파악하는 것이 중요하다.

스크럼과 칸반의 예제

다음 그림들을 통해 스크럼과 칸반을 이해해 보자.

스크럼에서는 다음과 같이 스크럼 보드를 사용할 수 있다.

제품 책임자는 스프린트 백로그를 볼 수만 있고 수정할 수 없다. 제품 백로그는 언제든지 변경할 수 있지만, 이 변경 사항은 다음 스프린트에 영향을 준다.

스프린트 백로그는 팀이 이번 스프린트에서 할 일들을 보여준다. 팀은 이 스프린트 백로그를 사용하여 업무를 진행하며, 스프린트가 종료되면, 팀은 제품 책임자에게 잠재적으로 출시 가능한 코드를 전달한다. 스크럼 팀은 스프린트를 마치고, 리뷰를 실시한 후, 스프린트에서 완료된 기능을 제품 책임자에게 시연한다.

이제 제품 책임자는 이 기능을 제품에 탑재할 것인지 여부를 결정한다. 개발한 기능이 제품에 실제로 탑재되는 것은 통상 스프린트에 포함되지 않기 때문에 위의 스크럼 보드에는 표시되지 않았다.

이제 이 스크럼 보드를 칸반 보드로 나타내보자.

“백로그”에는 우선 순위가 없는 일반적인 희망 사항들이 있다. 그리고 “선택됨” 열에는 우선 순위가 높은 아이템들을 놓게 되는데, 이번 예제에서는 WIP 제한이 2로 설정되어 있다. 팀은 새로운 아이템을 작업할 준비가 되면 “선택됨” 열에서 가장 우선 순위가 높은 아이템을 가져오게 된다.

제품 책임자는 “백로그”와 ‘선택됨” 열은 아무 떄나 변경이 가능하지만, 나머지 열은 변경이 불가능하다.

“개발” 열 하위를 “진행 중”과 “완료”로 나누었다. 이렇게 두 열로 나눈 이유는 제품 출시 팀에서 어떤 아이템들을 가져올 수 있는지 알 수 있게 하기 위함이다.

“진행 중” 열과 “완료” 열에 각각 WIP 제한을 주지 않고 “개발”이라는 상위 열에 WIP 제한을 주었다. 이렇게 제한을 준 이유는 제품 출시 팀이 제품을 출시하지 못하면, 개발 팀에서 제품 출시를 지원할 수 있도록 돕기 위함이다.

이제 이렇게 정의한 칸반 프로세스를 자세히 살펴보자.

칸반의 업무 프로세스를 살펴보면, 우선 개발하고자 하는 제품에 대한 아이템들을 세분화 하여 “백로그”에 준비해 둔다.

제품 책임자는 이렇게 준비된 “백로그”에서 우선 순위가 높은 아이템을 “선택됨”으로 옮긴다. 제품 책임자는 새로운 아이템이 추가 등, 여러 이유로 “백로그”에서 “선택됨”으로 “선택됨”에서 “백로그”로 아이템을 옮길 수 있다. 하지만 “선택됨”에는 WIP 제한이 있으므로, 한 번에 여러 개의 아이템을 추가할 수 없다.

개발 팀에서는 제품 책임자가 “선택됨”으로 옮겨둔 아이템중에서 우선 순위가 높은 아이템부터 가져와 개발을 시작한다. 개발 팀의 수용 능력 등을 고려하여 “개발”의 WIP 제한을 결정해야 한다. 이 예제에서는 WIP 제한을 2로 설정하였따. 그러므로 여러 멤버들이 같이 하나에 아이템을 협업하여 작업하게 된다.

개발팀은 멤버들의 협업을 통해 새로운 개발을 진행하며, 개발이 완료되면 아이템을 “진행 중”에서 “완료”로 이동 시키게 된다. 이렇게 “완료”에 새로운 아이템이 추가되면, 배포 팀에서는 이제 “완료”에 추가된 아이템을 배포할 준비를 한다.

배포팀에서 “완료”에 있는 아이템을 “배포”로 옮겨 배포 작업을 진행한다. 배포 팀이 배포를 위해 아이템을 “완료”에서 “배포”로 이동 시키면, 개발 팀의 WIP 제한에 여유가 생기므로 개발 팀에서는 새로운 아이템을 가져와 작업을 할 수 있다.

만약, 배포 팀에서 개발 팀이 완료한 아이템이 제대로 배포가 되지 않는다면 어떤 일이 벌어질까? 일단, 배포 팀은 배포를 하기 위해 열심히 노력할 것이고, 개발 팀은 현재 개발에 집중할 것이다.

그리고 개발 팀에서 개발이 다 끝나면, 새로운 아이템을 가져오려고 할 것이다. 하지만 WIP 제한에 의해, 개발 팀은 새로운 아이템을 가져올 수 없게 된다. 그럼 개발 팀에서 칸반 보드를 보고, 병목 현상이 발생하는 부분을 찾을 것이다.

현재 “배포”에서 문제가 발생하여 배포 팀이 배포를 진행하지 못하고 있고, 이 때문에 개발을 진행하지 못하고 있다. 따라서, 개발 팀은 배포 팀을 도와 병목 현상을 제거하려 노력할 것이다.

이 떄, 고객의 요구 사항으로 인해, 먼저 처리해야하는 아이템이 발생했다고 가정하자. 이렇게 우선 순위가 높은 아이템이 발생하면, 제품 책임자는 우선 적으로 진행할 아이템을 “선택 됨”으로 옮길 수 있다.

“개발” 항목의 WIP 제한이 2로 설정되었기 때문에, 우선 처리해야할 아이템이 발생하여도, 개발을 진행할 수 없는 상황이다. 이런 상황에서 개발 팀이 담당하던 아이템이 완료되어 “완료”로 이동되었다. 이때 제품 책임자는 개발 팀에게 고객의 요구 사항으로 이 아이템을 먼저 처리해줬으면 좋겠다고 전달한다. 하지만 개발 팀에서는 WIP 제한이 있고 이 아이템을 현재 진행할 수 없다고 이야기 한다. 그리고 여유가 생긴 개발 팀도, 병목 현상이 발생하는 부분을 확인한다.

병목 현상을 확인한 결과, 배포 팀에서 아직도 배포를 진행하지 못하고 있다는 것을 확인하였다. 이제 여유가 생긴 개발 팀에서 해당 병목 현상을 해결하기 위해 배포 팀을 돕기 시작한다.

제품 책임자는 계속 들어오는 고객의 요구 사항으로 처리하고자 아이템을 “백로그”에서 “선택됨”으로 옮기고 싶어한다. 하지만 WIP 제한때문에 자신의 업무가 진행되지 못하는 것을 알게 되었다.

이렇게 자신의 업무가 WIP 제한에 의해 진행되지 못하면, 병목 현상을 찾아 나서게 되고, 개발자는 아니지만 자신이 할 수 있는 일이 있는지 배포 팀과 개발 팀과 커뮤니케이션을 하게 된다.

칸반에서는 이런 일이 반복적으로 발생하며 WIP 제한을 통해 병목 현상을 찾을 수 있고, 업무의 문제점과 프로세스의 최적화를 진행할 수 있다.

여기서 소개한 예제는 하나의 예시일 뿐이다. 반드시 칸반에서 이렇게 보드를 구성해야 한다고 이야기 하는 것이 아니다. 이 팀은 스크럼을 진행하였고, 해당 스크럼을 좀 더 세분화하여 칸반 보드로 변경하였고, 스크럼에서 칸반으로 이동한 케이스이다. 여러분은 여러분만의 상황과 환경을 고려하여 칸반 보드를 구성해야할 것이다.

처음에는 최대한 단순한 칸반 보드 구성을 추천한다. 그 후, 업무 프로세스를 최적화해 나가면서 칸반 보드의 항목도 수정해 나가는 것을 추천한다.

스크럼과 칸반

스크럼과 칸반을 비교하여 요약하면 다음과 같다.

비슷한 점

스크럼과 칸반은 다음과 같은 유사점을 가지고 있다.

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

다른 점

스크럼과 칸반은 다음과 같은 차이점을 가지고 있다.

인사이트

• 우선 순위를 결정하는 방법이 필요하다.
• 일일 미팅은 중요하다. 단, 어떤 목적으로 실행할지 결정해서 진행하자.
• 사람이 많이 투입되면 해결되는 문제인지, 시간이 많이 투입되면 해결되는 문제인지 파악할 수 있는 업무 프로세스를 구축하라.
• 업무 프로세스를 최적화하라.
• 칸반 보드는 최대한 단순한 열 구성으로 시작하고, 업무 프로세스 최적화를 진행하면서 필요한 열을 추가하라.
• WIP 제한을 통해 병목 지점을 찾아라.

Github Sponsor Buy me a coffee