Scrumban은 대표적인 두 가지 애자일 방법론인 스크럼과 칸반을 업무를 위한 단일 프로세스로 결합한 것입니다. 그렇다면 Scrumban이란 무엇일까요? 그리고 이 고유한 접근법을 고려해야 하는 이유는 ?무엇일까요
이 가이드에서는 Scrumban이 무엇이고, Scrumban에 적합한 프로젝트 유형은 무엇이며, 애자일 프로젝트 관리에 대한 Scrumban의 하이브리드 접근법을 최대한 활용할 수 있는 대상은 누구인지를 설명합니다.
Scrumban이란 무엇입니까?
Scrumban 방법론은 스크럼 및 칸반이 제공하는 최고의 기능을 하이브리드 프로젝트 관리 프레임워크로 결합한 것입니다. Scrumban은 스프린트, 스탠드업 및 회고로 구성된 스크럼의 안정적인 구조를 사용합니다. 그리고 칸반의 시각적 워크플로 및 진행 중인 작업 제한 기능을 더합니다. 그 결과 어떤 규모의 프로젝트도 관리할 수 있는 매우 유연한 방법이 구현되었습니다.
처음 Scrumban은 팀이 스크럼과 칸반 사이를 쉽게 전환하기 위한 방법으로 시작되었지만, 지금은 팀이 진행 중인 복잡한 프로젝트를 처리할 수 있도록 도와주는 성숙한 시스템으로 발전했습니다. Scrumban은 하이브리드 접근법을 갖추고 팀에 다양한 애자일 도구를 제공하는 유연한 방법론입니다.
그렇다면 Scrumban은 애자일 접근법일까요?그렇습니다. Scrumban은 애자일 방법론인 스크럼 및 칸반을 결합한 것으로, 애자일 워크플로의 요소를 가져와 하이브리드 프로세스를 만듭니다.
스크럼에 대한 이해
스크럼은 팀이 스프린트라는 정해진 기간 안에 계속해서 작업을 완료할 수 있도록 도와주는 애자일 프레임워크입니다. 스크럼 팀은 스프린트마다 제품의 반복 작업인 MVP(최소 실행 가능한 제품)를 제공합니다.
스프린트가 끝날 때마다 팀은 검토 및 회고를 통해 프로젝트 및 프로세스를 지속적으로 개선할 수 있습니다. 스크럼 팀은 팀을 이끌고 프로젝트 장애물을 없애는 역할을 하는 스크럼 마스터와 특정 역할을 맡은 구성원으로 구성됩니다.
칸반과 마찬가지로 스크럼은 보드를 활용하여 프로젝트 진행률을 추적합니다. 하지만 스크럼 보드는 보드와 별도로 존재하는 백로그를 활용한다는 점에서 칸반과 다릅니다. 보드에는 팀이 단일 스프린트 동안 집중한 작업이 표시되고 백로그에는 프로젝트와 관련된 다른 모든 작업 항목이 포함됩니다. 팀은 예정된 스프린트에서 어떤 작업을 할지 결정할 때 이 백로그에서 작업을 가져옵니다.
팀은 Jira의 스크럼 템플릿을 사용하여 스크럼 보드 및 백로그를 쉽게 만들 수 있습니다.
스크럼의 어떤 부분이 Scrumban 방법론에 적용될까요?
첫째, Scrumban은 스크럼 구조를 사용합니다. 시간이 제한된 스프린트와 계획 및 검토 이벤트를 보면 어떤 작업을 언제까지 완료해야 하는지 명확하게 파악할 수 있습니다. 또한 Scrumban 프로젝트는 MVP를 주기적으로 검토하고 변화하는 요구 사항에 맞추는 스크럼의 기존 방법론을 따릅니다.
스크럼이 Scrumban에 기여하는 방식
스크럼은 Scrumban 프레임워크에 다음과 같은 세 가지 중요 요소를 기여합니다.
- 스프린트: 팀은 Scrumban 프로젝트의 모든 작업을 스프린트라고 하는 정해진 기간 이내에 완료합니다. 스프린트는 보통 2주 동안 지속되지만, 팀이 더 짧거나 긴 기간을 선택할 수도 있습니다. 스프린트 이내에 어떤 작업을 진행할지 팀에서 합의한 후에는 스프린트가 종료되기 전까지 새 작업을 수락할 수 없습니다.
- 일일 스탠드업: 누가 무슨 일을 하는지 명확히 정하기 위해 Scrumban 팀은 매일 10분 이내의 일일 스탠드업 미팅을 갖습니다. 여기에서 참가자는 다음의 세 가지 질문에 간략히 답변합니다.
- 내가 완료한 작업은 무엇입니까?
- 나는 어떤 작업을 하고 있습니까?
-
내가 느끼는 장애물은 무엇입니까?
-
회고: 스프린트가 끝날 때마다 팀이 모여 성과를 분석합니다. 어떤 과정이 잘 진행됐고 어떤 과정을 반복해야 하나요? 무엇이 잘 되지 않았으며 무엇을 중단해야 하나요? 팀은 각 회고에서 얻은 정보를 문서화하고 이를 향후 스프린트를 위해 사용합니다.
스크럼과 애자일: 같은 의미로 사용해서는 안 되는 두 용어
간단하게 설명하자면 스크럼과 애자일은 다른 의미이므로 혼동하지 말아야 합니다. 스크럼은 작업을 완료하기 위한 프레임워크이고, 애자일은 스크럼 프로세스의 성공에 필요한 원칙 또는 사고방식의 집합입니다.
간단히 말해 애자일은 프레임워크(스크럼, 칸반, Scrumban 등) 없이는 사용할 수 없습니다. 또한 애자일 사고방식을 구축하지 않고는 스크럼을 사용할 수 없습니다.
칸반에 대한 이해
"신호"와 "보드"를 뜻하는 일본어 단어의 조합인 칸반은 작업을 시각화하고 진행 중인 작업의 양을 제한하여 팀이 효율적인 흐름을 유지할 수 있도록 하는 방법입니다. Toyota가 생산 개선 및 팀 통합을 위해 1953년 비주얼 카드를 사용하는 이 방법을 도입했습니다. 현재 이 방법은 생산성과 훨씬 더 많은 관련이 있습니다. 지속적 개선이 필요한 팀에 적합한 방법론이기 때문입니다.
Jira를 사용하면 팀이 칸반 보드 템플릿으로 다음 프로젝트를 쉽게 시작할 수 있습니다. 강력한 보드에서 작업을 시각화 및 추적하고 작업의 지속적 제공을 관리합니다. 칸반의 어떤 부분이 scrumban 방법론에 적용될까요?
칸반의 어떤 부분이 scrumban 방법론에 적용될까요?
Scrumban은 칸반의 워크플로 시각화를 프로세스의 핵심으로 사용합니다. 보드 및 카드 외에도 Scrumban은 진행 중인 작업 제한, 작업을 위한 풀 시스템, 지속적 워크플로의 이점을 활용합니다. 즉, 스프린트 중간에도 팀이 프로젝트를 완료할 수 있다는 뜻입니다.
칸반이 Scrumban에 기여하는 방식
칸반에는 Scrumban 방법론에 가치를 부여하는 다음의 세 가지 주요 요소가 있습니다.
- 보드: 칸반 보드에는 일반적으로 프로젝트의 각 단계를 나타내는 "할 일" 열, "진행 중" 열, "완료" 열이 있습니다.
- 카드: 보드에는 프로젝트의 작업 또는 카드가 들어 있습니다. (기존에 팀은 화이트보드에 색인 카드 또는 스티커 메모를 사용했기 때문입니다.) 각 구성원이 특정 카드의 작업을 시작하면 카드를 "할 일"에서 "진행 중"으로 이동시키고, 작업을 마쳤으면 "완료" 열로 이동시킵니다.
-
진행 중인 작업 한도: 팀이 효율적으로 일하려면 정해진 작업 기간 내에 현실적으로 작업을 얼마나 처리할 수 있는지 알아야 합니다. 팀원이 하루에 작업할 수 있는 카드가 몇 개입니까? 이 한도를 정의하면 팀은 과로(및 번아웃)를 방지하는 동시에 이해 관계자에게 팀이 달성하고 있는 성과를 정확히 보여줄 수 있습니다.
한눈에 보기: 스크럼, 칸반, Scrumban
| | 스크럼 | 칸반 | Scrumban |
|---|---|---|---|
| 방법론 | 스크럼 시간이 고정된 스프린트 고정된 역할일관적인 제공 | 칸반 진행 중인 작업 제한작업을 시각적으로 추적지속적인 워크플로 | Scrumban 시간이 고정된 스프린트진행 중인 작업 제한작업을 시각적으로 추적지속적인 업무 흐름 |
| 역할 | 스크럼 제품 소유자스크럼 마스터개발 팀 | 칸반 없음 | Scrumban 없음 |
| 아티팩트 | 스크럼 제품 백로그스프린트 백로그증분 완료 | 칸반 칸반 보드칸반 카드 | Scrumban Scrumban 보드Scrumban 카드 |
| 이벤트 | 스크럼 스프린트 계획일일 스탠드업스프린트 검토스프린트 회고 | 칸반 칸반 회의 | Scrumban 스프린트 계획일일 스탠드업스프린트 회고 |
| 프로세스 흐름 | 스크럼 제품 백로그스프린트 백로그진행 중검토완료 | 칸반 할 일진행 중완료 | Scrumban 할 일진행 중완료 |
Scrumban 방법론의 이점
스크럼 또는 칸반 대신 Scrumban 방법론을 선택하는 이유는 무엇일까요?그 해답은 두 방법론의 가장 큰 장점을 합친 데 있습니다.
- 유연성 향상: Scrumban은 모든 스프린트에서 증분 작업을 제공하기 때문에 프로세스 중간에서도 프로젝트를 변경할 수 있습니다. 한편, 프로젝트 완료를 향한 진전이 이루어집니다.
- 지속적 제공: 보드 및 지속적 워크플로가 있으면 팀은 작업을 완료하는 대로 기능을 제공할 수 있습니다. 스프린트가 종료될 때까지 기다릴 필요가 없습니다.
- 과부하 감소: 진행 중인 작업을 팀의 역량으로 제한하면 번아웃 없이 진행할 수 있습니다.
- 더 빠른 이슈 해결: 보드에 카드를 배치하면 Scrumban을 통해 팀이 문제 및 솔루션을 빠르게 파악하면서 더 효과적인 협업에 필요한 투명성을 확보할 수 있습니다.
대규모 프로젝트 처리 능력: 스크럼 및 칸반은 모두 지속적 개선과 점진적 개선에 관한 것이므로, Scrumban을 사용하면 팀은 아무리 복잡한 프로젝트라도 완료를 향해 나아갈 수 있습니다.
Scrumban 방법론의 한계
Scrumban 방법론의 장점은 많지만, 다음을 포함하여 알고 있어야 할 한계도 있습니다.
- 모호성: Scrumban은 비교적 생소해서 도입에 관한 설명서가 많지 않습니다. 따라서 참고 자료 또는 모범 사례를 찾기가 어려울 수 있습니다.
- 낮은 통제력: Scrumban은 전통적인 스크럼 역할을 포기하므로, 팀원이 스프린트를 자체 관리합니다. 명확한 리더가 없으면 책임에 대한 혼란이 생길 수도 있습니다.
복잡성: 두 방법론의 요소를 가져오는 것은 다른 시스템에 익숙하거나 애자일 시스템을 사용해 본 적이 없는 팀원에게는 혼란스러울 수 있습니다.
Scrumban을 사용하는 경우
Scrumban은 스크럼 또는 칸반만으로는 충분하지 않은 특정 사용 사례에 적합합니다. 몇 가지 예는 다음과 같습니다.
요구 사항이 진화하는 소프트웨어 개발 프로젝트
범위 변동이 있는 소프트웨어 프로젝트는 Scrumban 방법론을 사용할 절호의 기회입니다. Scrumban은 스프린트 및 지속적 개발을 통해 이를 실현합니다. 요구 사항이 변경되더라도 팀은 계속하여 작업을 점진적으로 완료할 수 있습니다.
여러 개의 동시 이니셔티브가 있는 프로젝트
대기업의 경우 여러 프로젝트를 동시에 진행하는 일이 흔합니다. 여러 프로젝트에 같은 팀이 관여하는 경우도 있습니다. Scrumban은 유연성 덕분에 동시 이니셔티브가 가능하므로, 소규모 팀도 여러 요구 사항을 해결할 수 있습니다.
스타트업 또는 급변하는 환경
스타트업은 환경 및 프로젝트가 끊임없이 바뀌는 경우가 많습니다. 매일같이 새로운 어려움이 발생하며 리소스도 부족합니다. Scrumban은 그러한 환경에 가능성을 가져다 줍니다. 유연한 업무 프레임워크를 통해 소규모 팀도 성공할 수 있도록 지원합니다.
결국 칸반 대 스크럼의 대결이 아닙니다. 각 방법론에서 팀에 가장 적합한 원칙을 적용하면 어떤 프로젝트든 더 효율적으로 처리할 수 있습니다.
Jira에서 다음 scrumban 프로젝트 시작
Scrumban은 프로젝트 팀이 프로젝트의 복잡성과 작업 수용량의 균형을 맞추는 데 도움이 되는 유연한 애자일 방법론입니다. Scrumban의 강점은 스크럼 및 칸반의 장점을 결합하는 데 있습니다.
프로젝트 관리에 대한 scrumban의 하이브리드 접근 방식의 이점을 경험할 준비가 되었다면 Jira를 사용하여 다음 프로젝트를 설정하는 것만큼이나 쉽게 관리할 수 있습니다. Jira의 미리 구성된 수십 가지 템플릿 중 하나로 시작하여 팀 구조, 워크플로 또는 애자일 방법론에 맞게 프로젝트를 사용자 지정하세요. Jira를 사용하면 쉽게 작업을 체계화하고 정렬된 상태를 유지하고 더 나은 제품을 만들 수 있습니다.
또한 Jira를 사용하면 마케팅, HR 또는 재무와 같은 비즈니스 팀이 scrumban 원칙의 이점을 활용할 수 있습니다. 보드 보기 외에도 Jira는 캘린더 및 타임라인 보기를 제공하여 팀이 작업을 명확하고 쉽게 시각화할 수 있도록 합니다. Jira는 조직 전체의 공동 작업을 위한 공유 플랫폼으로 소프트웨어 개발 팀 및 비즈니스 팀이 각자의 사용 사례에 맞게 큐레이션된 도구를 사용하면서 연결된 상태를 유지할 수 있습니다.
Scrumban: 자주 묻는 질문
Scrumban은 우선 순위 지정을 어떻게 처리합니까?
Scrumban에는 스크럼 마스터가 필요하지 않으므로, 팀은 Scrumban 보드에서 우선 순위를 처리하는 방식에 대해 균형 잡힌 의견을 가집니다. 보통 팀은 각 작업에 가치 기반 순위(가치가 높을수록 우선 순위가 높음) 또는 위험 기반 시스템(기한에 미치는 영향이 클수록 더 중요함)을 할당하는 데 합의합니다.
Scrumban은 대규모 프로젝트에 적합합니까?
물론입니다. Scrumban은 점진적인 진전을 제공하므로, 팀은 시간이 흐르면서 범위가 자연스럽게 변경되는 대규모 프로젝트도 처리할 수 있습니다. 일관적인 결과물 제공을 통해 팀은 스프린트마다 대규모 프로젝트를 점진적으로 완료할 수 있습니다.
Scrumban을 도입할 때 팀이 흔히 겪는 어려움은 무엇입니까?
가장 큰 어려움은 언제나 문화적인 것입니다. 여느 조직 변화가 그렇듯이 다른 방식에 익숙한 팀원의 저항이 있을 것입니다. 팀이 Scrumban의 원칙 및 구조를 지키도록 하는 것이 주요 과제가 될 것입니다.