Github Project 칸반

유아현·2023년 2월 14일

Git & Github

목록 보기

7/12

팀 개발 프로젝트는 여러 인원이 함께 업무를 처리한다. 취미로 만드는 사이드 프로젝트는 혼자 기획하고 개발해도 문제가 없으나, 타겟 사용자가 있고 해당 사용자가 돈을 지불할 만한 상용 웹 애플리케이션을 만들려면 많은 사람이 함께 모여서 일해야 한다. 이렇게 여러 직군이 모여서 함께 개발을 하다 보니 자연스럽게 협업 방식이나 업무 관리 방식에 대한 많은 논의가 생겨났다. 칸반도 이런 논의 중 생겨난 하나의 업무 관리 방식 중 하나이다.

📌 칸반이란?

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

🔥 칸반 보드를 통한 시각화

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

[그림] 칸반 보드

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

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

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

[그림] 칸반 보드의 WIP 제한

🔥 업무 흐름 관리

WIP를 두는 이유는 무엇일까? 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위해서이다. 모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게 된다. 막히는 고속도로에 계속해서 차가 진입하여 속도가 더 느려지는 현상에 비유할 수 있다. 즉, WIP 제한은 고속도로 진입로에서 종종 볼 수 있는 신호등과 같은 역할을 한다.

🔥 진행중인 업무 제한

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

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

🔥 명확한 팀 정책을 설정

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

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

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

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

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

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

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

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