칸반 보드란?

칸반 보드는 작업을 시각화하고, 진행 중인 작업을 제한하며 효율성(또는 흐름)를 최대화하는 애자일 프로젝트 관리 도구입니다. 애자일 팀과 DevOps 팀이 일상 업무에서 체계를 확립하는 데 도움이 될 수 있습니다. 칸반 보드는 카드, 열 및 지속적인 개선을 사용하여 기술 및 서비스 팀이 적절한 양의 작업을 수행하고 완료할 수 있도록 도와줍니다!

칸반은 작지만 열정적인 칸반 애호가 그룹 덕분에 린 제조가 처음 발생했을 당시부터 크게 발전했습니다. 칸반 방법을 정의하는 David Anderson의 작업은 칸반을 소프트웨어 및 서비스 공간으로 가져오는 데 도움이 되었으며 Jim Benson과 Tonianne DeMaria의 Personal Kanban(개인적 칸반)은 칸반의 적용을 믿기 힘든 곳으로 확대하는 데 기여했습니다.

저는 칸반 보드를 매일 사용하는데, 칸반 보드가 없는 삶은 상상할 수 없었습니다. 여기서 언급하는 아이디어 및 모범 사례는 저의 개인적 경험, 연구 및 Zach Nies, Keith Nottinson 및 Jim Benson과 함께 나눈 대화를 곁들인 것입니다.

칸반으로 돌아가는 이유는 칸반의 가치와 (놀랍게도) 규칙이 없다는 것입니다. 칸반의 가치는 사람에 대한 존중과 지속적인 개선입니다.

David Anderson은 칸반 보드를 시각적 신호, 열, 진행 중인 작업 제한, 이행 약속 시점 및 배포 시점의 다섯 가지 구성 요소로 나눌 수 있음을 확인했습니다.

1. 시각적 신호 — 칸반 보드에서 가장 먼저 눈에 띄는 것 중 하나는 시각적 카드(스티커, 티켓 등)입니다. 칸반 팀은 일반적으로 카드당 하나씩 모든 프로젝트와 작업 항목을 기록합니다. 애자일 팀의 경우 각 카드는 사용자 스토리 하나를 캡슐화할 수 있습니다. 보드에 추가된 후 이러한 시각적 신호는 팀원과 이해 관계자가 팀에서 어떤 작업을 하고 있는지 빠르게 이해할 수 있게 합니다.
2. 열 — 칸반 보드의 또 다른 특징은 특정 활동을 나타내는 열이며 이 열들이 모며 '워크플로'를 구성합니다. 카드는 완료까지 워크플로를 따라 진행합니다. 워크플로는 '해야 할 일', 진행 중', '완료'와 같이 간단하거나 더 복잡할 수 있습니다.
3. WIP(진행 중인 작업) 제한 — WIP 제한은 지정된 시간에 한 열에 포함할 수 있는 최대 카드 수입니다. WIP 제한이 3개인 열에는 카드를 세 개 이상 포함할 수 없습니다. 열에 카드의 수가 '최대치'에 도달하는 경우, 새 카드를 워크플로의 해당 단계로 이동하려면 팀은 먼저 최대치에 도달한 카드를 해결하고 다음 단계로 보내야 합니다. WIP 제한은 워크플로에서 병목 현상을 노출시키고 흐름을 최대화하는 데 매우 중요합니다. WIP 제한은 너무 많은 작업을 이행 약정했다는 조기 경고 신호가 됩니다.
4. 이행 약속 시점 — 칸반 팀은 종종 보드에 대한 백로그를 가지고 있습니다. 백로그에 고객 또는 팀원이 프로젝트에 대한 아이디어를 제시하며 팀은 준비가 되면 백로그에서 이슈를 작업하기 시작합니다. 약정 시점은 팀에서 아이디어를 선택하여 프로젝트에서 작업을 시작하는 시점입니다.
5. 제공 시점 — 제공 시점은 칸반 팀의 워크플로 끝입니다. 대부분의 팀에서 제공 시점은 제품 또는 서비스를 고객에게 전달하는 시점입니다. 팀의 목표는 카드를 가능한 한 빨리 약정 시점에서 제공 시점으로 이동하는 것입니다. 두 시점 사이의 경과 시간을 리드 타임이라고 합니다. 칸반 팀은 리드 타임을 최대한 줄이기 위해 지속적으로 개선합니다.

이러한 다섯 가지 요소가 포함된 칸반 보드는 의심할 여지없이 팀을 성공으로 이끌 것입니다. 하지만 지금은 반대되는 관점을 제시하겠습니다.

Jim Benson은 칸반에는 진행 중인 작업을 제한하고 작업을 시각화하는 두 가지 규칙만 있다고 말합니다. 이러한 규칙으로 시작하여 작업에 적용하면 칸반 보드가 위에서 설명한 것과 크게 다르게 보일 것입니다. 하지만 괜찮습니다! Jim에 따르면 “규칙을 많이 추가할수록 맞는 맥락이 줄어들기 때문에” Jim은 이 두 가지 규칙으로 시작하는 것을 지지합니다.

칸반은 제조에서 인사, 애자일 및 DevOps 소프트웨어 개발에 이르기까지 다양한 환경에 맞춰 적응할 수 있습니다. 칸반을 적응하는 환경 유형에 따라 물리적 또는 디지털 보드를 결정하는 경우가 많습니다. 연구를 진행하면서 저는 트레일러에 물리적 보드를 놓고 관리하는 5800백만 달러 규모의 건설 작업을 본 적이 있으며 저는 매우 많은 소프트웨어 팀에게 디지털 칸반 보드를 사용하라고 이야기했습니다.

가장 간단한 칸반 보드는 수직 열로 구분된 물리적 보드입니다. 팀에서는 화이트보드 또는 칠판에 표시하고 보드에 스티커 메모를 붙입니다. 이러한 스티커 메모는 워크플로를 따라 이동하여 진행 상황을 보여줍니다.

물리적 보드의 장점 중 하나는 “항상 보인다”는 점입니다. 하지만 책상 바로 옆에 앉아 있는 거대한 롤링 화이트보드에서는 새 탭을 열 수 없습니다. 물리적 보드는 쉽게 설치할 수 있고, 다른 사람에게 보여주기 쉬우며, 일반적으로 특정 팀과 의사 소통하는 데 더 좋은 방법인 경우가 많습니다. 그러나 물리적 보드는 원격 팀 또는 저처럼 글씨를 끔찍하게 못 쓰는 사용자들에게는 적합하지 않습니다.

Optimizely는 사용자가 가장 좋아하는 웹 페이지 또는 제품의 변형을 기업에서 파악하는 데 도움이 되는 소프트웨어를 만듭니다. 이들은 Jira를 사용하여 크고 작은 작업 항목을 추적하지만 개발 담당 수석 이사인 Keith Nottonson은 공백을 보았습니다.

개별 팀은 Jira에서 열심히 작업하지만 서로 대화하지는 않았습니다. 모든 팀원들이 같은 정보를 공유할 수 있도록 Keith는 “작업의 벽”이라는 거대한 물리적 칸반 보드를 세웠습니다.

이 보드에는 엔지니어링 팀이 작업하는 모든 프로젝트를 메트릭, 팀원 및 상태와 함께 모두 볼 수 있도록 표시됩니다. 전체 작업 포트폴리오를 파악하는 데 도움이되었지만 훨씬 더 흥미로운 가치가 나타나기 시작했습니다.

Keith는 “처음에는 벽이 단지 '해야 할 일', '진행 중, '완료'였지만 시간이 지남에 따라 팀원들은 우리가 일하는 방식에 대해 대화를 나누기 시작했습니다.”라고 말합니다. Keith는 이러한 대화 덕분에 벽은 불과 몇 주 만에 성장하고 진화했으며, Optimizely는 작업이 어떻게 수행되는지에 그 어느 때 보다 명확하게 파악하게 되었다고 합니다.

Optimizely의 보드는 약정 시점과 배포 시점이 표시되어 있기 때문에 특히 좋습니다. 프로젝트가 정의되고 특정 기준을 충족하면 엔지니어링 팀이 프로젝트를 선택하고 완료하기로 약정합니다. 이 시점에서 프로젝트는 Jira로 이동하여 최종 제공과 관련된 모든 유용한 데이터와 상호 작용을 파악할 수 있습니다.

이러한 초기 대화가 워크플로와 보드의 빠른 반복으로 이어질 수 있기 때문에 Keith는 팀에 물리적 칸반 보드로 시작할 것을 권장합니다.

칸반 시스템이 소프트웨어 및 엔지니어링 팀에서 인기를 얻으면서 칸반 보드는 디지털 혁신을 거쳤습니다. 디지털 보드를 사용하면 물리적 사무실 공간을 공유하지 않는 팀이 원격 및 비동기식으로 칸반 보드를 사용할 수 있습니다.

Trello는 디지털 칸반 보드를 만드는 빠르고 간단한 방법입니다. 몇 번만 클릭하면 전체 팀이 액세스하고 관리할 수 있는 보드 보기에서 칸반 프로세스의 단계를 나타내는 디지털 목록을 만들 수 있습니다.

예를 들어 “백로그”, “다음 작업”, “진행 중” 및 “완료!” 에 대한 목록을 만들 수 있습니다. 각 작업은 카드로 구성하며 카드를 큐에 추가하고 작업하고 완료하면 목록에서 이동합니다.

이와 같은 디지털 칸반 보드의 장점은 빠른 설정 속도, 다른 사용자와 편리한 공유 및 프로젝트가 진행됨에 따라 무한한 수의 대화와 댓글을 비동기적으로 추적할 수 있다는 점입니다. 팀원이 칸반 보드에서 언제 어디서 체크인하든 프로젝트의 최신 상태를 볼 수 있습니다. 또한 이 샘플 보드가 보여주는 것처럼 개인의 해야 할 일에 Trello 칸반 워크플로 사용할 수도 있습니다.

일부 디지털 칸반 보드는 단순하고 일부는 더 견고하고 사용자 지정 가능합니다. WIP 제한 및 컨트롤 차트와 같은 추가 기능이 필요한 팀은 Jira와 같은 더 강력한 도구를 선택해야 합니다. Jira에서는 칸반 팀이 간단하게 구성하고 실행할 수 있는 칸반 보드 템플릿을 즉시 사용할 수 있습니다. 팀은 프로젝트에 착수하여 워크플로와 보드를 사용자 지정하고 WIP 제한을 설정하며 스윔레인을 만들고 우선 순위를 지정하는 더 나은 방법이 필요한 경우 백로그를 활성화할 수도 있습니다.

칸반과 스크럼의 차이는 실제로 매우 미묘합니다. 대부분의 해석에 따르면 스크럼 팀은 스크럼 프로세스, 아티팩트 및 역할과 함께 칸반 보드를 사용합니다. 그러나 몇 가지 중요한 차이점이 있습니다.

• 스크럼 스프린트에는 시작 날짜와 중지 날짜가 있지만 칸반은 계속되는 프로세스입니다.
• 스크럼에서는 제품 소유자, 개발 팀 및 스크럼 마스터와 같은 팀 역할이 명확하게 정의되어 있지만 칸반에는 공식적인 역할이 없습니다. 스크럼 및 칸반 팀 모두는 자체적으로 조직됩니다.
• 칸반 보드는 프로젝트의 수명 주기 전반에 걸쳐 사용되는 반면 스크럼 보드는 각 스프린트가 끝난 뒤에는 지우고 재활용합니다.
• 스크럼 보드에는 정해진 수의 작업과 엄격한 완료 기한이 있습니다.
• 칸반 보드는 작업 및 타이밍과 관련하여 더 유연합니다. 필요에 따라 작업의 우선 순위를 다시 지정하거나, 다시 할당하거나, 업데이트할 수 있습니다.

칸반과 스크럼은 모두 소프트웨어 개발자들에게 인기 있는 애자일 프레임워크입니다. 자세한 내용은 칸반과 스크럼에 대한 전체 분석을 읽어보세요.

칸반은 '지금 하는 작업부터 시작'하는 방법입니다. 즉, 칸반을 시작하기 위해 현재 하고 있는 작업을 송두리째 바꿀 필요가 없습니다. 칸반 방법은 다음 세 가지를 가정합니다.

1. 현재 실행되고 있는 프로세스를 이해하고 현재 역할, 책임 및 직함을 존중합니다.
2. 점진적인 변화를 통해 지속적인 개선을 추구하는 데 동의합니다.
3. 개별 기여자부터 고위 경영진에 이르기까지 모든 수준에서 리더십 행동을 장려합니다.

이것은 팀 프로세스이므로 팀이 가장 먼저 해야 할 일은 모이는 것입니다! 작업을 워크플로(열)를 구성하는 고유한 활동으로 나눕니다. 그런 다음 새로운 작업(카드)을 언제 어떻게 보드에 추가할지 생각합니다. 고객이 아이디어를 제출할 수 있는 서비스 데스크를 만들 예정입니까? 아니면 팀이 카드를 적고 게시할 수 있는 회의를 설정할 예정입니까?

카드 하나의 크기와 범위도 결정해야 합니다. 모든 카드에서 균일한 시간 추정치 또는 복잡성 추정치를 찾아보세요. 너무 과도하거나 도전이 되는 카드가 있다면 여러 장의 카드로 나누세요.

이행 약속 시점과 배포 시점을 결정하면 작업을 시작할 준비가 된 것입니다. 시간이 지나면서 팀에 의존하여 프로세스를 평가하고 개선하세요. 칸반은 모든 수준에서 지속적 리더십 행동 즉, 카이센(Kaisen)이라는 개념을 요구합니다. 팀원에 대한 존중과 지속적인 개선이라는 칸반 가치를 유념하면 바로 필요한 속도에 도달할 것입니다.