Scrum 과 Kanban

달피·2021년 5월 5일
5
post-thumbnail

스크럼에 대한 설명 및 칸반과의 차이점 정리


스크럼이란 무엇인가?


(미식축구의 포지션 이름에서 유래되었다)

스크럼(Scrum)은 프로젝트관리를 위한 상호, 점진적 개발 방법론이며, 애자일(Agile) 소프트웨어 공학 중의 하나입니다. 스크럼은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다. - 위키백과

agile
1.날렵한, 민첩한
2.(생각이) 재빠른, 기민한

스크럼은 프로세스 도구 중 하나로, 역할을 규정하며, 기간이 고정된 이터레이션을 규정하여 경험적으로 프로젝트를 관리해 나가는 방법이다.

(누구나 한 번쯤 봤을법한 스크럼 보드)


스크럼은 왜 하는가?

  • 계획한 대로 일이 진행되지 않음 : 스프린트 마다 계획과 프로세스를 수정하며 개선
  • 요구사항이 수시로 바뀜 : 스프린트 백로그/제품 시연을 통해 백로그를 관리하고 한 회의 스프린트동안에는 백로그 추가를 허용하지 않음
  • 자신의 능력으로 할 수 없는 일들에 막혀 있음 : 계획 회의/일일 미팅/회고 회의를 통해 팀원들간의 협력을 도모

스크럼을 구성하는 인원들은 어떻게 이루어져 있는가?

  1. Product Owner : 제품 책임자(프로젝트리더, PL 등이 될 수 있음)로서 제품 백 로그를 정의하여 우선순위를 정하는 역할이다.
  2. Scrum Master : 스크럼 관리자 및 코치로서 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자가 독단적으로 목표를 결정하지 않게 고객과 관리자 및 팀원들이 모여서 목표를 정하도록 하는 역할이다.
  3. Development Team : 개발팀은 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가도록 하는 역할이다. 물론, 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관 없이 팀원 자율로 진행된다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고 받게 되고, 끈끈한 협업체계를 가지게 된다.

스크럼은 어떻게 하는가?

스크럼 프레임워크


1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
7. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.


스프린트(Sprint)

sprint
1.(짧은 거리를) 전력 질주하다
2.(달리기수영 등의) 단거리 경기
3.전력 질주

스크럼에서 스프린트란 반복적인 개발 주기 를 뜻한다.
한 스프린트 내에서는 의미있는 산출물이 나오기 위한 목표를 설정한다.
정해진 목표는 그 누구도 팀원들의 동이 없이 바꿀 수 없다.

스프린트를 이루는 요소

1. 스프린트 계획 회의 (Sprint Planning Meeting) : 스프린트가 끝나고 다음 스프린트의 시작 전

  • 스프린트 목표와 스프린트 백로그를 계획하는 회의
  • 세부적으로 어떤 것을 구현해야 하는지에 대한 세부 작업 항목, 작업자, 예상 작업 시간 등을 수립한다.

2. 일일 스크럼 회의(Daily Scrum Meeting) - 매일 정해진 시간에, 일반적으로 15분


(일반적인 일일 스크럼과 미팅 시간을 획기적으로 줄여주는 일일 스크럼 방법)

  • 매일 정해진 시간에 일어서서 한다.
  • 모든 팀원이 참석한다.
  • 스프린트 현황판에 대한 업데이트를 진행한다.
  • 한 사람씩 어제 한 일과 오늘 할 일을 이야기하며 어려운 점이 있다면 이야기한다.
  • 되도록 짧게 (일반적으로 15분) 한다.

3. 스프린트 검토 회의 (Sprint Review) - 매 회 스프린트 종료 전

  • 고객이 요구했던 사항에 얼마나 부합하는지 참석자(고객포함)들 앞에서 시연한다.
  • 개선할 점 등에 관해 피드백을 받는다

4. 스프린트 회고 회의 (Sprint Retrospective) - 매 회 스프린트 종료 후 다음 스프린트 계획 회의 전

  • 그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아 보고, 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 검토한다.
  • 단점보다는 강점을 찾아 극대화 시키는데 주안점을 둠
  • 문제점을 확인하고 기록하는 정도로만 진행함.(문제점의 해결 방안을 찾는 회의가 아님)

칸반(Kanban) 이란?

일본어로 간판 이란 뜻이 어원으로 눈에 보이는 기록을 통해 제품을 개발하는 방법을 말한다.
많이 알려진 Scrum에 비해 Kanban은 조금 더 규범적이지 않은(rule이 적은) 개발 방법론이라고 할 수 있다.


칸반과 스크럼의 차이점

차이점 중 대표적인 몇 가지를 정리하면 이렇다.

  1. 역할을 지정하지 않는다.
    스크럼은 일반적으로 제품책임자/개발팀/스크럼 마스터 로 나뉘는데 반해 칸반은 이를 자유롭게 지정할 수 있다. (물론 스크럼도 유연하게 변경 가능하다)

  2. 기간이 고정된 이터레이션을 사용하지 않는다.
    스크럼은 스프린트를 통하여 계획/개선/릴리즈 와 같은 단계를 밟아가며 경험적으로 개선해 나가지만, 칸반의 경우에는 이를 고정하지 않는다. 필요하면 스프린트의 이터레이션을 사용해도 좋고, 필요할 때마다 릴리즈하도록 지정할 수 있다.

  3. 워크플로우 상태에 기반하여 WIP(work in process)를 제한한다.
    앞서 말했듯이 스프린트는 경험에 기반하여 매 스프린트마다 계획하는 일의 양을 조정하며 속도를 측정하지만, 칸반은 이터레이션을 사용하지 않기 때문에 워크플로우 상태에 WIP제한을 지정하여 일의 속도를 조절 및 파악한다. (보드 그림의 상태 이름 아래에 있는 숫자가 WIP를 의미하며 이를 넘는 아이템이 상태로 옮겨질 수 없다는 것을 의미한다)

  4. 이터레이션 내에서 변경이 가능하다.
    스크럼은 변경이 발생할 경우 현재 스프린트의 아이템을 변경하지 않고 다음 스프린트 계획에 포함시키는 것에 비해 칸반은 백로그에 언제든지 아이템을 추가할 수 있다. 다만 이를 다음 상태로 전환할 때 앞서 말했던 WIP제한을 통해 상태별로 할 수 있는 아이템을 제한시켜 우선순위별로 처리될 수 있도록 할 것이다.

  5. 보드는 초기화되지 않는다.
    스크럼은 스프린트마다 새롭게 보드를 구성하며 시작 시에 할일에 대부분, 끝날 때 완료에 대부분 아이템이 위치하는 반면 칸반은 그럴 필요가 없다. 따라서 칸반은 항상 할일/진행 중/완료 에 자유롭게 아이템이 위치하고 있다.


칸반과 스크럼 중 어떤 것을 사용해야 하나?

깊게 들어가면 더 많은 차이점이 있지만 결국 칸반과 스크럼 둘 다 경험적으로 일을 개선하며 릴리즈한다는데 같은 목표가 있다. 음식을 먹을 때 포크와 젓가락 중 무엇을 고르냐는 음식의 종류에 따라 적절한 것을 고르는 것과 같이 제품이나 서비스의 성격에 맞추어 선택하여야 한다. 결국 둘 다 일을 할 때 쓰이는 도구이기 때문에 더 효율적인 도구를 찾아 그 도구를 손에 맞게 변형하여 사용한다고 생각하면 쉬울 것이다.

개인적으로는 개발 초기에는 스크럼을, 테스트나 유지보수 기간일때는 칸반을 주로 사용하면 적절할 것 같다.


profile
개발 오답노트

0개의 댓글