애자일에 관심이 있는 분들이라면, 한 번쯤은 '칸반(Kanban)'과 '스크럼(Scrum)'이라는 단어를 들어보셨을 텐데요. 익숙하지 않은 단어들이라 그 의미와 개념을 이해하기가 어려우실 수도 있을 거 같단 생각이 듭니다. 그래서 이번 포스팅에서는 내용을 간략히 정리하여 좀 더 쉽게 접근해 보고자 합니다.
A. 칸반(Kanban)
칸반은 간판(看板)의 일본식 발음으로 도요타 생산 방식(TPS-JIT)에서 유래하였으며, 아래와 같은 방법론과 특성을 가지고 칸반 보드를 통해 사용되고 있습니다.
*TPS-JIT : Toyota Production System - Just In Time(생산현장의 낭비를 제거한 적시 생산 시스템)
1) 칸반 방법론
- 프로세스의 연속적인 흐름을 유기적, 시각적으로 만들어 전체 프로세스를 유연하게 하는 방법론
- 제약 이론(TOC : Theory of constraints)의 당김 방식(Pulling system)에서 착안
- 칸반은 도요타의 카이젠(지속적 개선) 프로세스의 핵심
- WIP(Work In Process)을 통해 개발 프로세스에 병목현상이나 지나친 업무 쏠림을 방지
“오노가 발견한 린 시스템의 진정한 힘은
문제를 표면에 노출시키고 사람들을 생각하도록 만드는 것이었다.”
<출처 : The Toyota Way Fieldbook 도서의 내용 中>
2) 칸반 메소드
- 제조업에서 시작된 칸반을 IT에 적용
- 2004년 초 David J. Anderson이 MS에서 시도했던 가상 칸반 시스템이 소프트웨어 공학에서 사용한 최초의 칸반
- 2006~2008년 Corbis에서 칸반이 탄생, 이후 많은 린 소프트웨어 개발 커뮤니티에서 지속적으로 발전
- 칸반은 점진적 프로세스 개선 방법
3) 칸반의 핵심 특성
- 업무 흐름의 시각화
- 진행 중 업무 제한
- 흐름 측정 및 관리
- 명시적 프로세스 정책 수립
4) 칸반을 통한 지속적 개선(카이젠)
- 칸반을 사용하면 모든 이해관계자가 자신의 행동으로 인한 영향을 볼 수 있음
- 칸반이 제공하는 가시성을 통해 각 담당자들은 스스로 자신이 아무것도 하지 않았을 때 발생하는 영향을 깨달음
- 서로 다른 직무를 담당하는 직원들이 한 가지 문제에 대해 해결책을 찾으려고 협업하면, 업무 흐름이 유지되고 시스템 차원의 성과가 개선되며 팀 신뢰가 증가
- 관리자는 개개인을 감독하는 대신 프로세스 성과, 위험 관리, 직원 개발, 직원 만족도 개선과 같은 다른 일에 집중할 수 있음
카이젠 문화는 각 개인이 권한을 부여받았다고 느끼고, 두려움 없이 행동하며,
자발적으로 참여하고, 협업하며, 혁신하는 문화다
5) 칸반 보드 기본 형태
- 칸반 보드는 기본적으로 계획(To-Do), 진행 중(Doing), 완료(Done)의 형태를 사용
- 기본적인 형태는 아래와 같으나, 실제 업무의 프로세스에 따라 변경하여 사용 가능
6) 칸반 보드 설계 팁(Tip)
- 업무 흐름 시각화를 위해 칸반 보드를 만들기 전에 스케치하기
- 요구 사항을 기반으로 수용량을 할당
- 동시 활동 표시 #1 : 하나의 열을 두 개(또는 그 이상)의 영역으로 분할
- 동시 활동 표시 #2 : 한 열에 두 가지 활동을 혼합해서 사용
7) 칸반 보드 예시
☆ 보드를 제작하기 전에 가장 적합한 형태를 찾는 것이 중요 ☆
- SAFe 기반 애자일 PI/Iteration 보드
- 진행 중 열이 확장된 형태
- 의존성이 표현된 레인 보드
- 여러 팀이 있고, 칸반 보드 위에 의존성을 표시한 형태
- 비 계획성 업무를 표시한 형태
- 상충하는 우선순위를 표기한 형태
- PDCA(Plan-Do-Check-Act) 활용한 형태
- 반복적인 업무가 많은 팀에서 활용하기 좋은 형태
- 구매/주문 업무의 형태
8) 칸반 보드 운영 가이드
- 해야 할 일을 카드(포스트잇) 형태로 작성하여, 진행 상태에 맞게 옮겨가면서 팀 전체의 업무를 함께 확인
- WIP(Work In Process) 제한 설정 필요(업무 지연 및 방치를 사전에 방지)
※ 과다한 진행 중 업무와 계획에 없는 추가 업무는 프로젝트 지연의 주요 원인
- 업무 우선순위를 지정(우선순위 충돌 방지)
![[칸반 보드 사용 예시]](https://blog.kakaocdn.net/dn/kBH9i/btsKGSXwdKz/R8FtEkHKtKUKUK19cvtZK1/img.png)
![[칸반 보드 사용 예시]](https://blog.kakaocdn.net/dn/bAYnrn/btsKH59nNwF/3PFUaM9Ygi6vgdX41gEQE0/img.png)
![[칸반 보드 사용 예시]](https://blog.kakaocdn.net/dn/dgZZ4A/btsKIbO2upy/awgDZibh9PBbV03l1DiVH0/img.png)
![[칸반 보드 사용 예시]](https://blog.kakaocdn.net/dn/92c6v/btsKH9KyAsR/weE6IKADdyMutgzjLk3r80/img.png)
칸반을 간략히 정리하자면, 칸반은 보드 형태의 업무 시각화 도구이며 우리가 진행하는 모든 업무(프로세스)를 다 함께 공유하여 업무의 가시성을 확보하고 투명한 업무 처리를 할 수 있게 하는데 목적이 있습니다. 또한 문제가 발생하였을 때 신속한 해결을 통해 프로젝트 지연을 예방할 수 있게 합니다.
“시각적으로 볼 수 있고 그것을 함께 공유한다는 것”
B. 스크럼(Scrum)
스크럼은 프로젝트 관리를 위한 상호/점진적 개발 방법론으로 프로덕트 백로그, 스프린트 플래닝, 스프린트 백로그, 데일리 스크럼, 스프린트 리뷰, 프로덕트 릴리즈, 스프린트 회고의 과정을 일정한 주기로 반복하는 것을 의미하며, 주기가 완료될 때마다 고객에게 가치 있는 제품(소프트웨어)을 전달하는 방식입니다.
1) 스크럼 팀
스크럼의 기본 단위는 작은 규모의 팀입니다. 스크럼 팀은 한 명의 스크럼 마스터(Scrum Master), 한 명의 제품 책임자(Product Owner), 그리고 개발자들(Developers)로 구성됩니다. 스크럼 팀 내에는 하위 팀이나 계층이 없습니다. 이는 한 번에 하나의 목표 즉, 제품 목표(Product Goal)에 집중하는 응집력을 가진 전문가들의 모임입니다. ※ 여기서 말하는 개발자는 기획자, 개발자, 테스터 등 개발에 참여하는 모든 구성원을 의미
또한, 스크럼 팀은 다기능 팀(Cross-functional Team)으로, 그 구성원들이 매 스프린트마다 가치를 창출함에 필요한 모든 기술들을 보유하고 있습니다. 또한 누가 무엇을 언제 어떻게 수행할지를 내부에서 자율적(Self-managing)으로 결정합니다.
- 제품 책임자(Product Owner) : 복잡한 문제에 대한 일감을 제품 요구 목록 (Product Backlog)으로 정리하고 우선순위를 결정
- 스크럼 마스터(Scrum Master) : 제품 책임자와 스크럼 팀이 애자일 가치(Value)와 원칙(Principle)으로 성공적인 제품을 만들고, 조직 변화와 민첩한 작업 방식을 수립하고 유지할 수 있도록 촉진
- 개발팀(Development Team) : 선택된 일감을 스프린트(이터레이션) 기간 동안에 가치 있는 증가분(Increment)으로 변환
2) 스크럼의 3가지 기둥
- 투명성(Transparency): 프로세스와 작업의 결과를 받는 사람들만 아니라 작업을 수행하는 사람들에게 시각적 공유.
- 점검(Inspection): 바람직하지 않은 편차나 문제점들을 감지하기 위해, 스크럼의 산출물들과 합의된 목표를 과정을 꼼꼼히 점검
- 조정(Adaptation): 공정의 어떤 부분이 허용 한계를 벗어나거나 결과의 제품이 인수할 수준이 안 될 경우, 적용되는 공정 또는 작업의 산출물을 조정
3) 스크럼의 5가지 가치
- 확약(Commitment): 약속한 것을 확실히 실현하는 것
- 집중(Focus): 확약한 것의 실현에 전념하는 것
- 개방성(Openness): 어떤 것이 자신에게 불리해도 숨기지 않는 것
- 존중(Respect): 자신과 다른 사람에게 경의를 표하는 것
- 용기(Courage): 자신이 옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 통해 작업할 수 있는 용기
4)스크럼 절차
- 스프린트(Sprint): 점진적 개발을 위한 반복 주기로 1~4주 이내를 권장하고 있으며, 스프린트 계획(Sprint Planning), 일일 스크럼(Daily Scrums), 스프린트 리뷰(Sprint Review) 및 스프린트 회고(Sprint Retrospective)를 포함하여, 제품 목표(Product Goal)를 달성함에 필요한 모든 작업이 스프린트 동안 이루어집니다.
- 스프린트 계획(Sprint Planning): 스크럼 팀 전체의 공동 작업을 통해 스프린트 기간 동안 수행할 제품 백로그 및 스프린트 백로그 도출
- 일일 스크럼(Daily Scrums): 매일 정해진 시간에 팀원 모두가 모여 “어제 한 일, 오늘 할 일, 이슈 사항”을 공유를 통해 업무 진행 사항을 확인
- 스프린트 리뷰(Sprint Review): 스프린트 기간 동안 완료한 작업의 결과물을 이해관계자들에게 제공 또는 데모하여 진행 상황을 논의
- 스프린트 회고(Sprint Retrospective): 지난 스프린트가 어떻게 진행되었는지를 되돌아보며, 발생한 문제점들을 확인하고 근본 원인을 탐색합니다. 또한, 스프린트 동안 좋았던 점, 좋지 않았던 점, 개선할 내용 등을 논의합니다.
스크럼을 간략히 정리하자면, 스크럼은 점진적 개발을 위한 기간(1~4주)을 설정한 후 해당 기간 동안 스크럼 팀 모두가 스크럼 절차를 함께 수행하여 고객에게 가치 있는 증분(Increment) 된 제품을 인도하고, 스프린트를 반복 수행하여 최종적으로는 완성된 제품을 제공하는 것이다.
“요즘과 같이 경쟁이 심한 상황에서는 ‘Relay Race(계주 경기)’와 같은 워터폴 방식보다는 팀 전체가 하나 되어 공을 주고받으며 밀고 나가는 ‘Rugby(럭비)’와 같은 방식이 더 잘 부합할 수 있습니다.”
<출처 : Hirotaka Takeuchi and lkujiro Nonaka, "The New New Product Development Game, "
Harvard Business Review , January 1986 >
C. 칸반(Kanban)과 스크럼(Scrum)
1) 칸반과 스크럼의 연관성
칸반과 스크럼은 모두 프로세스 도구
· 프로세스(Process): 일하는 방법
· 도구(Tool): 작업이나 목적을 달성하기 위해 사용하는 모든 것
- 스크럼은 칸반 보다 규범적이다.
· 스크럼: 프로덕트 백로그, 스프린트 플래닝, 스프린트 백로그, 데일리 스크럼, 스프린트 리뷰, 프로덕트 릴리즈, 스프린트 회고
· 칸반: 작업 흐름 시각화, WIP 개수 제한, 리드타임 측정 및 프로세스 최적화
2) 칸반과 스크럼의 차이점
- 스크럼은 역할을 규정하지만 칸반은 역할을 정의하지 않음
- 스크럼은 기간이 고정된 스프린트를 규정
- 칸반은 워크플로우 상태 별로 WIP를 제한
- 스크럼은 스프린트 내에 변경을 허용하지 않음
- 스크럼 보드는 매 스프린트마다 초기화된다.
- 스크럼은 교차 기능 팀을 규정하지만, 칸반은 선택적 사용.
- 스크럼의 스프린트 백로그는 한 스프린트에 맞아야 하지만, 칸반에서는 특정 기간에 맞도록 아이템이 충분히 작아야 한다는 명시적인 규칙이 없음
- 스크럼은 추정과 속도를 규정하지만, 칸반은 추정을 규정하고 있지 않음
- 스크럼은 번 다운 차트를 규정
- 스크럼은 데일리 스크럼(DSU)을 규정
3) 칸반과 스크럼의 공통점
- 둘 다 여러 제품의 동시 개발을 허용
- 경험을 통해 알 수 있음
· 누구를 스크럼 팀에 배치할 것인가?
· 한 스프린트에서 해야 할 일을 얼마나 가져가야 하는가?
· 칸반에서 WIP을 얼마로 제한해야 하는가?
· 린(Lean)과 애자일(Agile) 특성을 지님
· 당김 방식(Pull System)
· 카이젠 문화(지속적 개선)
· 계획을 따르기보다 변화에 대응
· 출시 가능한 소프트웨어를 자주, 빠르게 출하하는데 집중
· 지속적인 최적화
마지막으로, 애자일(Agile)과 워터폴(Waterfall)은 각자의 장단점이 있는 개발 방식입니다. 애자일은 좋고 워터폴은 좋지 않다는 생각보단, 어떤 것이 우리의 업무에 적절한 것이고 적용 가능한 것인지를 판단해 보시고 선택하는 것이 중요할 것 같습니다.
[PMP] 프로젝트 방법론 - Watefall(워터폴)/Agile(애자일) 정의,차이,장단점 및 하이브리드 사용
[PMP] 프로젝트 방법론 - Watefall(워터폴)/Agile(애자일) 정의,차이,장단점 및 하이브리드 사용
애자일(Agile) 방법론은 오늘날 많은 기업에서 사용하고 있는 방법론입니다. 2023년 현재 대부분의 IT 조직 개발 환경은 애자일 방법론의 영향을 받았고, 실천하고 있다고 해도 과언이 아닌데요. 애
infoofit.tistory.com
[금융보안] 금융권 APT 공격과 대응 방안 - 보이스피싱과 가상화폐를 이용한 자금 세탁 과정, 가짜 앱 피싱, BEC 공격, 랜섬웨어, 딥페이크, 핵티비즘, 스턱스넷
[금융보안] 금융권 APT 공격과 대응 방안 - 보이스피싱과 가상화폐를 이용한 자금 세탁 과정, 가짜
A. 금융권 APT 공격 사례1. 지능화된 보안 위협 동향1-1. 보이스피싱과 가상화를 이용한 세탁과정먼저 보이스피싱을 통해 갈취한 피해금을 가상화폐를 통해서 자금 세탁 하는 과정입니다. 법원이
infoofit.tistory.com
[용어/개념] 프로세스(Process) vs 쓰레드(Thread) 비교 정리
[용어/개념] 프로세스(Process) vs 쓰레드(Thread) 비교 정리
프로세스(Process)- 레지스터(register), 스택(stack), 포인트(point), 프로그램, 데이터 등의 집합체로 실행 중인 프로그램 비 동기적 행위, 프로시저(procedure)가 활동 중인 것, 실행 중인 프로시저의 제어
infoofit.tistory.com