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

스크럼 또는 칸반 중에서 선택할 때 고려해야 할 주요 사항과 둘 중에서 결정할 수 없는 경우 할 수 있는 일을 알아봅니다.

Max Rehkopf 작성자: Max Rehkopf
주제 찾아보기

요약: '칸반과 스크럼 비교'는 애자일 개발 또는 프로젝트 관리 시스템을 구현하기 위한 두 가지 전략에 관한 토론입니다. 칸반 방법론은 연속적이고 유동적인 반면 스크럼은 짧고 구조화된 작업 스프린트를 기반으로 합니다.

Agile is a set of ideals and principles that serve as our north star. DevOps is a way to automate and integrate the processes between software development and operations teams. When it comes to implementing agile and DevOps, kanban and scrum provide different ways to do so.

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

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

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

Kanban is all about visualizing your work, limiting work in progress, and maximizing efficiency (or flow). Kanban teams focus on reducing the time a project takes (or user story) from start to finish. They do this by using a kanban board and continuously improving their flow of work.

Scrum teams commit to completing an increment of work, which is potentially shippable, through set intervals called sprints. Their goal is to create learning loops to quickly gather and integrate customer feedback. Scrum teams adopt specific roles, create special artifacts, and hold regular ceremonies to keep things moving forward. Scrum is best defined in The Scrum Guide.

 

Scrum

Kanban

Origin

Scrum

Software development

Kanban

Lean manufacturing

Idealogy

Scrum

Learn through experiences, self-organize and prioritize, and reflect on wins and losses to continuously improve.

Kanban

Use visuals to improve work-in-progress

Cadence

Scrum

Regular, fixed-length sprints (i.e. two weeks)

Kanban

Continuous flow

Practices

Scrum

Sprint planning, sprint, daily scrum, sprint review, sprint retrospective

Kanban

Visualize the flow of work, limit work-in-progress, manage flow, incorporate feedback loops

Roles

Scrum

Product owner, scrum master, development team

Kanban

No required roles

스크럼 보드를 사용하는 팀원 | Atlassian 애자일 코치

스크럼: 구조화된 애자일 접근 방식

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

스크럼 케이던스

Scrum moves fast, with sprints that usually last between one to four weeks, which have clear start and finish dates. The short time frame forces complex tasks to be split into smaller stories and help your team learn quickly. A key question is this: Can your team ship useable code that fast?

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

스크럼 역할

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

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

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

Common metrics

Scrum metrics are data points scrum teams can use to improve efficiency and effectiveness. They can inform decision-making and help teams become more efficient in planning and execution. During the sprint planning phase, teams can use metrics such as sprint goals, team velocity, team capacity, and type of work. During stand-ups, teams can also benefit from measuring progress towards sprint goals, reviewing a sprint burndown, understanding workload distribution, and more.

변경 철학

Teams strive to understand how much they can accomplish within their sprint time boundaries. They commit to its delivery within a sprint. However, scrum teams can receive customer feedback that encourages them to pivot and change the sprint to deliver the most customer value. During the sprint retrospective, scrum teams should discuss how to limit change in the future, as changes put the potentially shippable increment at risk. If a team frequently changes scope mid-sprint, it may signify work was selected that isn’t adequately understood. It could also mean the team has operational/unplannable work that interferes with the plan.

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

칸반 보드를 사용하는 팀원 | Atlassian 애자일 코치

칸반: 지속적인 개선, 유연한 프로세스

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

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

칸반 케이던스

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

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

릴리즈 방법론

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

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

칸반 역할

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

주요 지표

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

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

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

변경 철학

A kanban workflow can change at any time. New work items can get added to the backlog and existing cards can get blocked or removed based on prioritization. Also, if the team capacity changes, WIP limit can be recalibrated and work items adjusted accordingly. It’s all about being flexible in kanban.

For more on kanban methodologies see What is kanban?

Atlassian의 애자일 프로젝트 | Atlassian 애자일 코치

Scrum tools vs. kanban tools

The agile community believes this conversation shouldn't be about the tools. We often see the tool of choice driving the framework of choice and the framework driving the principles the team adopts. We believe the decision should flow in the other direction.

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

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

Kanban vs. scrum: What if you can't choose?

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

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

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

You can confidently choose team-managed scrum or team-managed kanban knowing that both templates can evolve to suit the needs of your team.

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

Jira 보드

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

템플릿 사용
다음 단계
Kanplan