본문 바로가기

1.관리 및 아키텍처

[kanban] 칸반보드

들어가기

칸반보드는 개인 혹은 작은 조직에서 작업을 관리를 위한 칸반을 구현하기 위한 도구이다. 칸반보드는 직관적이기 때문에 쉽게 적용할 수 있는 장점이 있다.

작성자: ospace114@empal.com, http://ospace.tistory.com/

칸반보드란

칸반보드는 연속적 작업 흐름에 대한 처리 방식을 정의하고 있다. 칸반보드의 특징은 프로세스 단계를 컬럼으로 시각적으로 분리하고 프로세스 단계의 작업을 표시한다. 또한 작업을 왼쪽 컬럼에서 오른쪽 컬럼으로 이동하면서 진행상황을 표시한다.

출처:  https://ko.wikipedia.org/wiki/%EA%B0%84%EB%B0%98_%EB%B3%B4%EB%93%9C

모든 이슈는 큐에 입력되고, 개발 프로세스는 큐에 있는 이슈를 가져와서 처리한다. 오른쪽으로 이동하면 단계별로 처리가 되며 최종적으로 완료 처리한다. 큐에는 우선순위 높은 이슈가 높은 위치에 놓이게 된다.

칸반의 핵심은 WIP(Work-In-Process)으로 동시에 개발할 수 있는 작업 수를 제한함으로써 생산성과 속도를 조절한다. 스크럼인 경우는 스프린트를 이용해 작업 제한으로 생산성 조절(추정)한다.
WIP로 인해 프로젝트 관리 오버헤드가 최소화된다. 에자일에서 스프린트 플래닝이 없고 프로젝트 관리를 위한 자원이 줄어든다. 또한 에자일에서 추정에 대한 부담감 감소한다. 그렇다고 추정이 전혀 없는게 아니다. 또한 전문 스크럼 마스터 필요 없고 스크럼 회고는 개선회의로 대체될 수 있다. 말 그대로 개선을 위한 방안에 대해서만 집중한다.

물론 이런 부분들은 자신 조직에 맞게 보완해서 적용할 수 있다.

칸반보드 운영안

먼저 칸반 행(swimlane)을 구성해야 한다. 예를 들어 아래 처럼 5개 행으로 구성할 수 있다.

  • ToDo(할것): 해야할 작업 큐로 우선순위에 따라 위에서 아래로 나열된다.
  • In Progress(작업중): 현재 처리중인 작업이다.
  • Test(테스트): 작업이 완료되서 테스트 검증하는 단계이다.
  • Postpone(보류): 긴급하게 처리할 작업으로 인해 임시 중지된 작업이 놓인다.
  • Done(완료): 작업이 모두 완료된 경우이다.

칸반 행은 더 세분하거나 변경할 수 있다. 현재 작업하는 절차에 맞게 구성할 수 있다.
칸반 행까지 구성했으면 이를 기반으로 어떻게 운영할지 기본 원칙을 정해야 한다. 아래는 기본 가이드로 참고하시기 바란다.

  • ToDo에서 우선순위에 따라 관리자에 의해 임의로 작업 배치
  • In Progress 이후 흐름부터는 개발자 책임으로 다른 요청은 불가
  • 작업이 In Progress에 들어가면 예측시간 산출하고 진행
  • Postpone은 개인별로 최대 1개만 유지하며 가급적 사용은 지양
  • Postpone에 있는 작업은 재검토해서 다른 행으로 이동
  • 특별한 경우가 아니면 회의는 1:1로 진행하고 긴급한 안건이 아니면 이메일/메신저를 통해서 전달
  • 새로운 기능이나 변경이 발생할 경우 활발한 소통 진행

운영원칙은 절대로 지켜야할 기준으로 확립하는게 좋다. 또한 이런 개발 과정 중간에 개선회의가 필요하다. 에자일과 비슷하게 매 2주마다 개선회의를 진행하며, 이전작업 비판보다 개선위주로 검토를 한다. 예를 들어 개선회의 다음과 같은 안건이 도출되었다.

  • Postpone은 2개 이상 유지하는 경우 발생
  • 개선회의는 열리지 않음
  • 예측시간 산출이 없는 경우가 있음
  • 먼저 작업이 진행되고 ToDo에는 나중에 등록

아마도 쉽게 발생할 수 있는 상황이라고 생각든다. 그렇다면 누가 잘못인지 따지기 보다, 어떻게 하면 해결할 수 있는지 다양한 아이디어를 시도할 수 있다.

마무리

칸반보드는 어떻게 보면 개발자가 개발에 집중하도록 최대한 환경을 만들어준다고 보면된다. 그렇다고 개발자 간에 의사소통을 하지 말라는게 아니다. 그리고 불필요한 회의 최소화와 예측시간에 대한 고민을 줄여준다. 어떻게 보면 개발자 자신의 역량을 최대한 끌어낸다고 보면 된다.
ToDo행을 별도로 구성했지만 애자일 처럼 Backlog로 별도로 만들어서 작업 큐 관리를 할 수도 있다. 앞에는 언급이 없지만 작업이 많이 완료되면 Done 행에 목록이 많아진다. 이럴 경우 Done 행을 비워지는 부분도 고려해야 한다. 예를 들어 마일스톤이나 릴리즈 작업이 있을 수 있다.
얼핏보면 칸반이 매우 매력적으로 보일 수 있다. 칸반은 긴박감이 없기 때문에 업무에 대한 긴장감이 없을 수 있다. 그렇기에 팀 동기부여에 대해 고민이 필요할 수 있다.
추가로 용어가 간반, 또는 칸반으로 쓰이고 있는데, 영어 표기상 칸반이 좀더 비슷해 보여서 칸반으로 사용했습니다.^^;
부족한 글이지만 여러분에게 도움이 되었으면 하네요. 모두 즐거운 코딩하세요.ospace.

참고

[1] 간반 보드, https://ko.wikipedia.org/wiki/%EA%B0%84%EB%B0%98_%EB%B3%B4%EB%93%9C\
[2] Alex Salazar 저; Cho Minkyu 역, 잘가요 스크럽, 반가워요 칸반, https://medium.com/@pitzcarraldo/%EB%B2%88%EC%97%AD-%EC%9E%98-%EA%B0%80%EC%9A%94-%EC%8A%A4%ED%81%AC%EB%9F%BC-%EB%B0%98%EA%B0%80%EC%9B%8C%EC%9A%94-%EC%B9%B8%EB%B0%98-e27d1db15699

반응형