Github Project 칸반보드

jung_ho9 개발일지·2023년 2월 14일

Git&Github

Github | Git

목록 보기

5/10

칸반이란 ?

칸반은 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법이다.

칸반 보드를 통한 시각화

칸반의 대표적인 특징은 칸반 보드를 통한 업무 시각화다. 칸반 보드는 아래 사진처럼 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현한다. 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되어 쌓이는 방식이다. 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악할 수 있다.

이렇게 한눈에 업무를 파악할 수 있게 되면 각 팀원이 다른 팀원이 어떤 일을 하고 있는지 투명하게 확인할 수 있고, 문서 파일에 쌓여있는 업무 현황보다 훨씬 더 종합적이고 빠르게 업무 흐름을 파악할 수 있다.

Work In Progress(WIP)로 진행중인 업무 제한 및 흐름 관리

WIP는 현재 진행하고 있는 작업을 의미한다. 칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있다. WIP 제한이 2이면, 두 개 이상의 카드가 해당 열에 위치할 수 없게 된다. 아래 예시의 경우 하나의 업무를 추가할 수 있다.

업무 흐름 관리

WIP를 두는 이유는 무엇일까요? 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위해서다. 모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게 된다.

진행중인 업무 제한

특히 개발 프로젝트는 타 업무와 달리 맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가한다. 제조업 업무는 어떻게 해서든 기계 가동률을 높이거나 일부 생산을 아웃소싱하면 더 짧은 기간 내에 산출물을 만들 수도 있다. 하지만 개발 업무는 지식 업무에 해당하기 때문에 밤새 야근하거나 인원을 더 많이 투입한다고 해서 더 좋은 퀄리티의 산출물이 더 빠른 시간 안에 나오지는 않는다. 특히 소통이 많이 필요한 개발 프로젝트의 경우 인원수가 늘어난다고 해서 소요 기간이 드라마틱하게 증가하지는 않는다.

즉, WIP 제한은 한 번에 처리하는 업무의 양을 최소화하여 팀원이 한 번에 여러 업무를 동시에 진행해서 생기는 맥락 전환의 문제를 방지할 수 있고, 업무 흐름을 적당하게 유지시켜 업무가 차근차근 처리될 수 있도록 한다.

명확한 팀 정책을 설정

칸반을 잘 활용하기 위해서는 정책을 설정해야 한다. 칸반의 열을 정의하고 WIP limit을 세우는 것부터, 언제 회의를 하고 어떻게 의사결정을 할지 명확한 정책을 수립해야 한다. 정책 수립 시에는 팀원이 모두 모여서 합의를 이뤄야 한다. 그리고 이렇게 합의한 정책은 향후 업무 진행 상황에 따라서 팀원들이 모여서 언제든지 다시 조정할 수 있다.

프로젝트가 본격적으로 시작하기 전에 정하면 좋을 정책은 아래와 같다/

회의 시간 및 해당 회의에서 논의할 내용
팀원 간 소통 원칙
칸반 티켓을 언제, 어떻게, 누가 추가할지
WIP 제한

회의와 리뷰를 통해 함께 업무를 개선

보통 칸반을 사용하는 경우, 데일리 칸반 회의와 주간 보충 회의를 진행한다.

데일리 칸반 회의는 업무의 상태 및 흐름을 관찰하고 추적한다. 어떻게 하면 구현하고자 하는 기능을 좀 더 빠르게 구현할 수 있을지, 업무가 끝난 인원이 다른 업무를 당겨올 수 있는지 등을 정할 수 있다. 예를 들면, 프론트엔드 개발자 A가 게시판 CRUD 사용자 인터페이스를 모두 다 구현해서 시간이 충분한 경우, 백로그에 있는 다른 프론트엔드 작업을 가져와서 하거나, WIP에 있는 다른 프론트엔드 개발자 B의 업무를 도와 집중하여 끝낼 수 있게 돕는다던지의 의사결정을 할 수 있다.

주간 보충 회의에서는, 칸반 보드에 추가할 만한 업무가 있는지 확인하고, 다음 주에는 어떤 업무를 할 것인지 정할 수 있다. 예를 들면, 프로젝트 진행 상황이 매우 원활하여, 추가로 구현하기로 했던 기능을 구현할 수 있게 된 경우에는 주간 보충 회의를 통해 해당 기능 구현 티켓을 칸반 보드에 추가할 수 있다.

추가로 격주, 혹은 월간으로 KPT 회고를 진행할 수도 있는데, 지금까지의 진행 상황에 대해서 솔직하게 회고하고, 어떻게 하면 좀 더 잘할 수 있을지 개선점을 찾을 수도 있다.

칸반 실천법

지금까지 칸반에 대한 설명은 칸반의 6가지 실천법을 풀어서 설명하고 정리하면 아래와 같다.

업무 시각화
진행 중인 업무 제한
흐름 관리
명확한 프로세스 정책
피드백 루프 구현
협력적인 개선, 실험적인 발전

칸반 원칙

위에서 언급한 칸반 실천법은 모두 칸반 원칙을 잘 지키기 위해서 만들어졌다. 즉, 해당 구성 요소를 기계적으로 충족시키려고 하기보다는, 종종은 칸반 원칙으로 되돌아와서 지금 하고 있는 작업이 칸반 원칙에 잘 맞는지 고민을 해봐야 한다.

점진적인 변화를 추구

칸반은 당장의 업무 내용이나 방향성을 갑자기 뒤엎고 화려하고 멋진 기획을 만들기 위한 수단이 아닙니다. 현재 하고 있던 일이나 업무를 잘 수행하기 위한 하나의 수단입니다. 칸반을 위해서 갑작스럽게 업무 방식을 극적으로 변화시키지 말아야 합니다. Pre-Project에서도 칸반을 적용하는 게 어려울 수 있습니다. 당장 내가 할 일부터 하나씩 칸반에 올려두는 것부터 시작하세요.

직위에 관계 없이 리더십을 발휘

칸반은 팀장만 관리하는 것은 아니다. 각 팀원도 칸반을 보고 WIP 제한을 늘리거나 줄이는 것을 제안할 수 있고, 새로운 업무 티켓을 발행하거나 기존 업무 티켓의 진행을 도울 수 있다. Pre-Project에서도 팀원 모두가 합심해서 리더십을 발휘해야 한다. 아쉽게도 프론트엔드 개발자와 백엔드 개발자가 개발 단계에서는 직무 간 도움을 주기는 쉽지 않다. 다만 API 설계나 요구사항 명세서를 적는 기획 단계에서는 서로 어떤 기능을 더 구현하고 덜 구현할지 충분히 제안하고 의견을 나눌 수 있다.