Close

칸반

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

주제 찾아보기
Jira 보드

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

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

템플릿 사용

칸반이란?

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

칸반 문서

[계속]

칸반 흐름으로 소프트웨어 개발 최적화

애자일 및 DevOps 방법론의 기반인 칸반 흐름은 시각화된 워크플로를 통해 원활한 작업 진행을 조율하여 효율성을 높입니다. 칸반 흐름은 슈퍼마켓의 간소화된 재고 관리를 반영하여 필요할 때 개발 프로세스를 통해 작업이 정확하게 진행되도록 합니다.

칸반 보드에 시각화된 작업을 카드로 표시하면 진행률을 투명하게 추적하고 병목 현상을 신속하게 파악할 수 있습니다. 진행 중인 작업(WIP)을 제한함으로써 팀은 리소스 할당을 최적화하고 안정적인 워크플로를 유지합니다. 칸반은 컨트롤 차트 및 누적 흐름 다이어그램과 같은 메트릭을 통해 지속적 개선에 초점을 맞춰 팀이 워크플로를 반복적으로 개선하도록 지원합니다.

소프트웨어 개발에서 칸반 흐름은 동적 작업 관리를 촉진하고 제공 주기를 가속화하고 집중적이며 중단 없는 작업을 통해 고객 만족도를 높입니다. 본질적으로 칸반 흐름은 투명성, 적응성 및 지속적 개선이 조화롭게 어우러진 효율성을 통해 애자일 방법론의 잠재력을 최대한 발휘합니다.

칸반 흐름 구조화

칸반을 효과적으로 구현하려면 소프트웨어 개발 팀 내에 구조화된 칸반 흐름을 구축해야 합니다. 그러면 작업이 원활하게 진행되고 워크플로 관리가 최적화됩니다. 칸반 흐름을 구조화하는 방법은 다음과 같습니다.

워크플로 시각화: 먼저 팀의 워크플로를 칸반 보드에 시각화합니다. 실제 보드든 가상 보드든 작업 시작부터 완료까지 개발 프로세스의 각 단계를 설명해야 합니다.

워크플로 표준화: 팀의 프로세스 및 요구 사항에 따라 워크플로 단계를 정의하고 표준화합니다. 일반적인 단계로는 "해야 할 일", "진행 중" 및 "완료"가 있지만 필요에 따라 고유한 워크플로를 반영하도록 사용자 지정합니다.

블로커 및 종속성 파악: 칸반 보드를 통해 블로커 및 종속성을 즉시 파악할 수 있도록 합니다. 이러한 투명성을 통해 즉각적으로 해결하고 워크플로 중단을 방지할 수 있습니다.

진행 중인 작업(WIP) 제한 설정: 각 워크플로 단계에 WIP 제한을 적용하여 업무 부담을 방지하고 안정적인 워크플로를 유지합니다. WIP 제한은 리소스 할당을 최적화하고 멀티태스킹을 줄여 생산성을 높이는 데 도움이 됩니다.

공동 작업 장려: 팀원이 공동으로 병목 현상을 해결하고 원활한 워크플로 진행을 위해 함께 작업하는 팀 내 공동 작업 문화를 조성합니다. 이러한 공동 작업 중심의 접근 방식은 효율성과 작업 완료 속도를 높여줍니다.

칸반 카드 활용: 보드에 각 작업을 칸반 카드로 표시합니다. 여기에는 작업 설명, 담당자 및 예상 완료 시간과 같은 필수 세부 정보가 포함되어 있습니다. 칸반 카드를 사용하면 작업 진행률을 시각적으로 추적하고 팀 내에서 투명성을 높일 수 있습니다.

이러한 방식으로 칸반 흐름을 구조화하면 소프트웨어 개발 프로세스를 간소화하고 팀 공동 작업을 강화하며 작업 관리의 효율성을 최대화할 수 있습니다.

칸반의 기원 살펴보기

칸반은 오늘날의 애자일 및 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로 설정할 수 있습니다. 제한이 낮아 보일 수도 있지만 여기에는 그럴만한 이유가 있습니다.

개발자는 다른 팀원의 작업을 검토하는 것보다는 새 코드를 작성하는 것을 선호합니다. 제한을 낮게 설정하면 팀이 검토 상태의 이슈에 특히 주의를 기울이고 자신의 코드 검토를 제출하기 전에 다른 팀원의 작업을 검토하게 되어 결과적으로 전반적인 사이클 타임이 줄어듭니다.

시각적 지표

핵심 가치 중 하나는 작업을 반복할 때마다 팀 효율성과 효과성을 지속적으로 개선하는 데 중점을 두는 것입니다. 팀은 차트에서 제공하는 시각적 메커니즘을 통해 계속 개선해 나갈 수 있습니다.

팀에서 데이터를 확인할 수 있으면 프로세스 내의 병목 현상을 더욱 쉽게 발견하고 제거할 수 있습니다. 칸반 팀에서 일반적으로 사용하는 두 가지 보고서는 컨트롤 차트와 누적 흐름 다이어그램입니다. 컨트롤 차트에는 각 이슈의 사이클 타임과 팀의 롤링 평균이 표시됩니다.

프로 팁:

팀의 목표는 이슈가 전체 프로세스를 따라 진행하는 데 걸리는 시간을 줄이는 것입니다. 컨트롤 차트에서 평균 사이클 타임이 낮아진다면 성공한 것입니다.

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

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

누적 흐름 다이어그램

지속적 배포 (Continuous Delivery)

지속적 제공(CD)은 고객에게 작업을 자주 릴리스하는 프로세스를 설명합니다. 지속적 통합(CI)은 하루 동안 자동으로 코드를 점진적으로 만들고 테스트하는 관행입니다. 이들은 함께 DevOps 팀이 뛰어난 품질을 보장하면서 소프트웨어를 더 빠르게 제공하는 데 필수적인 CI/CD 파이프라인을 형성합니다.

칸반과 CD는 모두 가치의 just-in-time(및 한 번에 한 개) 제공에 중점을 두므로 서로 보완적입니다. 팀이 혁신 기술을 시장에 더 빠르게 제공할수록 제품 경쟁력도 더욱 높아집니다. 칸반 팀은 고객에 대한 워크플로를 최적화하는 데 큰 중점을 둡니다.

스크럼과 칸반 비교

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

 

스크럼

칸반

릴리즈 방법론

스크럼

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

칸반

지속적 흐름

역할

스크럼

제품 소유자, 스크럼 마스터, 개발 팀

칸반

지속적 배포 또는 팀의 재량으로

주요 지표

스크럼

속도

칸반

사이클 타임

변경 철학

스크럼

팀은 스프린트 중에 스프린트 예측을 변경하지 않도록 주의해야 합니다. 변경할 경우 추정치에 대해 정확히 파악할 수 없습니다.

칸반

변경은 언제든지 발생할 수 있습니다.

일부 팀에서는 칸반 방법과 스크럼의 장점을 "scrumban"으로 결합합니다. 스크럼에서는 시간이 고정된 스프린트 및 역할을, 칸반에서는 진행 중인 작업 제한과 사이클 타임에 중점을 둡니다.

애자일을 처음 시작하는 팀의 경우 한 가지 방법론을 선택하여 일정 기간 실행하는 것이 좋습니다. 팀에서 칸반 방법론을 사용할 준비가 되었다면 지금 바로 무료 칸반 보드 템플릿을 사용해 보세요!

Jira 보드

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

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

Dan Radigan
Dan Radigan

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

다음 단계
보드