Chap 08. 서비스 기획 업무 A~Z (3) 애자일 방법론 中 칸반

1. 칸반의 유래

• 일본어인 칸반은 한국어로 간판을 뜻하며, 도요타의 자동차 생산관리 시스템에서 사용된 칸반에서 유래함
• 생산 도중 추가로 부품이 필요할 때 이 카드를 작성하여 전 단계로 보내면 카드에 적혀진 만큼의 전 단계의 부품을 생산하였음
• 전 단계의 부품이 재고로 쌓이는 것을 막고 필요한 만큼의 부품을 적시에 만들기 위해 노력했는데 이를 JIT(Just In Time)이라고 함
• 전 단계의 작업을 계속 수행하여 다음 단계로 밀어 넘기는 (Push) 방식과 다르게 칸반에서는 특정단계의 작업이 완료되었을 때 전 단계의 작업 수행을 지시하여 끌어당기는 (Pull) 방식으로 진행하는 소프트웨어 개발 방법론을 도요타에서 전 단계에서 작업 지시를 할 때 사용했던 간판에서 차용하여 칸반 방법론이라고 명명하였음

---

2. 칸반 실천법

1)  시각화 

• 칸반 보드는 시작 지점과 끝 지점이 열로 나눠져 왼쪽부터 오른쪽으로 흘러가도록 구성되어 있음
• 카드는 작업단위, 카드가 속해있는 열은 해당 카드의 프로세스 단계를 나타냄
• 각 단계 사이에 진행 중 업무 WIP(Work In Progress) 제한이 표기되어 있어야 함
• 어떤 열에서 다음 열로 옮기기 전에 완료되어야 하는 일이 무엇인지 명확히 정책을 만들어두어야 함
• 하나의 열에서 다음 열로 옮길 때에는 정책이 명확하게 정해져 있어야 함
  • IN PROGRESS → IN REVIEW : 코드 작성 완료 시점? 깃헙에 PR을 올린 시점? 개발 완료 후 테크 리더에게 확인만 받은 시점?
• 툴 예시 : 지라, 아사나, 트렐로 등

---

2)  진행 중 업무를 제한 (WIP) 

• WIP 제한을 함으로써 ‘Push’가 아닌 ‘Pull’ 형으로 업무 방식이 변경됨
• 하나의 열에 WIP 제한 기준만큼의 카드가 있을 경우, 카드를 완료하여 다음 단계로 보내기 전까지 새로운 카드를 당겨올 수 없게 됨
• 이를 통해 부분적으로 완료한 업무가 많아져 발생하는 (젖은 빨래) 낭비를 줄이고 완성된 제품을 배포할 때까지의 리드타임을 줄여 더 자주 고객에게 배포하고 피드백을 얻을 수 있게 됨

---

3)  흐름을 관리 

• 업무 흐름이 완성된 가치 생산을 최대화하도록 지속적으로 관리함 (건조된 빨래)
• 완성 제품이 생산될 때까지의 리드 타임을 줄이고 가능하면 예측 가능해야 함
• 특정 업무가 전체 흐름을 막고 있을 경우(낮은 성능의 건조대), 해당 업무를 개선하여 흐름을 개선해야 함

---

4)  정책을 명시화 

• 칸반 방법론에서 정책을 명시화하여 모든 구성원이 동일한 방식으로 일하는 것이 중요함
• 다만 해당 정책은 토론을 통해 언제든지 변경될 수 있어야 지속적으로 개선되는 칸반 실천을 할 수 있게 됨
• WIP의 제한도 정책 중 하나이며 각 열의 완료의 정의 또한 정책 중 하나임
• 정책의 종류 : WIP 제한, 각 열마다 WIP 제안의 개수, 각 열의 완료에 대한 정의 등

---

5)  피드백 루프를 실행 

• 칸반 방법론에서 7가지 리뷰 : 전략, 운영, 위험, 서비스 제공, 재보충, 칸반, 제공 계획 리뷰를 진행함
  • 전략 리뷰 : 프로젝트 전략 관련하여 논의하는 회의 ⇒ 아무리 좋은 프로젝트를 좋은 프로세스로 개발한다고 하더라도 전략이 옳지 못하면 결코 성공할 수 없기 때문에 지속적으로 외부 상황, 내부 상황, 경쟁자 상황 등을 파악해서 우리가 옳은 프로덕트를 만들고 있는지 확인하고 옳은 프로덕트를 만들 수 있게 끔 전략 세워야 함 (분기별 진행 추천)
  • 위험 리뷰 : 칸반 시스템을 진행하면서 특정 워크 프로세스가 지속적으로 흐름을 막고 있다면 그 흐름을 막고 있는 이유가 무엇인지 파악하고 그것을 개선해 나가기 위해 진행하는 회의 (1달에 1번 추천)
  • 재보충 회의 : 어떤 신규 업무를 to do에 넣어서 칸반보드에서 작업을 진행할지를 팀원들과 함께 고민하여 넣어가는 회의 ⇒ 스크럼의 스프린트 플래닝 미팅과 거의 동일 (1주에 1번 추천)
  • 칸반 미팅 : 매일매일 완료된 업무와 함께 어떠한 열에서 병목 현상이 발견되는지 파악해서 팀이 서로 간에 문제점을 파악해서 서로 도움을 줄 수 있게끔 기회를 제공하는 회의 ⇒ 스크럼의 데일리 스크럼과 거의 동일한 리뷰
• 핵심은 주기적인 리뷰 세션(데일리, 위클리 등)을 통해서 칸반이 더 나은 방향으로 개선되기 위해서 다양한 사항들을 팀원들 모두가 꼼꼼히 살펴보고 수정하고 개선하는 것

---

6)  함께 개선하고 실험을 통해 발전 

• 칸반은 규범에 얽매이지 않고, 조직의 상황에 적응하며 발전함
• 칸반은 조직의 현상태에서 시작하여 지속적이고 점진적인 개선을 추구함
• 경험을 통해 조직에 맞는 최선을 찾는 것이 중요함

---

3. 칸반의 장점과 단점

< 장점 >

• 규범이 많지 않아, 조직에 도입하기 용이함
• 연속적인 흐름을 관리하기 때문에 스프린트와 같은 데드라인은 없으나, 속도에 대한 압박이 존재함
• 스프린트 플래닝 등으로 스크럼의 다양한 미팅으로 인한 시간 리소스 낭비를 막을 수 있음
• 병목 지점을 명확히 파악할 수 있어 개선에 용이함
• 스크럼에서 스프린트에 일을 마무리 해야 하기 때문에 발생하는 저품질 상태의 배포가 최소화 됨

< 단점 >

• 규범이 없어 Anomy 상태가 될 수 있음
• 스프린트 안에서 일을 완료해야 한다는 압박감이 없어 자발적 실천 문화가 약하거나, 프리라이더가 많을 경우에는 긴장감이 떨어지고 전체적인 생산성은 떨어 질 수 있음

---

4. 칸반의 스크럼과의 차이점

• 역할을 지정 하지 않음
  • 제품책임자 / 개발팀 / 스크럼 마스터 등의 역할이 따로 존재하지 않고 유연하게 진행 가능함
• 이터레이션(스프린트)가 진행되지 않음
  • 기간이 정해진 스프린트를 반복하는 스크럼과 달리, 칸반은 기간을 따로 고정하지 않음
  • 배포 가능한 기능이 완성될 때마다 배포하고, 새로운 기능 개발이 가능한 시점에서 끌어와 개발을 시작하는 방식으로 진행하여 맺고 끊음 없이 지속적으로 흐름이 유지됨
• WIP를 제한함
  • 스크럼은 스프린트 백로그의 양을 조정하며 팀의 제품 개발 속도를 측정하지만, 칸반은 이터레이션을 사용하지 않기 때문에 워크플로우상태에 WIP 를 지정하여 일의 속도를 조절 및 파악
• 스프린트 백로그 변경 가능 여부
  • 스크럼에서는 일단 스프린트가 시작되면 스프린트 백로그를 변경하지 않는 것이 원칙이지만 칸반은 언제든지 작업을 추가 및 수정할 수 있음
• 보드 초기화 여부
  • 스크럼에서는 매 스프린트마다 보드가 생성되고, 해당 스프린트에 진행할 사항들을 보드에 넣어두고, 그전에 끝내지 못한 사항들은 다시 백로그로 보내는 작업을 하지만, 칸반은 지속적으로 보드가 유지됨

---