소프트웨어 엔지니어링에서 칸반 모델이란 무엇인가요?

칸반이란 무엇입니까?

Kanban 애자일 소프트웨어 개발 방법론에서 매우 인기 있는 개발 프레임워크입니다. 이는 팀의 작업과 작업 능력을 시각화하는 투명한 방법을 제공합니다. 주로 실제 보드와 디지털 보드를 사용하여 팀 구성원이 작업 중인 프로젝트의 현재 상태를 시각화할 수 있습니다.

칸반은 1940년대 도요타에서 시작되었습니다. 칸반의 일본어 의미는 "빌보드"입니다. 칸반 보드에는 열과 스토리 카드가 있습니다. 열은 아무것도 아니지만 워크플로 상태와 카드는 팀원이 수행하는 실제 작업을 보여주는 것일 뿐입니다.

그 카드들은 적시 생산(Just-in-Time) 신호를 전달했습니다. 즉, 공장은 실제로 필요할 때만 부품을 요청했기 때문에 어떤 것도 미리 만들어 놓지 않았습니다. 칸반은 이러한 아이디어를 그대로 따릅니다. 칸반은 기존 프로세스를 대체하는 것이 아니라 그 위에 덧씌우는 방식이기 때문에 어떤 프로세스에도 적용할 수 있습니다. 소프트웨어 개발 수명주기 이미 실행 중인 모델입니다.

칸반은 언제 사용하는가?

칸반은 작업물이 예측 불가능하게 들어오고, 항목이 준비되는 즉시 배포해야 하는 팀에 적합합니다. 칸반 방식을 사용하는 주요 이유는 다음과 같습니다.

• Kanban은 모든 도메인에서 사용할 수 있으며 소프트웨어 개발에 매우 ​​효과적으로 사용될 수 있습니다. Kanban 프로젝트 관리는 팀의 효율성을 향상시키는 데 도움이 됩니다.
• 풀 기반 시스템입니다. 개인이 자유로워지는 즉시 작업이 취소됩니다.
• 칸반은 언제든지 작업을 공개하고 싶을 때 사용해야 합니다. git 분기가 필요하지만 가능합니다.
• Kanban은 우선 순위를 즉시 변경하려는 경우에 사용해야 합니다. 이를 위해 당신이 해야 할 일은 이 스토리를 할 일 대기열의 맨 위에 두는 것뿐입니다.
• 작업을 시각화하고 작업 진행 상황을 시각적으로 확인하려는 경우에 사용해야 합니다.

적합성은 의사 결정의 절반이고, 아래의 보상이 나머지 절반입니다.

칸반 방법론의 장점

칸반의 가장 강력한 장점은 조직 개편 없이도 업무 효율성을 향상시킨다는 점입니다. 직책이 바뀌거나 스프린트 일정이 강제되는 것도 아니지만, 칸반 보드를 통해 첫날부터 대기열, 병목 현상, 과중한 업무에 시달리는 사람들을 한눈에 파악할 수 있습니다. 모두가 볼 수 있는 병목 현상은 해결될 가능성이 높습니다.

칸반을 꾸준히 사용하는 팀은 다음과 같은 이점을 보고합니다.

• 더 짧은 배송 시간: WIP 제한은 카드가 대기하는 시간을 줄여주는데, 대부분의 지연은 바로 이 대기 시간에서 발생합니다.
• 더 높은 유연성: 긴급한 항목은 기다릴 필요 없이 언제든지 할 일 목록 맨 위로 올라갈 수 있습니다.
• 더 나은 협업: 컬럼이 최대 용량에 도달하면, 무료 회원은 새 컬럼을 시작하는 대신 기존 컬럼을 비우는 데 도움을 줍니다.
• 직원 권한 부여: 개인들이 다음 카드를 직접 선택하고 카드의 소유권을 가지게 되므로 승인 병목 현상이 사라집니다.
• 예측 가능한 예측: 과거 소요 기간은 추측이 아닌 증거 기반의 납품 예측치를 제공합니다.
• Less 낭비: 시스템이 작업을 완료할 수 있는 용량을 확보하기 전에는 아무것도 시작되지 않습니다.

이러한 결과는 모든 칸반 구현을 지배하는 네 가지 원칙에서 비롯됩니다.

칸반의 XNUMX가지 원칙

다음은 칸반의 네 가지 핵심 원칙입니다.

1. 지금 가지고 있는 것부터 시작해 보세요.: 칸반 시스템은 점진적으로 작업하고 현재 가지고 있는 것부터 시작하도록 제안합니다. 그 실천 중 하나가 지속적으로 개선하는 것이므로 시스템을 점진적으로 개선해야 합니다.
2. 점진적이고 진화적인 변화를 추구하는 데 동의합니다. 칸반은 프로세스의 점진적인 변화를 권장하며, 프로세스에서 한 번에 큰 변화를 줘서는 안 됩니다.
3. 현재 프로세스, 역할 및 책임을 존중합니다. 다시 한 번 현재 가지고 있는 것부터 시작하여 프로세스, 역할 및 책임을 점진적으로 변경하십시오.
4. 모든 수준에서 리더십 활동을 장려합니다.: 모든 개인이 리더 역할을 하며 칸반 시스템 전반의 효율성을 높이기 위한 아이디어를 제공할 수 있습니다. 이것이 경영진 수준의 활동이라고 생각하면 안 되며, 팀의 막내라도 리더 역할을 할 수 있습니다.

원칙은 사고방식을 설명합니다. 아래의 여섯 가지 실천 사항은 이러한 원칙을 실제로 적용하기 위한 일상적인 행동을 설명합니다.

XNUMX가지 칸반 핵심 관행

다음은 칸반의 주요 6가지 핵심 실천 방법입니다.

1. 워크플로 시각화이 원칙은 워크플로를 시각화하기 위해 칸반 보드(실물 또는 디지털)를 사용하는 것을 제안합니다. 팀의 모든 구성원은 자신의 카드와 다른 팀원들의 카드를 볼 수 있어야 합니다. 보드 레이아웃에 따라 카드를 다른 열로 이동할 수 있습니다. 이는 팀 내 투명성을 높이고 문제 해결을 용이하게 합니다.
2. 진행 중인 작업 제한: Kanban은 Pull 기반 시스템으로, 진행 중인 작업을 제한하고 팀에서 주어진 시간 안에 완료할 수 있는 작업을 갖도록 하여 팀의 효율성을 향상시킵니다. 이 WIP 한도는 워크플로우의 시작부터 끝까지 적용됩니다. 양의 정수를 사용하여 열 위에 제한을 적용할 수 있습니다.
3. 흐름에 집중: 이 원칙은 흐름과 중단에 중점을 둡니다. 중단이나 방해 요소가 있는 경우 영구적으로 수정해야 합니다.
4. 명시적 정책: 재작업을 줄이고 주의가 필요한 영역이나 더 효과적인 영역에 집중하기 위해 팀에서 정책을 수립할 수 있습니다.
5. 피드백 루프: 피드백 루프는 Kanban에서 매우 중요합니다. 이는 팀 내뿐만 아니라 여러 팀, 코치 등 사이에서도 이루어집니다. 이는 Kanban 시스템의 전반적인 상태를 개선하는 데 도움이 됩니다.
6. 지속적인 개선: 이것이 칸반 시스템의 핵심 원칙입니다. 이는 항상 프로세스를 개선할 수 있으며 결과적으로 효율성이 향상될 것이라고 말합니다.

실천에는 책임자가 필요하며, 칸반은 다른 방식과 달리 이 부분을 다르게 처리합니다. 애자일 방법론.

칸반의 역할과 책임

칸반은 새로운 직책을 규정하지 않으며, 이는 의도적인 것입니다. 세 번째 원칙은 기존 역할을 존중하라고 요구하기 때문입니다. 개발자는 개발자로 남습니다. 하지만 실제로는 칸반이 성숙해짐에 따라 두 가지 책임이 드러나며, 성숙한 구현에서는 이러한 책임을 명시적으로 명명합니다.

The 서비스 제공 관리자 보드를 통한 작업 흐름을 관리하는 책임자입니다. 진행이 멈춘 카드를 감시하고, 문제 발생 시 보고하며, 각 열의 WIP(작업 진행 중) 한도를 유지하고, 팀이 자체 사이클 타임 데이터를 검토하는 회의를 진행합니다. 서비스 요청 관리자 보드에 들어오는 항목을 관리하며, 요청을 제기하는 고객을 대표하고, 할 일 목록 열을 정렬하여 가장 가치 있는 항목이 맨 위에 오도록 하고, 선택 정책을 명확히 합니다.

둘 다 인력 증원이 아니라 책임 사항이며, 한 사람이 두 가지 모두를 담당하는 경우가 많습니다. 중요한 것은 누군가는 흐름을, 누군가는 입고를 책임져야 한다는 것이고, 그들이 관리하는 결과물은 그 다음 문제입니다.

칸반 카드

칸반 방식은 작업 시각화를 권장합니다. 물리적 보드와 디지털 보드를 활용할 것을 제안하며, 아래 그림은 카드가 배치된 열들을 보여줍니다.

칸반 카드는 팀이 진행 중인 작업을 나타내기 때문에 칸반 보드의 필수 요소입니다. 이 카드에는

1. 우선
2. 대표이사
3. 타입
4. 마감일

칸반보드의 열은 작업 단계를 나타내며 해당 열에 WIP(Work in Progress) 제한을 설정할 수 있습니다. WIP 한도는 해당 열에 머무를 수 있는 최대 카드 수를 의미합니다..

칸반 방식은 끌어당기는 방식을 사용하기 때문에 개발자는 시간이 날 때마다 할 일 목록에서 개발 목록으로 카드를 가져올 수 있습니다. 이러한 카드가 놓이는 보드를 좀 더 자세히 살펴볼 필요가 있습니다.

칸반 보드

칸반 보드 Kanban을 구현하여 개인 및 비즈니스 목적으로 프로젝트를 관리하는 데 도움이 되는 민첩한 프로젝트 관리 도구입니다. 팀이 다양한 단계와 프로세스에서 작업을 시각화할 수 있도록 설계된 물리적 또는 디지털(JIRA) 보드입니다. 또한 카드를 사용하여 열 작업 단계를 나타내는 데 도움이 됩니다.

다음과 같은 작업 상태를 나타내는 열이 있습니다.

1. 할 것,
2. 데브
3. 지원
4. 만들기

이러한 각 열에는 WIP 한도 미만의 카드가 있을 수 있습니다. 카드는 실제 작업을 나타냅니다.

진행 중인 작업의 범위를 제한하기 위해 양수를 사용할 수 있으며, 이 제한 숫자는 물리적 및 디지털 칸반 보드의 각 열 상단에 표시할 수 있습니다. 팀의 모든 구성원은 자신의 카드 상태를 관리할 수 있으며, 팀 전체는 워크플로를 시각화할 수 있습니다. Digi탈 보드와 같은 것들 지라 자동 주기 시간과 동일한 제한 사항을 추가합니다. trac왕. 다음으로, 해당 열들이 나타내는 칸반 워크플로에 대해 알아보겠습니다.

칸반 워크플로우

칸반 워크플로우 팀이 Kanban에서 명시적인 정책과 원칙을 정의하는 데 도움이 되는 일련의 단계입니다. 이는 개발 및 전달 주기의 다양한 단계에 걸쳐 작업이 진행되는 동안의 규칙과 절차를 나타냅니다. Kanban 워크플로는 특정 작업의 시작과 전달 사이의 단계별 프로세스로 구성됩니다.

Kanban의 기본 원칙은 다음과 같습니다. "시작을 멈추고 마무리를 시작해라". WIP 제한의 도움으로 더 많은 작업이 완료됩니다. JIRA와 같은 최신 도구에서는 사용자 정의 가능한 Kanban 워크플로와 상태를 사용할 수 있습니다.

다음은 많은 소프트웨어 팀이 워크플로 관리를 위해 따르는 기본 상태입니다.

"준비" 상태는 작업이 아니라 대기열이라는 점에 유의하세요. 카드는 대기열에 무기한으로 머무를 수 있으므로, 상태 자체보다는 카드를 이동시키는 규칙이 더 중요합니다.

풀 기반 시스템

Kanban은 작업을 푸시하는 대신 가져오는 풀 기반 방법입니다. 현재 카드를 완성하자마자 칸반 보드의 이전 열에서 새 카드를 가져올 수 있습니다.

WIP 제한을 통해 칸반은 리드 타임과 사이클 타임을 개선하는 데 도움이 됩니다. 이 두 타이밍 사이에 가능한 한 최소한의 간격이 있어야 합니다. 예를 들어, 개발자가 5명이고 테스터가 1명뿐인 경우 어떻게 될까요? 테스트가 필요한 카드가 항상 많을 것이고, 그들은 유휴 상태로 대기할 것입니다.

위에서 언급한 문제를 극복하고 효율성을 향상시키기 위해 Kanban은 끌어올 수 있는 카드 수가 제한된 WIP 제한이 있는 풀 기반 접근 방식을 따릅니다.

따라서 테스터는 현재 작업을 완료하면 "테스트 준비" 단계에서 작업을 가져옵니다. Kanban 열(개발 단계)의 WIP 제한을 사용하면 Kanban 워크플로에 무인 카드가 많지 않습니다.

당기기 기반 시스템은 팀에 적합한 속도를 찾는 데에도 도움이 됩니다. 적절한 속도가 확보되면 팀의 경기력은 향상됩니다. 이 모든 것은 단 하나의 수치, 즉 WIP 제한에 달려 있습니다.

WIP 제한(작업 진행 중)

칸반 방식에서 WIP(작업 진행 중)는 팀 구성원 또는 전체 팀이 한 번에 처리할 수 있는 작업/카드의 수를 제한합니다.

WIP 제한은 팀이 작업을 안정화하고 풀 기반 시스템에 필수적인 예측 특성을 향상하도록 보장합니다. 일반적으로 WIP 한도는 팀 자체에서 결정합니다.

WIP 한도를 설정하는 이유

WIP 한도를 설정하는 이유는 다음과 같습니다.

• 한 번에 한 가지 작업에만 집중하면 일을 처리하는 데 초점을 맞출 수 있습니다.
• 이는 팀이 자신의 역량을 이해하는 데 도움이 됩니다.
• 생산성 리드와 사이클 타임을 향상시킵니다.
• 작업이 쌓이는 것을 방지하는 데 도움이 됩니다(대기 모드에서).
• 이는 작업 흐름의 원활함을 개선하여 작업이 계속 진행되도록 합니다.
• 또한 개인이 여러 작업을 번갈아 가며 수행하지 않으므로 작업 방해 요소를 해결하는 데 도움이 됩니다.

⚠️ 경고: 한도를 너무 높게 설정하면 한도가 없는 것과 마찬가지이므로 카드 대기열이 발생하고 처리 시간이 길어집니다. 반대로 한도를 너무 낮게 설정하면 담당자들이 대기 상태에 놓이게 됩니다. 한 번에 한 열의 한도만 변경하고 2주 동안 처리 시간을 관찰해 보세요.

이것으로 이론적인 부분은 끝났습니다. 아래 섹션에서는 이를 실제 행동으로 옮기는 방법을 설명합니다.

칸반을 단계별로 구현하는 방법

칸반은 시작하기 쉽습니다. 첫 번째 단계는 이미 하고 있는 일을 설명하는 것입니다. 팀원 전체가 참석한 상태에서 이 단계를 순서대로 진행하세요.

1. 현재 워크플로를 도식화하세요. 완성된 항목 하나를 역순으로 따라가며 해당 항목이 거쳐간 모든 인수인계를 확인합니다. 각 인수인계는 열이 되며, 공식적으로 소유권이 없는 대기 상태도 포함됩니다.
2. 보드판을 그리세요. 각 주별로 한 칸씩, 왼쪽에서 오른쪽으로 쓰고 마지막 칸에는 '완료'라고 적으세요. 첫 달에는 화이트보드에 포스트잇을 붙이면 충분합니다.
3. 카드를 작성하세요. 기내의 모든 물품에 우선순위, 소유자, 종류 및 반납일을 적은 카드를 부여한 다음, 해당 물품의 실제 상태에 맞는 열에 배치하십시오.
4. 각 열에 대해 "완료"를 정의하십시오. 퇴장 기준을 칠판에 적으세요. 이렇게 명확한 정책을 세우는 것이 카드가 뒤로 튕겨 나가는 것을 방지하는 방법입니다.
5. 초기 작업 진행 상황(WIP) 한도를 설정합니다. 아래 방법을 사용하여 '할 일'과 '완료' 열을 제외한 모든 열에 시작 번호를 선택한 다음, 제목 위에 해당 번호를 적으세요.
6. 당기기 규칙에 동의하세요. 자신의 열이 최대치에 도달했을 때는 아무도 새 카드를 시작하지 않습니다. 대신 오른쪽 열을 비우는 것을 돕습니다.
7. 매일 보드 위를 걸어보세요. 오른쪽에서 왼쪽으로, 가장 오래된 카드부터 차례대로 이동하며, 이 카드를 막고 있는 것은 무엇이고 오늘 누가 이 카드를 막을 수 있는지 묻습니다.
8. 측정한 후 조이세요. 2주 후, 사이클 타임 데이터를 통해 어느 열에 카드가 가장 오래 보관되는지 확인할 수 있습니다. 해당 제한을 낮추거나 용량을 추가한 후, 데이터를 다시 분석하세요.

5단계는 대부분의 팀이 정체되는 단계이므로 실무자들이 사용하는 세 가지 규모 산정 방법을 소개합니다.

첫 번째 숫자를 가설로 간주하십시오. 보드를 공식적인 것과 짝지어 보세요. 민첩한 테스트 테스트 열이 병목 현상이 되는 것을 방지하며, 아래 두 가지 시간 측정 결과는 이것이 제대로 작동하는지 보여줍니다.

리드타임 및 사이클타임

칸반 방식에서는 리드 타임과 사이클 타임이라는 용어가 널리 사용되는데, 이 둘 사이에는 차이가 있으므로 혼동을 피하기 위해서는 이를 명확히 이해하는 것이 중요합니다.

여기서는 출시 준비부터 실제 출시까지 걸리는 시간을 포함하지 않는다는 점을 이해하는 것도 중요합니다.

Cycle Time = Work in Progress/Throughput

💡 팁: 리드 타임은 고객이 체감하는 시간이고, 사이클 타임은 팀이 관리하는 시간입니다. 리드 타임과 사이클 타임 사이에 큰 차이가 있으면 작업이 시작되기 전에 대기 시간이 길어지므로, 팀의 작업 속도를 높이기 전에 먼저 작업량 처리 속도를 개선해야 합니다.

이상적인 시나리오에서는 리드 타임과 사이클 타임의 차이가 최소화되어야 하며, 칸반은 누적 흐름도(CFD)를 사용하여 리드 타임과 사이클 타임의 과거 데이터를 측정합니다. 이 흐름도는 다음 섹션에서 자세히 다룹니다.

누적 흐름도(CFD)

CFD는 모든 주요 차트에서 사용할 수 있는 차트입니다. 워크플로 관리 도구 JIRA처럼요. 이 차트는 워크플로에 입력되고 시간이 지남에 따라 완료된 카드/작업을 축적한 작업 카드/작업의 총량을 측정합니다.

미리 지정된 시간에 대한 평균 리드타임과 사이클 시간을 추정하는 데 도움이 됩니다.

CFD 다이어그램은 개선해야 할 문제 영역을 알려주는 지표 역할을 합니다. 이 다이어그램을 통해 명확한 그림을 얻을 수 있으며, 이를 바탕으로 팀의 리드 타임과 사이클 타임을 조정할 수 있습니다. 아래의 누적 흐름 다이어그램은 각 단계를 색상 띠로 표시하며, 띠가 넓어질수록 병목 현상이 발생합니다.

차트는 네 가지 수치를 통해 읽습니다.

1. 리드 타임: 워크플로에 새 카드가 도착하는 시점부터 워크플로에서 최종적으로 벗어나는 시점까지의 시간입니다.
2. 사이클 타임: 카드가 작동 상태에 도달하는 시점과 카드가 출시될 준비가 되는 시점 사이의 기간입니다.
3. WIP: 진행 중인 작업(WIP)은 워크플로의 다양한 단계에서 작업 항목의 최대 양을 제한합니다.
4. 맞춤형 설비: 실제 실적이며, 특정 기간 동안 실제 전달된 카드 수를 알려줍니다.

Throughput = WIP/Cycle Time

그 내용은 산출물, 메커니즘, 그리고 측정 지표를 다룹니다. 남은 질문은 칸반이 스크럼과 어떻게 다른가 하는 것입니다.

스크럼 대. 칸반

다음은 사이의 중요한 차이점입니다. 스크럼 대. 칸반더 넓은 관점을 보려면 다음을 참조하세요. 애자일 vs. 스크럼.

자주 묻는 질문