닫기

칸반

소프트웨어 개발에 칸반 방법론이 적용되는 방식

칸반이란?

칸반은 애자일 소프트웨어 개발 구현 시 많이 사용되는 프레임워크입니다. 여기에는 용량에 대한 실시간 통신과 작업의 완전한 투명성이 요구됩니다. 작업 항목은 칸반 보드에 시각적으로 표시되므로 팀원은 언제든지 모든 작업 상태를 볼 수 있습니다.

Kanban articles

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

소프트웨어 팀을 위한 칸반

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

이 프레임워크의 핵심 원칙은 시간이 지나도 변하지 않으며 거의 모든 산업에 적용할 수 있지만, 동시에 소프트웨어 개발 팀에서는 애자일 프랙티스를 이용해 보다 뛰어난 성과를 이룰 수 있었습니다. 이러한 성과 달성 요인 중 하나는 소프트웨어 팀이 기본 원칙을 이해하기만 하면 거의 오버헤드 없이 프랙티스를 이용할 수 있다는 점입니다. 실제 프로세스가 변경되고 실제 자재가 포함되는 공장에서의 칸반 구현과 달리, 소프트웨어 팀에 필요한 실제 물건은 보드와 카드이며, 이 또한 가상으로 구현할 수 있습니다.

칸반 보드

모든 칸반 팀의 업무는 업무를 시각화하고 팀 간 워크플로우를 최적화하는 데 사용되는 도구인 칸반 보드를 중심으로 이루어집니다. 실제 보드를 선호하는 팀도 있지만, 가상 보드는 애자일 소프트웨어 개발 도구에서 추적성, 용이한 협업, 여러 위치에서의 접근성에 필요한 중요한 기능입니다.

팀에서 실제 보드를 사용하든지, 디지털 보드를 사용하든지 관계없이, 이를 사용하여 팀 업무를 시각화하고, 워크플로우를 표준화하며, 모든 장애물 및 종속성을 즉시 식별하고 해결할 수 있습니다. 기본 칸반 보드에는 수행할 작업, 진행 중인 작업, 완료된 작업의 3단계로 구성된 워크플로우가 포함되어 있습니다. 그러나 팀의 규모, 구조 및 목표에 따라 워크플로우를 매핑하여 특정 팀의 고유 프로세스를 따를 수 있습니다.

칸반 방법론은 업무의 완전한 투명성과 생산 능력을 실시간으로 전달하는 것이 핵심이므로, 칸반 보드는 팀 업무의 SSoT(Single Source of Truth)로 간주되어야 합니다.

Agile Kanban Board | Atlassian agile coach

칸반 카드

칸반을 문자 그대로 일본어로 번역하면 "시각적 신호"입니다. 칸반 팀에게 모든 업무 항목이 보드에 개별 카드로 표시됩니다.

업무를 칸반 보드에서 카드로 표시하는 주요 목적은 팀원들이 워크플로우 전체에서 업무의 진행 상황을 매우 시각적인 방식으로 트래킹할 수 있도록 하는 것입니다. 칸반 카드는 특정 업무 항목에 대한 중요 정보를 담고 있으며, 팀 전체에 해당 업무 항목의 담당자, 완료된 작업의 간략한 설명, 해당 업무의 예상 소요 시간 등에 대한 완벽한 가시성을 제공합니다. 가상 칸반 보드의 카드에는 종종 스크린샷을 비롯하여 피할당자에게 매우 중요한 기타 기술적인 세부 정보도 포함됩니다. 팀원들이 언제든지 모든 업무 항목의 상태와 모든 관련 세부 정보를 확인할 수 있으므로 집중도가 높아지고 추적성이 향상되며 장애물과 종속성을 더 빨리 식별할 수 있습니다.

The benefits of Kanban

칸반은 오늘날 애자일 팀에게 가장 사랑받는 소프트웨어 개발 방법론 중 하나입니다. 팀 규모와 관계없이 칸반은 작업 계획 및 처리량 측면에서 여러 가지 장점을 추가로 제공합니다.

기획 유연성

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

여러 스킬셋을 중첩시켜서 사이클 타임을 단축시킬 수 있습니다. 특정 스킬셋을 보유한 사람이 한 명뿐인 경우 해당 팀원이 업무를 처리할 때까지 워크플로우상 이후 처리가 지연됩니다. 따라서 팀은 코드 리뷰 및 멘토링 지원과 같은 기본 모범 사례를 채택하여 지식을 널리 공유합니다. 스킬을 공유하면 팀원들이 여러 종류의 업무를 수행할 수 있게 되므로 사이클 타임의 최적화 수준을 향상시킬 수 있습니다. 또한 업무 백업이 있는 경우 전체 팀이 그 업무에 매달려 프로세스 흐름을 다시 원활하게 할 수 있습니다. 예를 들어, QA 엔지니어만 테스트를 수행하는 것이 아니라 개발자도 참여합니다.

칸반 프레임워크에서는 전반적인 프로세스에서 업무가 원활하게 진행되는지 확인하는 것은 모든 팀원의 책임입니다.

병목 감소

멀티태스킹은 효율성을 저해합니다. 특정 시간에 진행 중인 업무 항목의 수가 많을수록 맥락이 자주 바뀌어 완료하는 데 더 많은 시간이 소요됩니다. 이러한 이유로 인해 칸반은 진행 중인 업무(WIP)의 양을 제한하는 데 중점을 둡니다. 진행 중인 업무를 제한하면 집중도, 인원 또는 스킬셋 부족으로 인한 팀 내 프로세스의 병목 및 백업이 강조 표시됩니다.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

시각적 지표

핵심 가치 중 하나는 모든 업무 반복을 통해 팀의 효율성 및 효과를 지속적으로 향상시키는 데 집중하는 것입니다. 팀은 차트에서 제공하는 시각적 메커니즘을 통해 계속 개선해 나갈 수 있습니다. 팀에서 데이터를 확인할 수 있으면 프로세스 내의 병목을 더 쉽게 발견하고 제거할 수 있습니다. 칸반 팀에서 공통적으로 사용하는 두 가지 보고서는 컨트롤 차트 및 누적 흐름도입니다.

컨트롤 차트에서 각 이슈의 사이클 타임 및 팀의 롤링 평균을 확인할 수 있습니다.

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

누적 흐름도에는 이슈의 개수가 상태별로 표시됩니다. 팀은 지정된 상태별로 증가한 이슈 개수를 확인하여 병목 요인을 쉽게 찾아낼 수 있습니다. "진행 중" 또는 "검토 중"과 같은 중간 상태의 이슈는 아직 고객에게 출시되지 않은 것으로, 해당 상태의 병목 요인으로 인해 업무가 업스트림으로 병합될 때 대량의 통합 충돌이 발생할 가능성이 증가할 수 있습니다. 

Cumulative Flow Diagram

지속적 배포 (Continuous Delivery)

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

스크럼과 칸반 비교

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
간격

정기적이고 시간이 고정된 스프린트(즉, 2주)

 지속적 흐름
릴리즈 방법론 제품 소유자의 승인이 있는 경우 각 스프린트 종료 시 지속적 배포 또는 팀의 재량으로
역할 제품 소유자, 스크럼 마스터, 개발 팀 기존 역할이 없습니다. 일부 팀에서 애자일 코치의 도움을 요청합니다.
주요 지표 속도 사이클 타임
변경 철학 팀은 스프린트 중에 스프린트 예측을 변경하지 않도록 주의해야 합니다. 이를 변경하면 추정에 대해 정확히 파악할 수 없습니다. 변경은 언제든지 발생할 수 있습니다.

 

일부 팀에서는 칸반과 스크럼의 장점을 "Scrumban"으로 결합합니다. 스크럼에서는 시간이 고정된 스프린트 및 역할을, 칸반에서는 진행 중인 업무 제한에 대한과 사이클 타임을 채택한 것입니다. 그러나 애자일을 처음 시작하는 팀의 경우 두 가지 방법론 중 하나를 선택하여 일정 기간 실행해 볼 것을 강력히 권장합니다. 나중에 언제든지 결합하여 사용할 수 있습니다. 

Dan Radigan
Dan Radigan

저는 일에서나 개인적으로나 애자일에 큰 영향을 받았으며, 애자일을 통해 코딩을 할 때도, 삶에서도 최고의 경험을 누릴 수 있었습니다. 저는 기술, 사진, 모터사이클에 깊은 관심이 있습니다. Twitter에서 @danradigan을 찾아 주세요.

Up Next
보드