Kanban

Now let’s look at Kanban. It’s a smaller and more lightweight framework. All agile methods by definition are lightweight, but Kanban is lighter as compared to the others like scrum. It does not define as much of the agile process as scrum does. For example, it is up to the Kanban team to decide which ceremonies to use, if any. Because it is a more bare-bones way to achieve agility, Kanban is often used as an evolutionary approach to agile. It doesn’t require reorganization, new types of meetings or new roles. You can start implementing it now and become more agile over time.

이제 칸반을 살펴봅시다. 칸반은 더 작고 가벼운 프레임워크입니다. 정의상 모든 애자일 방법은 가볍지만, 칸반은 스크럼과 같은 다른 방법과 비교했을 때 더 가볍습니다. 스크럼처럼 애자일 프로세스의 많은 부분을 정의하지는 않습니다. 예를 들어, 어떤 의식을 사용할지 결정하는 것은 칸반 팀의 몫입니다. 칸반은 애자일을 달성하기 위한 보다 기초적인 방법이기 때문에 애자일에 대한 진화적 접근 방식으로 자주 사용됩니다. 조직 개편, 새로운 유형의 회의 또는 새로운 역할이 필요하지 않습니다. 지금 바로 실행을 시작하여 시간이 지남에 따라 더 민첩해질 수 있습니다.

Kanban is for teams that work with a continuous flow of issues. New issues are continuously added to the backlog and are always being prioritized, usually by the business team. Work is also continuously being finished before starting new work. Kanban is excellent for service-based teams, customer support, help desk and operations teams, and for other ongoing work that has to be prioritized but does not involve planning.

칸반은 이슈가 지속적으로 발생하는 팀에 적합합니다. 새로운 이슈는 백로그에 지속적으로 추가되며, 보통 비즈니스 팀에서 항상 우선순위를 정합니다. 또한 새로운 작업을 시작하기 전에 지속적으로 작업을 마무리합니다. 칸반은 서비스 기반 팀, 고객 지원, 헬프 데스크 및 운영 팀, 그리고 우선순위를 정해야 하지만 계획과 관련이 없는 기타 진행 중인 작업에 적합합니다.

A main focus of Kanban is to improve the flow by limiting work in progress before starting new issues. At any given time, the team should only be working on what they can handle sustainably. This has many benefits. There is less multitasking, less waste, and less rework; which leads to increased productivity and faster delivery due to the improved flow. Bottlenecks are identified much quicker because there are fewer issues in progress at any time and problems more easily visible. Identifying and fixing those bottlenecks continuously improves the work of the team. And in turn, this promotes teamwork as everyone works together to clear the impediments.

칸반의 주요 초점은 새로운 이슈를 시작하기 전에 진행 중인 작업을 제한하여 흐름을 개선하는 것입니다. 언제든지 팀은 지속적으로 처리할 수 있는 작업만 진행해야 합니다. 여기에는 많은 이점이 있습니다. 멀티태스킹, 낭비, 재작업이 줄어들어 생산성이 향상되고 개선된 흐름으로 인해 납기가 빨라집니다. 진행 중인 이슈가 줄어들고 문제를 더 쉽게 파악할 수 있기 때문에 병목 현상을 훨씬 더 빨리 식별할 수 있습니다. 이러한 병목 현상을 파악하고 해결하면 팀의 업무가 지속적으로 개선됩니다. 또한, 모두가 함께 협력하여 장애물을 제거함으로써 팀워크가 증진됩니다.

For many steps of a process, it is better for someone working on the next step to pull the work from the previous step rather than having it pushed on them when the previous step is finished. Pulling work is common on agile, self-organizing, empowered teams because it enables team members to select their work – when they have availability – rather than being assigned work when they don’t. Pulling also maintains a sustainable pace. Kanban uses both pull and push. For example, when new issues are ready to be worked on, they are pushed from Backlog to the Selected for Development. When a person is ready to work on the issue, he pulls the issue (using drag-and-drop) from Selected for Development into the In Progress column. When the developer is done, he pushes the issue onto the Done column. The overall Kanban process is a pull system.

프로세스의 많은 단계에서, 이전 단계가 끝났을 때 다음 단계의 작업자에게 작업을 밀어넣는 것보다 이전 단계의 작업을 끌어오는 것이 더 좋습니다. 풀링 작업은 팀원들이 여유가 없을 때 작업을 할당받는 대신 여유가 있을 때 작업을 선택할 수 있기 때문에 민첩하고 자율적이며 권한이 부여된 팀에서 흔히 사용됩니다. 풀링은 또한 지속 가능한 속도를 유지합니다. 칸반은 풀링과 푸시를 모두 사용합니다. 예를 들어, 새 이슈가 작업할 준비가 되면 백로그에서 개발용으로 선택됨으로 푸시됩니다. 개발자가 이슈를 작업할 준비가 되면 드래그 앤 드롭을 사용하여 이슈를 개발용으로 선택됨에서 진행 중 열로 끌어옵니다. 개발자가 작업을 완료하면 이슈를 완료 열로 밀어 넣습니다. 전체 칸반 프로세스는 풀 시스템입니다.

• By default, the entire prioritized backlog of work is visible to the team in the Kanban board.

• Tasks are prioritized and then pulled from the top of the queue by a team member when they are ready for more work.

• Work is also completed one-by-one in a continuous process.

• Issues can be released from the Done column on the board, periodically or as needed.

• 기본적으로 우선순위가 지정된 전체 작업 백로그가 칸반 보드에서 팀원에게 표시됩니다.

• 작업은 우선순위가 지정된 다음 팀원이 더 많은 작업을 할 준비가 되면 대기열의 맨 위에서 끌어올려집니다.

• 또한 작업은 연속적인 프로세스를 통해 하나씩 완료됩니다.

• 이슈는 보드의 완료 열에서 주기적으로 또는 필요에 따라 릴리즈할 수 있습니다.

By default, Kanban backlog is in the first column of a Kanban board, along with the rest of the columns. This may be sufficient if there are only a few issues in the backlog. But as a backlog grows, viewing and scrolling through these issues can become difficult.

• Therefore, it’s possible to enable the Kanban backlog.

• If you're planning work for your team, you have a separate and bigger space to create and rank issues and select issues for your team to start working on. You can triage and plan before sending the tasks to the team for development by dragging them up into the Selected for Development area (or to the next status in your workflow, if it has been customized).

• These items then appear on the main Kanban board, so team members can focus on working without the distraction of planning. And managers can see the progress of what is actually being worked on.

• The Epics Panel can also be (optionally) enabled in the Kanban backlog. If it is enabled, it has the same functionality as in Scrum boards.

기본적으로 칸반 백로그는 칸반 보드의 첫 번째 열에 나머지 열과 함께 표시됩니다. 백로그에 이슈가 몇 개만 있는 경우에는 이 정도면 충분할 수 있습니다. 하지만 백로그가 늘어나면 이슈를 보고 스크롤하는 것이 어려워질 수 있습니다.

• 따라서 칸반 백로그를 활성화할 수 있습니다.

• 팀을 위해 작업을 계획하는 경우, 별도의 더 큰 공간에서 이슈를 만들고 순위를 매기고 팀이 작업을 시작할 이슈를 선택할 수 있습니다. 개발용으로 선택됨 영역(또는 워크플로우가 사용자 지정되어 있는 경우 워크플로우의 다음 상태)으로 드래그하여 작업을 팀에 보내기 전에 분류하고 계획할 수 있습니다.

• 그러면 이러한 항목이 메인 칸반 보드에 표시되므로 팀원들은 계획에 방해받지 않고 작업에 집중할 수 있습니다. 그리고 관리자는 실제로 작업 중인 항목의 진행 상황을 확인할 수 있습니다.

• 에픽 패널은 칸반 백로그에서 (선택 사항으로) 활성화할 수도 있습니다. 활성화하면 스크럼 보드에서와 동일한 기능을 사용할 수 있습니다.

As mentioned earlier, work in progress limits can improve the flow of value by preventing multitasking and focusing the team on issues already in progress before starting new ones.

• You can set the minimum and/or maximum number of issues allowed in certain board columns.

• If the number of issues in those columns falls outside the threshold, the background color of the column changes; yellow (if there are fewer issues than minimum) or red (if there are more issues than the maximum).

• What WIP limits should be set to depends on the specific project and the team.

• They may start with no limits and see if the issues are flowing nicely, then add limits as the process starts to show problems

• Or they may add them to discourage multitasking.

• Or to set minimums on steps that the team tends to neglect.

• Backlog or done columns generally don’t have limits, because those statuses do not contain the team's work in progress.

앞서 언급했듯이 진행 중인 작업 제한은 멀티태스킹을 방지하고 팀이 새로운 작업을 시작하기 전에 이미 진행 중인 이슈에 집중할 수 있도록 하여 가치의 흐름을 개선할 수 있습니다.

• 특정 보드 열에 허용되는 이슈의 최소 및/또는 최대 개수를 설정할 수 있습니다.

• 해당 열의 이슈 수가 임계값을 벗어나면 열의 배경색이 노란색(최소값보다 이슈 수가 적은 경우) 또는 빨간색(최대값보다 이슈 수가 많은 경우)으로 변경됩니다.

• WIP 한도는 특정 프로젝트와 팀에 따라 설정해야 합니다.

• 제한 없이 시작하여 이슈가 원활하게 진행되는지 확인한 다음 프로세스에 문제가 보이기 시작하면 제한을 추가할 수 있습니다.

• 또는 멀티태스킹을 막기 위해 제한을 추가할 수도 있습니다.

• 또는 팀이 소홀히 하는 경향이 있는 단계에 최소값을 설정할 수도 있습니다.

• 백로그 또는 완료 열에는 일반적으로 팀의 진행 중인 작업이 포함되지 않으므로 제한이 없습니다.

Kanban boards focus on improving the flow of issues through the workflow. There are two reports available to facilitate this;

• the Cumulative Flow Diagram

• and the Control Chart

칸반 보드는 워크플로우를 통해 이슈의 흐름을 개선하는 데 중점을 둡니다. 이를 촉진하는 데 사용할 수 있는 두 가지 보고서가 있습니다;

• 누적 흐름 다이어그램

• 제어 차트