상세 컨텐츠

본문 제목

칸반에서 진행 중 상태의 작업 제한하기

테스팅 번역 자료들

by techbard 2023. 2. 10. 22:57

본문

반응형

 

2020년 6월 8일

 

칸반 프로젝트 관리 방법론에서 진행 중 상태의 작업을 (work in progress) 제한한다는 개념은 한 팀이 수행하는 작업량이나 작업 흐름 상에서 활성 상태로 존재하는 작업의 최대치를 정의한다. Gerard Chiva는 이 기고에서 진행 중 상태의 작업을 제한하는 것이 왜 애자일 팀에게 중요한 결정인지 설명한다.

 

저자: Gerard Chiva, AKTIA 솔루션즈, https://aktiasolutions.com/

 

칸반 방식을 적용할 때 큰 도전과제 중 하나는 진행 중인 작업 제한이다 (work-in-progress, WIP). 그 회사의 산업군과 업력 그리고 크기에 상관없이, 적기 출시와 생산성 향상을 위해 칸반에서 WIP 제한을 사용하는 개념은 직관에 반대되며 전통적인 가치관에 크게 위배된다.

 

이제 이것을 확실히 살펴보자. 당신이 WIP를 제약하지 않으면 칸반의 효능을 볼 수 없다. 당신이 PULL을 구현하기 위해서는 WIP를 제한해야 한다. 스티커 몇 개로 대시보드를 만드는 일은 칸반이 아니다. 그건 그냥 스티커 몇 개를 붙인 보드일 뿐이다.

 

우리가 칸반을 적용하고자 할 때는 우리 시스템의 현재 처리 용량과 요구량 사이의 균형을 잡으면서 시작한다. 이렇게 진행하면서 진화적인 개선이 시작된다.

 

칸반에서 WIP를 제약하는 것에 관해 반대하는 목소리가 있었나?

 

그리고 우리가 한 번에 많은 것들을 처리하고 생산팀에 압력을 가해 그들이 더 많은 생산량을 만들도록 원한다면 왜 PULL을 구현하기를 원할까?

 

만일 당신이 더 많이 산출하기를 원한다면 정확히 정반대로 해야 한다. PULL을 구현하는 일은 칸반에서 개선점을 찾는 출발점이다. 우리는 처리량 대비 요구량의 균형을 조절하고 어떤 것도 손대지 않고 시스템을 생산성이 최적인 상태로 둔다. 그리고 이를 통해 스트레스 감소, 과로 방지, 더 많은 생산성, 품질 개선 그리고 출시 일정 감소를 만드는 진화적인 개선을 시작한다.

 

하지만 WIP를 제약하면 더 적은 일을 처리할 것이다. 개발팀이 더 많은 일을 하도록 하기 위해서는 개발팀의 규모를 조정해야 한다.

 

위의 주장은 다음 몇 가지 이유로 틀렸다.

 

1. 모든 생산 시스템은 단일 제약 요인, 가장 약한 링크에 의존하는 최대 생산량을 가지고 있다. 만일 우리가 가장 약한 링크를 빼놓고 나머지를 개선해도 개선은 일어나지 않는다. 아마 실제로는 더 나빠질 것이다.

2. 시스템이 WIP로 인해 과적 상태가 되면 어디에 문제가 있는지 알 수 없다. 너무나 많은 것들이 진행 중이어서 중요한 활동 지점을 찾기가 어렵다. 이것은 마치 건초더미에서 바늘 찾기와 같다.

3. 더 많은 사람을 투입하면 그 시스템은 더 복잡해진다. 더 많은 사람을 투입해 더 많은 일을 하기 원한다면 조직과 기술을 재편해야 할 것이다.

4. 린 작업 방식의 접근법은 가치 사슬을 더 추가하는 것이 아니라 가치 사슬에 있는 낭비를 제거하는 일을 더 많이 하는 것이다.

 

나는 처리량과 요구량의 균형을 맞추고 싶지 않다. 내가 원하는 건 모든 요구량을 다 받아 줄 수 있도록 처리량을 늘리는 것이다. 나는 어떤 것이든 하고 싶다!

 

요구량과 처리량의 균형을 맞추는 것은 수단이자 목적이다. 이것이 칸반의 목적은 아니지만 생산성 향상, 적기 출시 그리고 민첩성을 달성하는 방법의 하나다. 아래에 어떻게 하면 제약 이론을 적용해 이것을 이뤄낼 수 있는지 설명한다.

더 많이 알고 싶다면 이 기고문을 찾아보라. David Anderson은 조직 단위에서 PULL을 구현하는 장점에 대해 우리에게 이야기해준다. (* 현재 링크 존재하지 않음)

 

사고체계 변화

 

칸반의 6가지 기본 원칙 중 하나는 "당신이 지금 하는 일부터 시작한다"는 것이며 이것은 훌륭한 원칙이다. 왜냐하면 우리는 우리가 가진 것을 받아들여 현재 상황에서 시작하기를 원하며 시작부터 아무것도 바꾸고 싶지 않기 때문이다. 하지만 이것은 전혀 그렇지 않다. 올바른 칸반의 적용은 커다란 저항이 발생하는 초반부터 거대한 정신적 변화가 필요하다. WIP 제약하기와 리소스 효율 문화에서 흐름 효율의 문화로 바뀌는 것은 큰 변화이다.

 

여기서 나의 제안은 아주 명확하다. 조직의 다른 중요한 변화와 비슷하게 C 레벨 임원과 경영진이 이런 변화에 동의하지 않고 암시하는 바를 이해하지 못하면 아무 일도 일어나지 않는다. 당신은 WIP 제약의 장점과 그 기대치를 적절하게 관리할 수 있어야 한다.

사람들이 하루 종일 내내 바쁘고 다중 작업을 하며 일을 아래로 밀어내는 데 익숙한 조직에서는 내가 상위에서 일을 끌어가고 한 번에 한 가지 일에 집중하며 다른 일을 시작하기 전에 모든 일을 끝내야 한다고 말하면 기겁하며 놀란다.

 

내 경험에 의하면 저항의 두 가지 원인은 다음과 같다.

  • 임원과 경영진 차원에서 큐 이론과 시스템 사고에 대한 이해가 부족하다. 그들은 더 많은 사람을 투입할수록 더 많은 일을 할 수 있다고 믿는다. 그럴듯해 보이지만 틀렸다.
  • 팀 차원에서 그것은 기본적으로 두려움이다. 그들이 광란의 꿀벌처럼 하루 종일 바쁘지 않으면 직업을 잃거나 여유가 생기는 것이나 거절하는 것에 대한 두려움이다.

 

따라서 당신은 다른 모든 변화처럼 이성적 수준과 감성적 수준 모두에서 이 문제를 해결해야 한다.

 

에이징 - 과도한 WIP를 증명하는 쉬운 방법

 

에이징은 작업 중인 과업이 소비하는 시간의 양을 측정하는 메트릭이다. 다시 말해 투입 시점에서 산출 시점까지 과업이 소비하는 시간이다. 그리고 우리는 에이징이 리드 타임보다 더 높다는 걸 나타내서 WIP가 과도하다는 점을 입증한다.

 

* 리드 타임: 제품의 주문에서 납품까지 소요 시간. 일반적으로는 하나의 시스템에 인풋이 들어간 뒤 처리를 거쳐 완성된 결과로 나오기까지 걸리는 시간을 의미. 소프트웨어 개발에서는 능 구현 요청이 개발팀에 들어가 기능 구현을 완료한 시점까지를 리드 타임으로 볼 수 있다. 프로젝트 단위에서는 과제가 진입한 뒤 구현을 거쳐 출시한 시점까지 리드 타임으로 볼 수 있다.

 

에이징이 리드 타임보다 훨씬 더 높다면 그 시스템에 너무나 많은 WIP가 존재한다는 명확한 신호이다. 즉 대기 중이거나 우선순위가 낮게 조정되는 작업이지만 여전히 자원, 사람들의 작업 시간 그리고 출고를 복잡하게 만드는 많은 작업이 시스템에 존재하는 상황이다.

 

스스로 자문해보라.

  • 처음에 그 작업이 왜 시스템에 들어갔을까?
  • 출고 완료의 기준은 무엇인가?
  • 이전 작업을 더 이상 하지 진행하지 않는 이유는 무엇인가?
  • 이전 작업을 완료하지 못하게 방해하는 것은 무엇인가?
  • 이런 작업 중 상태를 유지하고 지연시키는 이유는 무엇인가? 그것들을 취소할 수 있나? 그것들을 출고할 수 있나?
  • 몇 주 동안 그 자리에 계속 있는 많은 작업을 아직도 가지고 있는데 왜 또 추가해야 할까?
  • 당신이 전자적인 도구를 사용할 수 있다면 에이징 계산을 쉽게 할 수 있다. 당신의 에이징이 리드 타임보다 훨씬 더 높다면 문제가 있는 것이다!

 

균형이 잡힌 시스템에서 리드 타임의 85%와 에이징의 85%가 비슷해야 한다. 이것은 리틀의 법칙을 적용하기 위해 참이어야 하는 기본 가정 중 하나이다.

 

당신이 칸반 작업 방식에서 WIP 제한을 올바르게 하지 않는다면 아이템이 시스템 내부에서 생존하는 시간이 늘어나며 시스템은 균형이 깨져 예측 불가능하게 될 것이다. 당신은 어떤 것이 언제 시스템에 들어갔는지는 알지만 언제 나갈지는 알 수 없다.

 

제약 이론과 요구사항 관리

 

 

(이상 / 현실 / 전략의 도입)

1. 투입량을 줄인다. 2. 병목을 개선한다. 3. 투입량을 늘린다. 4. 다음 번에 수정한다.

 

이 이미지는 Henrik Kniberg의 원안을 가져와 수정한 것이다.

 

맨 처음 우리는 투입을 줄여서 시스템의 WIP를 제한한다. 이런 식으로 우리는 PULL을 구현해서 시스템의 최대 처리량을 현재 제약 수준으로 고정시켜 큐와 지연을 만들지 않게 운영한다.

그 시스템이 균형 상태로 동작하고 나면 일반적으로 병목이라 불리는 가장 큰 제약을 찾아 수정한다. 그리고 투입량을 증가시킨다. 이제 우리는 더 많은 처리량을 가지게 되었기 때문에 더 많은 아이디어를 시스템에 넣을 수 있다.

 

그 다음 우리는 새로운 제약을 찾아 계속 반복한다.

 

우리는 칸반 작업 방식에서 WIP를 제약해 시스템을 안정화하고 제약을 찾아 시스템을 개선할 수 있다. 과도한 WIP가 처리되는 프로세스에서는 문제를 찾아낼 수 없다. 따라서 당신은 결국 최적화할 필요가 없는 무언가를 최적화하게 될 것이다.

 

칸반 작업 방식에서 WIP를 제약하기 위한 제안

  • 당신이 이전에 매일 수백 가지 일을 하는 상황이었기 때문에 굳이 내리지 않아도 되는 결정을 내리도록 강요받는 고통스러운 지점까지 WIP를 줄인다. 누군가가 "오늘은 할 일이 없어"라고 말하기 전까지는 WIP 제약이 긍정적인 효과를 가져오지 않는다. 누군가가 "WIP가 꽉 차 있고 QA 담당자가 꽉 차서 어떤 것도 끌어갈 수 없기 때문에 모든 작업이 완료되었지만, 개발팀에 더는 할당할 수 없다"라고 말하기 전까지는 아직 아니다. WIP 제약이 작동하도록 하기 위해 당신이 바로 해야  가장 중요한 일이 무엇인지 궁금해하기 전까지는 아직 아니다.
  • 만일 Ready to Pull / Backlog / Commitment Point에 얼마나 제약을 가해야 할지 모른다면 아이템 보충 주기 당 시스템에서 나가는 아이템의 숫자와 동일하게 입력한다. 예를 들어 당신의 시스템이 주당 5개의 아이템을 산출한다면 당신의 보충 주기는 주간 단위로 Ready to Pull은 5로 제한한다.
  • 칸반 시스템을 설계한 뒤에는 WIP 제약을 초과하는 모든 아이템을 시스템 뒤로 밀어낸다. 당신 보드의 우측에서 시작해 WIP 제약을 초과하는 모든 아이템을 뒤로 밀기 시작하고 각 단계에서 뒤로 가면서 어떤 것을 남기고 어떤 것을 보낼지 결정한다. 이 방식은 시스템이 다시 채워질 때까지 기다리지 않고 칸반에서 이익을 취할 수 있는 가장 빠른 방법이다. 
  • 당신이 할 일이 없다고 놀라지 않는다. 그건 대부분의 경우 현실이 아니며 아마 당신이 너무 전문적이기 때문일 것이다. 당신은 다음과 같은 것을 통해 여유를 즐길 수 있다.
    • 배움
    • 상위 단계에서 일하기
    • 작업 공간 청소하기
    • 다른 팀원을 돕기
    • 고객과 이야기 하기
    • 다른 팀을 돕기

 

저자에 대하여

 

Gerard Chiva는 기업이 더 나은 제품을 만들고 경영진이 선도적인 제품 조직을 구축할 수 있게 지원한다. 그는 혁신, 디지털 제품 관리, 운영 성과를 위한 컨설팅 회사인 AKTIA 솔루션의 매니징 디렉터이다. Gerard는 제품과 혁신 코치로서 기업들과 협력한다.

 

EOD.

반응형

관련글 더보기

댓글 영역