칸반

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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