Close

칸반

소프트웨어 개발에 칸반 방법론이 적용되는 방식

주제 찾아보기
Jira 보드

Jira의 칸반 템플릿 무료로 시작하기

가장 중요한 작업을 확인하고 진행하여 효율성을 최대화하세요.

템플릿 사용

칸반이란?

칸반은 애자일DevOps 소프트웨어 개발 구현에 많이 사용되는 프레임워크입니다. 작업 수용량에 대한 실시간 커뮤니케이션과 작업의 완전한 투명성이 요구됩니다. 작업 항목은 칸반 보드에 시각적으로 표시되므로 팀원은 언제든지 모든 작업 상태를 볼 수 있습니다.

칸반 문서

[계속]

칸반은 오늘날의 애자일 및 DevOps 소프트웨어 팀 사이에서 널리 주목받고 있지만, 작업의 칸반 방법론이 시작된 것은 50여 년 전으로 거슬러 올라갑니다. 1940년대 말에 Toyota에서는 슈퍼마켓에서 진열대에 제품을 채우는 데 사용한 것과 동일한 모델을 바탕으로 엔지니어링 프로세스를 최적화하기 시작했습니다. 슈퍼마켓은 고객의 수요를 충족시키기 위해 충분한 양의 제품을 채워둡니다. 이것은 슈퍼마켓과 고객 간의 흐름을 최적화하기 위한 관행입니다. 재고 수준이 소비 패턴과 일치하므로, 슈퍼마켓은 특정 시점에 보유하게 되는 초과 재고 수량을 줄임으로써 재고 관리의 효율성을 크게 향상시킵니다. 동시에 슈퍼마켓은 고객이 필요로 하는 특정 제품의 재고를 항상 보유할 수 있습니다.

Toyota에서 이와 같은 시스템을 공장에 적용했을 때, 목표는 대량의 재고 수준을 실제 자재 소비에 맞춰 더 낫게 정렬하는 것이었습니다. 공장(및 공급업체)에 생산 능력을 실시간으로 알리기 위해 작업자들은 팀 간에 "칸반"이라는 카드를 전달했습니다. 생산 라인에서 사용 중인 자재함이 비워지면 필요한 자재, 필요한 자재의 정확한 양 등을 설명하는 칸반이 창고에 전달되었습니다. 창고에서는 새 자재함을 대기시켰다가 공장으로 보냈고, 창고 측의 칸반을 공급업체에 보냈습니다. 공급업체에서도 창고로 배송하기 위해 이러한 자재함을 대기시켰습니다. 1940년대부터 이 프로세스의 신호 기술이 계속 발전했지만, 이 "Just in time"(또는 JIT) 제조 프로세스는 여전히 가장 중요한 사항입니다.

소프트웨어 팀을 위한 칸반

애자일 소프트웨어 개발 팀은 이제 진행 중인 업무(WIP)의 양을 팀의 생산 능력과 일치시켜서 동일한 JIT 원칙을 활용할 수 있습니다. 팀은 더욱 유연한 계획 옵션을 확보하고, 더 빠르게 결과를 전달하며, 초점 범위를 명확히 하고, 전체 개발 사이클을 투명하게 합니다.

칸반 보드 | Atlassian 애자일 코치

이 프레임워크의 핵심 원칙은 시간이 지나도 변하지 않으며 거의 모든 산업에 적용할 수 있지만, 동시에 소프트웨어 개발 팀에서는 애자일 프랙티스를 이용해 보다 뛰어난 성과를 이룰 수 있었습니다. 이 성과 달성 요인은 소프트웨어 팀이 기본 원칙을 이해하기만 하면 거의 오버헤드 없이 프랙티스를 이용할 수 있다는 점입니다. 실제 프로세스가 변경되고 실제 자재가 포함되는 공장에서의 칸반 구현과 달리, 소프트웨어 팀에 필요한 실제 물건은 보드와 카드이며, 이 또한 가상으로 구현할 수 있습니다.

칸반 보드

모든 칸반 팀의 업무는 업무를 시각화하고 팀 간 워크플로우를 최적화하는 데 사용되는 도구인 칸반 보드를 중심으로 이루어집니다. 실제 보드를 선호하는 팀도 있지만, 가상 보드는 애자일 소프트웨어 개발 도구에서 추적성, 용이한 협업, 여러 위치에서의 접근성에 필요한 중요한 기능입니다.

팀에서 실제 보드를 사용하든지, 디지털 보드를 사용하든지 관계없이, 이를 사용하여 팀 업무를 시각화하고, 워크플로우를 표준화하며, 모든 장애물 및 종속성을 즉시 식별하고 해결할 수 있습니다. 기본 칸반 보드에는 수행할 작업, 진행 중인 작업, 완료된 작업의 3단계로 구성된 워크플로우가 포함되어 있습니다. 그러나 팀의 규모, 구조 및 목표에 따라 워크플로우를 매핑하여 특정 팀의 고유 프로세스를 따를 수 있습니다.

칸반 방법론은 작업의 완전한 투명성과 수용 작용량의 실시간 커뮤니케이션에 의존합니다. 따라서 칸반 보드는 팀 작업의 단일 정보 소스로 간주되어야 합니다.

애자일 칸반 보드 | Atlassian 애자일 코치

칸반 카드

칸반을 문자 그대로 일본어로 번역하면 "시각적 신호"입니다. 칸반 팀에게 모든 업무 항목이 보드에 개별 카드로 표시됩니다.

업무를 칸반 보드에서 카드로 표시하는 주요 목적은 팀원들이 워크플로우 전체에서 업무의 진행 상황을 매우 시각적인 방식으로 트래킹할 수 있도록 하는 것입니다. 칸반 카드는 특정 업무 항목에 대한 중요 정보를 담고 있으며, 팀 전체에 해당 업무 항목의 담당자, 완료된 작업의 간략한 설명, 해당 업무의 예상 소요 시간 등에 대한 완벽한 가시성을 제공합니다. 가상 칸반 보드의 카드에는 종종 스크린샷을 비롯하여 피할당자에게 매우 중요한 기타 기술적인 세부 정보도 포함됩니다. 팀원들이 언제든지 모든 업무 항목의 상태와 모든 관련 세부 정보를 확인할 수 있으므로 집중도가 높아지고 추적성이 향상되며 장애물과 종속성을 더 빨리 식별할 수 있습니다.

칸반의 장점

칸반은 오늘날 애자일 팀에게 가장 사랑받는 소프트웨어 개발 방법론 중 하나입니다. 팀 규모와 관계없이 칸반은 작업 계획 및 처리량 측면에서 여러 가지 장점을 추가로 제공합니다.

기획 유연성

칸반 팀은 현재 진행 중인 업무에만 집중합니다. 팀이 하나의 업무 항목을 완료하면 다음 업무 항목을 백로그의 맨 위에서 옮깁니다. 현재 업무 항목 외의 변경은 팀에 영향을 주지 않으므로 제품 소유자는 팀을 방해하지 않고 백로그에서 업무 우선 순위를 마음껏 다시 지정할 수 있습니다. 제품 소유자가 가장 중요한 작업 항목을 백로그 맨 위에 두면 개발 팀은 최대의 가치를 비즈니스에 다시 제공할 수 있습니다. 따라서 스크럼과 같이 시간이 고정된 반복이 필요 없습니다.

프로 팁:

유능한 제품 소유자는 백로그를 변경을 고려할 때 항상 개발 팀과 상의합니다. 예를 들어, 사용자 스토리 1~6이 백로그에 있는 경우, 사용자 스토리 6의 추정은 사용자 스토리 1~5의 완료에 따라 다를 수 있습니다. 항상 변경 사항을 엔지니어링 팀에 확인하여 예측 가능하게 하는 것이 모범 사례입니다.

시간 주기 단축

사이클 타임은 칸반 팀에게 중요한 메트릭입니다. 사이클 타임은 특정 업무 단위가 업무 시작 시점부터 제공 시점까지 팀의 전체 워크플로우를 따라 이동하는 데 소요되는 시간입니다. 사이클 타임을 최적화여 팀은 향후 업무의 제공을 확실하게 예측할 수 있습니다.

여러 스킬셋을 중첩시켜서 사이클 타임을 단축시킬 수 있습니다. 특정 스킬셋을 보유한 사용자가 한 명뿐인 경우 해당 팀원이 업무를 처리할 때까지 워크플로우상 이후 처리가 지연됩니다. 따라서 팀은 코드 리뷰 및 멘토링 지원과 같은 기본 모범 사례를 채택하여 지식을 널리 공유합니다. 스킬을 공유하면 팀원들이 여러 종류의 업무를 수행할 수 있게 되므로 사이클 타임의 최적화 수준을 향상시킬 수 있습니다. 또한 업무 병목 현상이 있는 경우 전체 팀이 그 업무에 매달려 프로세스 흐름을 다시 원활하게 할 수 있습니다. 예를 들어, QA 엔지니어만 테스트를 수행하는 것이 아니라 개발자도 참여합니다.

칸반 프레임워크에서는 전반적인 프로세스에서 업무가 원활하게 진행되는지 확인하는 것은 모든 팀원의 책임입니다.

병목 감소

멀티태스킹은 효율성을 저해합니다. 특정 시간에 진행 중인 업무 항목의 수가 많을수록 맥락이 자주 바뀌어 완료하는 데 더 많은 시간이 소요됩니다. 이러한 이유로 인해 칸반은 진행 중인 업무(WIP)의 양을 제한하는 데 중점을 둡니다. 진행 중인 업무은 집중도, 인원 또는 기술 세트의 부족으로 인한 팀 내 프로세스의 병목 및 백업을 강조 표시합니다.

예를 들어, 일반적인 소프트웨어 팀에는 해야 할 일, 진행 중, 코드 검토 및 완료로 이루어진 4가지 워크플로우 상태가 있습니다. 코드 검토 상태에 대해 WIP 제한을 2로 설정할 수 있습니다. 제한이 낮은 것처럼 보일 수 있지만, 개발자들은 다른 팀원의 작업을 검토하는 것보다는 새 코드를 작성하는 것을 선호하므로 2로 설정하는 것이 적절합니다. 제한을 낮게 설정하면 팀은 검토 상태의 이슈에 특히 주의를 기울이고, 자신의 코드 검토를 올리기 전에 다른 팀원의 작업을 검토하도록 할 수 있습니다. 이는 결과적으로 전체 사이클 타임을 단축시킵니다.

시각적 지표

핵심 가치 중 하나는 모든 업무 반복을 통해 팀의 효율성 및 효과를 지속적으로 향상시키는 데 집중하는 것입니다. 팀은 차트에서 제공하는 시각적 메커니즘을 통해 계속 개선해 나갈 수 있습니다. 팀에서 데이터를 확인할 수 있으면 프로세스 내의 병목을 더 쉽게 발견하고 제거할 수 있습니다. 칸반 팀에서 공통적으로 사용하는 두 가지 보고서는 컨트롤 차트 및 누적 흐름도입니다.

컨트롤 차트에서 각 이슈의 사이클 타임 및 팀의 롤링 평균을 확인할 수 있습니다.

프로 팁:

팀의 목표는 이슈가 전체 프로세스를 통과하는 데 소요되는 시간을 줄이는 것입니다. 컨트롤 차트에서 평균 사이클 타임이 확연히 낮아진다면 성공적임을 의미합니다.

애자일 컨트롤 차트 | Atlassian 애자일 코치

누적 흐름 다이어그램에는 각 상태의 이슈의 수를 표시합니다. 팀은 특정 상태의 이슈 수의 증가를 확인하여 블로커를 쉽게 찾아낼 수 있습니다. "진행 중" 또는 "검토 중"과 같은 중간 상태의 이슈는 아직 고객에게 제공하지 않은 것이며 이런 상태의 블록커로 인해 작업이 업스트림에 병합될 때 대량의 통합 충돌이 발생할 가능성이 증가할 수 있습니다.

누적 흐름 다이어그램

지속적 배포 (Continuous Delivery)

CD(지속적 배포)는 고객에게 작업을 자주 릴리스하는 관행입니다. CI(지속적 통합)는 하루 언제든지 코드를 점진적으로 자동으로 빌드하고 테스트하는 관행입니다. 이들은 함께 개발 팀(특히, DevOps 팀)이 소프트웨어를 더 빠르게 릴리스하는 동시에 고품질을 보장하는 데 필수적인 CI/CD 파이프라인을 형성합니다.

칸반과 CD는 모두 가치의 Just-in-time(및 한 번에 한 개) 제공에 집중하는 기술이므로 서로 보완적입니다. 팀이 더 빠르게 혁신을 시장에 제공할수록 시장에서 제품은 우수한 경쟁력을 확보합니다. 또한 칸반 팀은 정확하게 이 부분(제품이 고객에게 도달하기까지의 워크플로우를 최적화)에만 집중합니다.

스크럼과 칸반 비교

칸반과 스크럼은 일부 개념은 공유하지만 접근 방식은 매우 다릅니다. 이 둘을 서로 혼동해서는 안 됩니다.

스크럼

칸반
간격

정기적이고 시간이 고정된 스프린트(즉, 2주)

지속적 흐름
릴리즈 방법론 제품 소유자의 승인이 있는 경우 각 스프린트 종료 시 지속적 배포 또는 팀의 재량으로
역할 제품 소유자, 스크럼 마스터, 개발 팀 기존 역할이 없습니다. 일부 팀에서 애자일 코치의 도움을 요청합니다.
주요 지표 속도 사이클 타임
변경 철학 팀은 스프린트 중에 스프린트 예측을 변경하지 않도록 주의해야 합니다. 이를 변경하면 추정에 대해 정확히 파악할 수 없습니다. 변경은 언제든지 발생할 수 있습니다.

일부 팀에서는 칸반과 스크럼의 장점을 "Scrumban"으로 결합합니다. 스크럼에서는 시간이 고정된 스프린트 및 역할을, 칸반에서는 진행 중인 업무 제한에 대한과 사이클 타임을 채택한 것입니다. 그러나 애자일을 처음 시작하는 팀의 경우 두 가지 방법론 중 하나를 선택하여 일정 기간 실행하는 것이 좋습니다. 나중에 언제든지 특이한 방식을 사용할 수 있습니다.

Jira 보드

Jira 칸반 템플릿 무료로 시작하기

가장 중요한 작업을 확인하고 진행하여 효율성을 최대화하세요.

Dan Radigan
Dan Radigan

저는 일에서나 개인적으로나 애자일에 큰 영향을 받았으며, 애자일을 통해 코딩을 할 때도, 삶에서도 최고의 경험을 누릴 수 있었습니다. 저는 기술, 사진 및 모터사이클에 깊은 관심이 있습니다. 

다음 단계
보드