칸반과 스크럼 비교: 어떤 애자일을 사용합니까?

요약: 칸반은 시각적 작업에 의존하여 워크플로를 관리하는 프로젝트 관리 프레임워크이고 스크럼은 팀이 일련의 가치, 원칙 및 관행을 바탕으로 업무를 구조화하고 관리하도록 지원하는 프로젝트 관리 프레임워크입니다.

애자일은 북극성 역할을 하는 일련의 이상과 원칙입니다. DevOps는 소프트웨어 개발 팀과 운영 팀 간의 프로세스를 자동화하고 통합하는 방법입니다. 애자일 및 DevOps를 구현할 때 칸반과 스크럼은 다양한 방법을 제공합니다.

스크럼 방식과 칸반 방식의 차이점은 쉽게 지적할 수 있지만 이는 표면적인 차원에 불과합니다. 관행은 다르지만 원칙은 거의 동일합니다. 두 개 프레임워크는 모두 골칫거리를 줄이면서 더 나은 제품(및 서비스)을 구축하는 데 도움이 됩니다.

그럼 다시 설명하겠습니다.

애자일은 프로젝트 관리 및 제품 개발에 대한 체계적이고 반복적인 접근 방식입니다. 제품 개발의 변동성을 인식하고 자체적으로 구성한 팀이 선을 넘지 않고 변화에 대응할 수 있는 방법론을 제공합니다. 오늘날 애자일은 더 이상 경쟁 우위가 아닙니다. 블랙박스에서 몇 년 또는 몇 달 동안 제품을 개발하고 있을 정도로 여유로운 곳은 없습니다. 즉, 제대로하는 것이 그 어느 때보 다 중요해졌습니다.

칸반은 작업을 시각화하고 진행 중인 작업을 제한하며 효율성(또는 흐름)을 최대화하는 것입니다.칸반 팀은 처음부터 끝까지 프로젝트(또는 사용자 스토리)에 걸리는 시간을 줄이는 데 중점을 둡니다. 칸반 보드를 사용하고 작업 흐름을 지속적으로 개선하여 가능합니다.

스크럼 팀은 스프린트라고 하는 정해진 간격을 통해 제공 가능한 작업 증분을 완료하기로 이행을 약속합니다.스크럼 팀의 목표는 고객 피드백을 빠르게 수집하고 통합하는 학습 루프를 만드는 것입니다. 스크럼 팀은 특정 역할을 채택하고, 특별한 아티팩트를 만들고, 일을 계속 진행하기 위해 정기적인 세레모니를 개최합니다. 스크럼은 스크럼 가이드에 가장 잘 정의되어 있습니다.

Jira 템플릿은 가장 적합한 프로젝트 관리 프레임워크가 무엇이든 빠르게 구성하고 실행할 수 있도록 도와줍니다. Jira의 스크럼 템플릿 또는 칸반 보드 템플릿을 확인하세요. 두 가지 모두 무료로 사용할 수 있습니다.

스크럼을 사용하면 팀은 각 스프린트가 끝날 때까지 의미 있는 작업 증분을 제공할 것을 약속합니다. 스크럼은 경험을 기반으로 구축되어, 고객으로부터 배우고 다음에 수행할 작업을 더 잘 알리는 데 도움이 되는 작은 작업 증분에 중점을 둡니다. 자세히 살펴보면 다음과 같습니다.

스크럼은 일반적으로 1~4주 동안 지속되는 스프린트와 함께 빠른 속도로 움직이며 시작 및 종료 날짜가 명확합니다. 짧은 시간 프레임으로 인해 복잡한 작업이 더 작은 스토리로 분할되어 팀이 빠르게 학습할 수 있습니다. 팀에서 사용 가능한 코드를 그렇게 빨리 제공할 수 있는가가 중요한 질문입니다.

스프린트에는 스프린트 계획, 스프린트 검토 및 회고 회의가 있고 매일 스크럼(스탠드업) 회의가 더해집니다. 이러한 스크럼 세레모니는 간략하고 지속적으로 진행됩니다.

스크럼에는 세 가지 역할이 명확하게 정의되어 있습니다.

• 제품 소유자는 고객을 옹호하고, 제품 백로그를 관리하며 개발 팀이 수행한 작업의 우선 순위를 정하는 데 도움을 줍니다.
• 스크럼 마스터는 팀이 스크럼 원칙을 벗어나지 않도록 도와줍니다.
• 개발 팀은 수행할 작업을 선택하고, 증분을 제공하며, 집단적 책임을 입증합니다.

그럼 스크럼 팀은 누가 관리합니까? 사실 관리하는 담당자는 없습니다. 스크럼 팀은 자기 조직적이며, 다른 책임이 있지만 모두가 평등합니다. 이 팀은 고객에게 가치를 제공한다는 목표로 하나가 됩니다.

스크럼 메트릭은 스크럼 팀이 효율성과 효과성을 개선하는 데 사용할 수 있는 데이터 포인트입니다. 이 메트릭은 의사 결정에 정보를 제공하고 팀이 계획 및 실행을 보다 효율적으로 수행하도록 지원합니다. 스프린트 계획 단계에서 팀은 스프린트 목표, 팀 속도, 팀 작업 수용량 및 작업 유형과 같은 메트릭을 사용할 수 있습니다. 스탠드업 중에 팀은 스프린트 목표에 대한 진행률 측정, 스프린트 번다운 차트 검토, 워크로드 분산 이해 등의 장점을 누릴 수 있습니다.

팀은 스프린트 시간 경계 내에서 얼마나 많은 성과를 거둘 수 있을지 이해하려고 노력합니다. 그들은 스프린트 내에서 제공을 이행하기로 약속합니다. 그러나 스크럼 팀은 최고의 고객 가치를 제공하기 위해 스프린트를 전환하고 변경하도록 장려하는 고객 피드백을 받을 수 있습니다. 변경으로 인해 잠재적으로 제공 가능한 증분이 위험해질 수 있기 때문에 스프린트 회고 중에 스크럼 팀은 향후 변경을 제한하는 방법에 대해 논의해야 합니다. 팀이 스프린트 중에 범위를 자주 변경하는 경우 제대로 이해되지 않은 작업을 선택했다는 의미일 수 있습니다. 또한 팀에 계획을 방해하는 운영/계획 불가 작업이 있음을 의미할 수도 있습니다.

스크럼 방법론에 대한 자세한 내용은 스크럼이란 무엇입니까?를 참조하세요.

칸반을 사용하면 작업을 시각화하고, WIP(진행 중인 작업)를 제한하며, 작업을 '수행 중'에서 '완료'로 빠르게 이동할 수 있습니다.

칸반은 우선 순위와 크기가 다른 수신 요청이 많은 팀에 적합합니다. 스크럼 프로세스는 범위 내 항목을 정확하게 제어하는 것이 필요한 반면에 칸반은 흐름을 따르게 합니다. 결정을 내리는 데 도움이 되는 동일한 다섯 가지 고려 사항을 살펴보겠습니다.

칸반은 팀이 민첩하고 변화하는 우선 순위에 적응할 수 있도록 지원하는 지속적인 워크플로 구조를 기반으로 합니다. 카드로 표시되는 작업 항목은 칸반 보드에서 구성하며 워크플로의 한 단계(열)에서 다음 단계로 흐릅니다. 일반적인 워크플로 단계는 해야 할 일, 진행 중, 검토 중, 차단됨 및 완료입니다. 하지만 좀 따분합니다.

칸반의 가장 중요한 부분은 팀 작업 방식에 따른 사용자 지정 열을 만드는 것입니다. 저의 팀에서는 콘텐츠를 제공하므로 열(단순화됨)은 백로그에서 우선 순위 지정됨, 개요 준비 완료, 작성 중, 디자인 중, 기술 검토 및 제공으로 이동합니다. 보드는 팀이 (기술 검토를 참조하여) 매주 약 하나의 콘텐츠를 제공하고 병목 현상이 어디에서 발생했는지 찾는 데 도움을 주었습니다

칸반에서는 업데이트가 준비될 때마다 정기적인 일정이나 미리 정해진 기한 없이 릴리스됩니다.

이론적으로 칸반은 작업을 제공하는 시간을 규정하지 않습니다. 작업이 더 일찍 (또는 나중에) 완료되는 경우 스프린트 검토와 같은 릴리스 마일스톤을 기다릴 필요 없이 필요에 따라 작업을 릴리스할 수 있습니다.

칸반 보드의 소유자는 전체 팀입니다. 일부 팀은 애자일 코치를 지정하지만 스크럼과 달리 모든 것을 원활하게 실행하는 “칸반 마스터”는 한 명도 없습니다. 공동 작업을 수행하고 보드에서 작업을 제공하는 것은 팀 전체의 공동 책임입니다.

리드 타임과 사이클 타임은 칸반 팀의 중요한 메트릭입니다. 작업이 시작부터 완료까지 이동하는 데 걸리는 평균 시간입니다. 사이클 타임이 개선되었다는 것은 칸반 팀의 성공을 나타냅니다.

CFD(누적 흐름 다이어그램)는 칸반 팀이 각 상태의 작업 항목 수를 파악하기 위해 사용하는 또 다른 분석 도구입니다. CFD는 처리량을 개선하기 위해 해결해야 하는 특정 병목 현상을 식별하는 데 도움이 됩니다.

병목 현상을 처리하는 또 다른 방법은 WIP(진행 중인 작업) 제한을 사용하는 것입니다. WIP 제한은 한 번에 한 열에 포함할 수 있는 카드 수를 제한합니다. WIP 제한에 도달하면 Jira와 같은 도구가 해당 열을 제한하고 팀이 함께 협력하여 해당 항목을 앞으로 진행시킵니다.

칸반 워크플로는 언제든지 변경할 수 있습니다. 새 작업 항목을 백로그에 추가할 수 있으며, 우선 순위에 따라 기존 카드를 차단하거나 제거할 수 있습니다. 또한 팀 역량이 변경되면 WIP 제한을 다시 보정하고 그에 따라 작업 항목을 조정할 수 있습니다. 이 모든 것이 칸반에서 유연성을 유지하는 것입니다.

칸반 방법론에 대한 자세한 내용은 칸반이란 무엇입니까?를 참조하세요.

애자일 커뮤니티는 이 대화가 도구에 관한 내용이 되어서는 안 된다고 생각합니다. 선택한 도구에 따라 선택하는 프레임워크가 달라지고 그 프레임워크에 따라 팀에서 채택하는 원칙이 달라지는 경우가 종종 있습니다. 하지만 우리는 결정이 이것과 다른 방향으로 흘러가야 한다고 생각합니다.

스크럼 원칙에 정렬되고 스크럼 프레임워크에 만족하면 이제 자신에게 적합한 스크럼 도구를 찾아야 할 때입니다. 칸반의 경우에 마찬가지입니다. 물론 우리 자신에 대한 평가이지만 애자일 팀에서 사용하는 최고의 소프트웨어 개발 도구로서 Jira는 모든 경우에 사용 가능합니다.

스크럼 및 칸반을 위한 Jira의 전용 프로젝트 유형을 사용하면 각 프레임워크의 원칙을 실현할 수 있습니다. 또한 Jira를 사용하여 스크럼을 수행하는 방법 및 Jira로 칸반을 수행하는 방법에 대한 가이드로 시작하도록 도와드리겠습니다.

스크럼과 칸반은 '이론을 따른 애자일'입니다. 둘 다 솔직히 흠잡을 수 없는 증명된 방식으로 작동합니다. 또 다른 유명한 문구에서 말하는 것처럼 “스크럼을 선택했다고 해고당하는 사람은 아무도 없다”라고 말할 수 있습니다.

하지만 반드시 스크럼 또는 칸반 둘 중 하나를 선택해야 하는 것은 아닙니다. 수많은 팀이 스크럼과 칸반 둘 모두의 영향을 받은 하이브리드 모델을 사용하고 있습니다. Atlassian은 Jira에서 팀이 하이브리드 모델을 사용할 수 있도록 지원하기 시작했으며 이것이 바로 팀에서 관리하는 프로젝트를 만든 이유입니다.

이름에서 알 수 있듯이 팀에서 관리하는 프로젝트를 통해 팀은 스크럼, 칸반 또는 두 가지를 혼합하여 적합한 애자일 기능을 선택할 수 있습니다. 팀에서 관리하는 프로젝트를 사용하면 첫날에 하나의 프레임워크를 구현하는 대신 팀에 적합한 기능과 그렇지 않은 기능을 학습하면서 점점 더 강력한 기능을 점진적으로 계층화할 수 있습니다.

두 템플릿 모두 팀의 요구에 맞게 진화할 수 있으므로 팀에서 관리하는 스크럼 또는 팀에서 관리하는 칸반을 자신 있게 선택할 수 있습니다.

무엇을 선택하든 한동안은 지속하세요. 백로그에서 완료까지 몇 개의 작업을 수행한 다음 팀에게 잘된 부분과 부족한 부분을 물어보세요. 스크럼과 칸반을 모두 시도하고 이러한 질문을 하면 적합한 애자일을 선택할 수 있습니다.