칸반

애자일 소프트웨어 개발 팀은 이제 진행 중인 작업(WIP)의 양을 팀의 작업 수용량과 일치시켜서 JIT 원칙을 활용할 수 있습니다. 팀은 더욱 유연한 계획 옵션을 확보하고 더 빠르게 결과를 전달하며 지속적 개선에 대한 초점 범위를 명확히 하고 전체 개발 주기를 투명하게 파악할 수 있습니다.

칸반 프레임워크의 핵심 원칙은 시간이 지나도 변하지 않으며 거의 모든 산업에 적용할 수 있지만 동시에 소프트웨어 개발 팀에서는 애자일 관행을 통해 더욱 뛰어난 성과를 이룰 수 있었습니다. 실제 프로세스를 변경하고 상당한 자재를 추가해야 하는 공장에서의 칸반 구현과 달리 소프트웨어 팀에 필요한 유일한 물리적 요소는 보드와 작업 카드이며 이 또한 가상으로 구현할 수 있습니다.

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

팀이 디지털 칸반 보드를 사용하든지 실제 칸반 보드를 사용하든지 상관없이 팀이 작업을 시각화하고 워크플로를 표준화하며 모든 블로커 및 종속성을 즉시 파악하고 해결할 수 있습니다. 기본 칸반 보드에는 해야 할 일, 진행 중 및 완료의 3단계 워크플로가 있습니다. 하지만 팀의 규모, 구조 및 목표에 따라 팀은 고유한 프로세스에 맞게 워크플로를 매핑할 수 있습니다.

칸반 방법론은 작업의 완전한 투명성과 실시간 커뮤니케이션에 의존하므로 칸반 보드는 팀 작업의 단일 정보 출처 역할을 합니다.

칸반을 문자 그대로 일본어로 번역하면 "시각적 신호"입니다. 칸반 팀은 보드에 있는 모든 작업 항목을 별도의 카드로 표현합니다. 작업을 칸반 보드에서 카드로 표시하는 주된 목적은 팀원이 워크플로 전체에서 진행률을 매우 시각적인 방식으로 추적할 수 있도록 하는 것입니다.

칸반 카드에는 프로젝트 작업에 대한 중요한 정보가 포함되어 있어 팀이 누가 어떤 작업을 담당하는지와 작업에 대한 간략한 설명 및 작업에 걸리는 예상 시간을 파악할 수 있습니다. 가상 칸반 보드의 카드에는 스크린샷을 비롯하여 담당자에게 매우 중요한 기타 기술적인 세부 정보가 포함되는 경우가 많습니다.

팀원이 언제든지 각 작업의 상태를 관련 세부 정보와 함께 볼 수 있도록 하면 집중력이 높아지고 종합적인 추적이 가능하며 블로커 및 종속성을 빠르게 파악할 수 있습니다.

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

칸반 팀은 현재 진행 중인 작업에만 집중합니다. 팀이 작업을 완료하면 백로그에서 다음 작업을 선택합니다. 현재 작업 항목 외의 변경은 팀에 영향을 주지 않으므로 제품 소유자는 팀을 방해하지 않고 백로그에서 작업의 우선 순위를 마음껏 다시 지정할 수 있습니다.

제품 소유자가 가장 중요한 작업 항목을 백로그 맨 위에 두면 개발 팀은 비즈니스에 최대한의 가치를 제공하고 있다는 확신을 가질 수 있습니다.

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

기술 집합이 중복되도록 하면 사이클 타임을 단축할 수 있습니다. 특정 기술 집합을 보유한 팀원이 한 명뿐인 경우 해당 팀원이 작업을 처리할 때까지 워크플로에서 병목 현상이 발생합니다. 따라서 팀은 코드 검토 및 멘토링과 같은 모범 사례를 활용하여 지식을 널리 공유합니다. 기술을 공유하면 팀원이 여러 유형의 작업을 수행하게 되므로 사이클 타임을 더욱 최적화할 수 있습니다.

또한 이 접근 방식을 사용하면 팀 전체가 작업 병목 현상을 공동으로 해결하여 신속하게 문제를 해결하고 워크플로를 원활하게 유지할 수 있습니다. 예를 들어 테스트 책임은 QA 엔지니어를 넘어 개발자까지 확대되어 효율성을 유지하기 위한 공동의 노력을 장려합니다. 칸반 시스템에서는 프로세스가 원활하게 진행되는지 팀 전체가 확인합니다.

멀티태스킹은 효율성을 저해합니다. 워크로드가 증가하면 컨텍스트 전환이 더 자주 발생하여 작업을 완료하는 데 방해가 됩니다. 따라서 칸반 프로세스의 핵심 원칙은 진행 중인 작업(WIP)을 제한하는 것입니다. 진행 중인 작업 제한은 집중력, 인력 또는 기술 집합 부족으로 인한 팀 프로세스의 병목 현상을 강조합니다.

예를 들어 일반적인 소프트웨어 팀에는 해야 할 일, 진행 중, 코드 검토 및 완료로 이루어진 4가지 워크플로 상태가 있습니다. 코드 검토 상태에 대해 WIP 제한을 2로 설정할 수 있습니다. 제한이 낮아 보일 수도 있지만 여기에는 그럴만한 이유가 있습니다.

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

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

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

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

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

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

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