애자일 팀을 위한 애자일 프레임워크를 선택할 때 완벽한 방식은 없습니다. 칸반, 스크럼을 사용하든 Scrumban 및 Kanplan과 같이 둘의 조합을 사용하든 애자일은 팀 프로세스입니다. 모든 팀은 훌륭한 소프트웨어를 계획, 추적 및 릴리스하는 방법의 기초로 가장 적합한 프레임워크를 파악해야 합니다.
Scrumban, 칸반 및 스크럼 비교
칸반은 팀원에게 겨우 충분한 작업을 제공하여 팀이 지속적으로 수용 작업량에 따라서 작업하게 합니다. 칸반을 실행하는 팀은 보드에 있는 모든 것이 최고 우선 순위이기 때문에 유연한 계획, 명확한 초점 및 완전한 투명성의 이점을 누릴 수 있습니다. 그것이 바로 개발자가 작업하고 있는 것입니다. 칸반은 우선 순위가 바뀌는 상황에서 지속적 제공에 중점을 두는 운영 팀에 적합합니다.
반대로 스크럼은 작업을 스프린트라고 하는 일련의 시간이 고정된 반복으로 나눕니다. 스프린트에 예약된 모든 것이 팀의 최고 우선 순위입니다(예: 특정 기능 또는 기능 그룹). 명확한 로드맵과 우선 순위가 지정된 작업 청크를 갖춘 제품 팀이 일반적으로 스크럼의 이점을 가장 많이 누릴 수 있습니다.
하지만 스크럼과 칸반을 조합하면 팀에서 가장 큰 이점을 얻을 수 있을까요? 또는 스크럼에서 칸반으로 전환하고 싶습니까? 이러한 내용이 우리 팀의 이야기처럼 들린다면 해결책은 Scrumban입니다. 이 혼합 방법론 자체는 여러 가지 방식으로 나타나지만 Scrumban 팀에서 가장 일반적인 트렌드는 스크럼의 백로그와 칸반의 WIP 제한 및 사이클 타임과 함께 스프린트를 사용하는 것입니다. (참고: 사이클 타임은 작업이 팀의 워크플로 거치는 데 걸리는 시간입니다.)
반복적인 작업은 하고 싶지 않지만 여전히 백로그 그루밍 기능은 원하는 팀이라면 어떻게 해야 합니까? Jira의 kanplan(또는 칸반 백로그 기능 활성화)이 해답일 수 있습니다.
kanplan이란 무엇입니까?
Kanplan은 애자일 소프트웨어 개발을 실행하기 위한 혼합 방법론입니다. Scrumban과 마찬가지로 스크럼과 칸반의 기능을 결합합니다. Kanplan은 백로그 그루밍 기능을 원하지만 스프린트에서 작업하고 싶지 않은 팀에 이상적입니다.
칸반이 엄격한 프레임워크가 아닌 기초인 이유
Atlassian의 빌드 엔지니어링 팀은 Atlassian 소프트웨어를 빌드, 테스트 및 제공하는 데 사용되는 플랫폼을 담당합니다. 개발자는 신뢰할 수 있는 인프라와 빠른 지속적 통합(CI)에 의존합니다. 4년 전에는 한 달에 빌드 수가 21,000개인 것처럼 보였습니다. 현재 이 숫자는 매월 15만 개를 넘습니다.
이러한 확장 기능은 팀 성장, Subversion에서 Git으로 마이그레이션, 자동화된 테스트으로 인한 것이며 덜 분명할 수 있지만 스크럼에서 칸반으로 이동으로 인한 것일 수 있습니다. 빌드 엔지니어링 작업의 특성(예를 들어 특별 요청, 인시던트, 혁신 작업)은 스크럼 프레임워크 내에서 적합하지 않았습니다. 그래서 팀이 scrumban을 도입하기로 결정했고, 팀이 스프린트 사용을 좋아하지 않았기 때문에 빠르게 칸반으로 전환되었습니다. 하지만 칸반도 팀에서 바라는 비법이 아니라고 밝혀졌습니다. 많은 팀과 마찬가지로 여러 노력을 했습니다. 그들은 한 보드에서 여러 보드로, 지원 엔지니어 보드, 프로젝트 작업 보드 등으로 이동했으며 모두 워크플로가 달랐습니다. 하지만 모든 보드에서 가장 큰 문제점은 무엇일까요? 한 팀원의 표현처럼 “황무지” 즉 작업할 준비된 모드로 이동해야 하는 심사하지 않은 문제들입니다. '진행 중' 열에 들어가면 팀은 순조로웠지만 '해야 할 일' 열("황무지" 열)은 말그대로 황무지였습니다.
'햐야 할 일' 목록을 백로그로 전환
저희의 빌드 엔지니어링 팀은 매일 스탠드업 미팅 및 주간 계획 미팅을 통해 길고 체계화되지 않은 할 일 목록에 대응하려고 노력했습니다. 하지만 실제로 필요한 것은 더 많은 회의가 아닌 백로그였습니다.
칸반 보드에는 전통적으로 백로그 기능이 없기 때문에 제품 관리자, 개발 관리자 및 팀 리더는 첫 번째 열의 이슈를 사용하여 계획합니다. 이 목록이 늘어남에 따라 이슈를 확인하고 우선 순위를 지정하기가 어렵습니다. 빌드 엔지니어링 팀은 다양한 작업 영역을 기준으로 보드를 분할했지만 결합된 팀 보드의 양은 매우 컸습니다(많이 스크롤해야 함).
따라서 Jira 팀은 팀 또는 보드를 재구성하는 다양한 방법을 찾거나 새로운 방법을 구상하는 대신 칸반에 백로그를 가져오기로 결정했습니다. kanplan 기능은 목록 보기에 이슈가 있는 넓은 열 백로그를 도입합니다. 이렇게 하면 칸반 보드가 백로그 그루밍을 위한 백로그와 엔지니어링 팀이 워크플로 전체에 걸쳐 작업을 선택해 이동할 수 있는 칸반 보드의 두 개의 다른 화면으로 분할됩니다.
이 기능은 Jira에 있는 스크럼 보드의 백로그와 다르지 않습니다. 예를 들어 사이드바에서 백로그 아이콘을 클릭하면 넓은 백로그 이슈 열로 이동합니다. 백로그를 그루밍한 후에는 이슈를 워크플로의 다음 단계로 끌어 놓을 수 있습니다.
스크럼의 백로그 화면과 칸반 보드를 하나의 애자일 보드로 결합하면 스크럼 보드 백로그처럼 작동합니다. 이슈를 클릭하면 이슈 세부 정보 보기가 표시됩니다. 이슈 세부 정보 보기와 같은 집중 보기를 사용하면 팀의 각 구성원이 방해 요소를 줄이면서 작업을 더 빠르게 수행할 수 있습니다.
마지막으로 에픽 및 미리 할당된 버전을 사용하여 릴리스를 구성하는 스크럼을 사용하지 않는 팀의 경우 이슈 보기 또는 빠른 편집 등 스크럼 보드에 있는 도구를 활용할 수 있습니다. 이렇게 간단하고 빠른 편집을 통해 제품 관리자, 개발 관리자 및 계획 모드에서 작업하는 모든 팀원이 에픽과 버전을 효율적으로 관리할 수 있습니다.
칸반 보드에 백로그를 추가하고 싶습니까?
Kanplan은 한 고객의 표현대로 “둘의 장점”만을 제공하기 위한 것입니다. 스프린트 진행하지 않고 카드를 이동하고 백로그 작업을 입력하여 더 나은 계획을 세울 수 있습니다. Atlassian의 빌드 엔지니어링 팀이 경험했던 '황무지'를 제거하고 칸반 팀에게 이전에 칸반에는 없었던 계획 모드를 제공합니다. 또한 칸반, 스크럼 또는 Scrumban이 원하는 작업을 수행하는 데 필요한 기반을 제공한다고 생각하지 못했던 팀을 위해 새로운 방식으로 작업을 수행하도록 안내합니다.칸반 보드에서 계획 모드를 열면 칸반을 처음 사용하는 팀과 기존 팀은 각자 팀에 적용할 수 없는 모범 사례를 따르는 대신 애자일 프레임워크를 작동시키는 방법을 찾을 수 있습니다. 기억하세요. 애자일 개발은 모범 사례보다는 지속적인 개선에 관한 것입니다.
