본문 바로가기
기타

Agile(애자일) 그리고 Scrum(스크럼)

by Su1993 2020. 8. 17.
반응형

Agile 단어의 뜻은 다음과 같다.
1. 날렵한, 민첩한 (=nimble) 2. (생각이) 재빠른, 기민한

 

Agile은 쉽게 이해한다면 '유연하게 일하는 방식'이라 할 수 있다.

Agile은 '연속적인 고객의 요구사항 변경'에 실패하는 프로젝트가 빈번하게 생기지 않도록 하기 위해 해결하고자 소프트웨어 세계의 거장들이 모여 선언문을 작성하게 되었다. 이것이 바로 애자일의 탄생 배경이 된 '애자일 소프트웨어 개발 선언'이다.

 

 

출처: http://agilemanifesto.org/iso/ko/manifesto.html

 

요구분석 → 설계 → 디자인 → 코딩 → 개발 순으로 순차적으로 이어지는 흐름인 워터폴 모델(Waterfal Model)의 반대로 Agile은 짧은 주기로 고객이 사용할 수 있는 소프트웨어를 만들어가면서 커뮤니케이션의 비용을 최소화하고 이슈 사항들을 바로바로 제거하면서 개발하는 방식이라 볼 수 있다.

그리고 Agile의 개념들을 잘 실천할 수 있도록 만들어 놓은 도구들이 스크럼(Scrum), 칸반(Kanban), XP(eXtream Programming), Lean Software Development 등이 있다. 이 중 가장 흔히 사용하는 도구가 스크럼(Scrum)이다.

※ 스크럼(Scrum), 칸반(Kanban), XP(eXtream Programming), Lean Software Development 등은 애자일이라는 용어가 나오기 전에 이미 존재했다. 다만, 애자일 선언문이 발표되면서 자연스럽게 애자일 범주안에 들어온 것.

 

스크럼(Scrum)은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세서 프레임 워크이다. 스크럼 단어는 럭비에서 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 가리킨다.

※ 스크럼(Scrum)은 노나카 이쿠지로와 타케우치 히로타카에 의해 처음 등장했지만, 서덜랜드와 슈와버가 영감을 받아 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다.

 

출처: https://agileforall.com/resources/introduction-to-agile/

 

스크럼의 특성은 다음과 같다.

 

  • 솔루션에 포함할 기능/개선점에 대한 우선순위를 부여한다.
  • 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공해라.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
  • 날마다 15분 정도 회의를 가져라.
  • 항상 팀 단위로 생각하라.
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

 

스크럼이 추구하는 가치는 5가지이다.

 

  • 확약: 약속한 것을 실현하는 것.
  • 전념: 확약한 것의 실현에 전념하는 것.
  • 정직: 어떤 것이 자신에게 불리해도 숨기지 않는 것.
  • 존중: 자신과 다른 사람에게 경의를 표하는 것.
  • 용기: 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 통해 작업할 수 있는 용기.

 

스크럼의 역할들

 

Product Owner(PO)
비즈니스 목표를 충족시키는 제품을 만들기 위해 제품에 대한 요구사항 백로그(Backlog)를 작성하는 역할.

고객 및 조직 가치에 기반하여 제품 백로그 항목들의 우선순위를 결정하고, 매 스프린트의 결과를 검토하여 우선순위를 지속적으로 조정, 관리한다.

 

Scrum Master
쉽게 이해하면 프로젝트 관리자(코치) 역할.
스크럼 팀의 스크럼이 잘 수행될 수 있도록 도와주는 역할이다. 애자일 프로세서는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여기고 있다. 하지만, 이러한 부분과 더불어 애자일 프로세스는 무질서해 보이기 때문에 마찰이 생기기도 하는데, 이러한 부분들을 스크럼 마스터는 최대한 객관적인 시각에서 스크럼에 정해진 원칙들이 팀에 잘 적용될 수 있도록 도와주고, 문제가 생겼을 때 해결하는 역할을 한다. 즉, 투명하게 의사결정을 할 수 있게 가이드하는 역할을 한다.

 

Scrum Team 
프로젝트 수행에 필요한 모든 역량을 갖춘 팀으로 이를 위해 관련된 모든 부서로부터 팀원이 구성되며, 팀원은 자신의 전문 영역(디자이너, 테스터 등)에 고정되지 않고 다 같이 팀 과제를 수행한다.
작업을 정하고 할당하는 데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다.(자율적인 행위, 끈끈한 협업체계)

 

스크림의 주요 용어

 

제품 백로그(Product Backlog)
개발할 제품에 대한 요구 사항 목록.
제품 완성에 필요한 특성, 기능, 개선점 등 제품의 모든 요구사항을 우선순위에 따라 나열한 목록이다.

 

스프린트(Sprint)
반복적인 개발 주기.
프로젝트가 진행되는 주기를 말하며, 계획, 개발, 리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위 선택.

 

스프린트 계획 회의(Sprint Planning Meeting)
스프린트 목표와 스프린트 백로그를 계획하는 회의.
매번 스프린트가 시작될 때 수행하며, 기간에 따라 소요되는 시간이 유동적일 수 있다.(4주 스프린트 기준 8시간 정도 수행)

 

스프린트 백로그(Sprint Backlog)
각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록.
1개 스프린트에서 개발할 백로그들을 스프린트 백로그라고 한다.(하나의 스프린트 동안 완료할 과제들의 목록)
스프린트 계획 회의를 통해 나온 백로그의 집합이 바로 스프린트 백로그이다.

 

일일 스크럼 회의(Daily Scrum Meeting)
날마다 진행되는 미팅(어제 한일, 오늘 할 일, 장애 현상 등을 공유)(매일 15분 정도 수행).
수평적 공유 차원으로 진행. 관리자와 PO참석은 옵션.
만약 관리자와 PO 참석 시, 이 또한 수평을 유지해야 한다.

 

실행 가능한 제품(Shippable Product) 개발
스프린트의 결과로써 나오는 실행 가능한 제품.
- 잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP) : 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품.

 

스프린트 리뷰(Sprint Review)
스프린트가 종료하는 시점에 팀원 전체가 모여 각자 한 일을 리뷰.

 

스프린트 회고(Sprint Retrospective)
스프린트 기간 동안에 팀 내부에서 발생한 여러 가지 일들을 되돌아보고 잘한 것, 아쉬웠던 것, 개선할 것, 새로 시작할 것들을 도출해내는 과정.

 

소멸 차트(Burn-down Chart)

 

출처: https://www.visual-paradigm.com/scrum/scrum-burndown-chart/

스크럼에서 작업 현황을 추적하기 위해 일반적으로 사용하는 차트가 바로 소멸 차트(Burn-down Chart)이다. 소멸 차트를 사용하면 스프린트 수행 시 초기에 세운 계획이 잘 흘러가고 있는지 쉽게 확인할 수 있다. 빨간 선이 처음에 계획했던 스프린트의 스토리 포인트들의 합이 이상적으로 줄어드는 것을 말한다. 파란선은 빨간 선보다 아래쪽에 있다면 계획보다 빠르게 진행되고 있음을 나타내는 것이고, 위에 있다면 계획보다 늦음을 나타내는 것이다. 여기서 주의할 것은 그래프를 보고 계획보다 일처리가 늦어진다 하여 비난을 하기 위한 척도로 사용되서는 절대 안 된다.

 

 

증분(increment)
매 스프린트에서 팀이 개발한 제품 기능으로 잠재적으로 출시가 가능하거나 제품 책임자의 이해관계자들에게 효용을 가짐

 

스크럼의 진행 순서

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

'기타' 카테고리의 다른 글

유닉스(Unix)와 리눅스(Linux)  (0) 2020.09.23
컴파일러(Compiler)와 인터프리터(Interpreter)  (0) 2020.09.22

댓글