Sprint를 활용한 대표적인 Agile 방법론, 스크럼(SCRUM)

    내 머리속에서 애자일(Agile)하면 제일 먼저 떠오르는 것은 바로 스크럼(Scrum)이다. 요즘에는 관심이 좀 식었지만 한 때 폭발적인 관심으로 애자일 = 스크럼이 될 정도였었다. 대기업에서는 특히 스크럼을 실행하는 곳이 많았는데 사이트를 가면 스크럼 기반으로 만들어진 팀부터 프로젝트 관리까지 스크럼 투성이었다.


    몇년전 당시 다니던 회사의 본부장님은 SW 품질쪽으로는 유명하신 분이라서, 애자일과 스크럼, 칸반에 관련된 문서를 잔뜩 뽑아서 나눠졌던 기억도 있다. 그만큼 SW 품질이나 관리를 하는 사람들에게는 도저히 못들어본 말일 것이다.


    우선 스크럼의 탄생은 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game" 에서 시작된다. 이 아이디를 기반으로 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions" 에서 스크럼을 처음 언급한다. 


    스크럼이라는 용어의 탄생은 럭비(미식축구)에서 나오는 용어로 스크럼은 한 팀의 선수들이 서로 팔을 건 상태에서 상대 팀을 앞으로 밀치는 대형을 말한다. 


    스크럼


    스크럼은 일단 사소한 반칙이 일어나면 그 주변으로 7~8명이 뭉쳐서 서로간의 힘겨루기를 하는 모양새를 보이는데 인원수도 그렇고 이 모습이 이 방법론과 닮아있어서 이 이름을 붙이는 것이라 생각한다. 


    현재는 애자일이라는 개념이 혁명처럼 퍼지는게 아니라 수많은 애자일들을 사이트에 맞게 변형(테일러링)해서 사용하는 곳이 많은데 오늘은 바로 대표적인 애자일 기법인 스크럼에 대해서 설명해보고자 한다.




    Sprint를 활용한 대표적인 Agile, 스크럼(Scrum)의 개요


    스크럼의 개념 및 정의

    • 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어(SW)를 산출하는 대표적인 애자일 방법론
    • Agile 방법론 중의 하나로 Product Backlog를 바탕으로 기술적으로 분할되고 재해석된 스프린트(Sprint)를 스크럼 팀으로 통해 구현해 나가는 개발 방법론
    • Product Backlog를 바탕으로 하여 기술적으로 재해석된 Sprint를 구현해 나가는 Agile 방법론


    스크럼의 특징

    • 프로젝트 관리 강조 : XP와 달리 진행 체계 수립, 역할, 정의에 중점
    • 포괄적 정의, 포용 : 기존의 개발방법론, 표준, 공학적 접근법의 포괄적 수용
    • 시간적 조정 설정 : 15분의 Daily Meeting, 30일 정도의 개발주기(Time Box)
    • 관리적 체계 : 전체 제품 요구사항 관리, 개발주기 내 요구사항, 업무 진행 가시화
    • 팀 중심적 : 5~9명으로 구성, 팀 내에서 역할 분담, 모든 팀원 구성원간 업무 교환
    위 스크럼의 설명처럼 스크럼은 관리적인 애자일 방법론이다. 그리고 롤을 명확히 하고, 미팅 시간까지 산정할 정도로 매뉴얼화 되어 있는 방법론이다. 

    스크럼은 기존의 폭포수 모델이나, 프로토타이핑같은 모델과 달리 모든 LifeCycle을 담지 않는다. 개발단계에서만 들어가고 유지보수, 폐기는 없다.

    스크럼은 5~9명으로 구성이 되어 있는데 피자를 한판 시켰을 때 적당히 나눠 먹을 수 있는 팀원이 가장 적절하다고 말하기도 한다. 팀원이 너무 많으면 관리하기 힘들고 너무 적으면 뭔가 구현하기 힘들기 때문인듯


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


    웃겨 보일 수 있지만, XP도 그렇고 스크럼도 이런 가치를 말한다. 하여간 매뉴얼화 되어 있으면 별의별걸 다 한다




    SCRUM의 프레임워크 및 프로세스

    SCRUM의 프레임워크

    스크럼은 최대 한달안에 Sprint Backlog를 처리하는 프로세스이다



    SCRUM의 구성요소

    Product Backlog
    - 시스템에서 해결해야 하거나, 시스템에 포함되어야 할 기능, 특성과 기술에 대한 모든 기술 나열 
    - 요구되는 제품의 요구사항의 우선순위를 나열

    Sprint Backlog
    - 해당 Sprint 기간에 수행되어야 하는 TASK 목록으로 Sprint 기간 동안 개발 가능한 기능의 목록을 Product  Backlog에서 선택

    Sprint
    - 통산 4~6주(30)일 정도의 Time box 성격을 가진 잘 정의된 반복 개발주기
    - 각 Sprint 단계 종료 시 새로운 기능이 추가되어 실행 가능 제품이 인도 되어야 함

    Daily Scrum
    - 매일 약 15분 정도의 짧은 회의
    - SCRUM Master는 진척 사항 검토, 정상적 종료를 방해하는 위험 및 작업 계획을 확인


    SCRUM의 프로세스 (설명 및 특징)


    Prepare Product Backlog

    - 실제로 구현되어야 하는 기능 목록을 나열

    - SRS(요구사항정의서)나 TRS(기술요구 사항정의서)로부터 목록 도출

    - 특징 : 추정리소스, 우선순위 등


    Release Planning

    - 해야 할 작업(일)에 대한 계획 수립

    - Milestone을 정하여 Release시가 마다 작동 가능한 Product Release

    - 특징 : 위험의 조기 발견


    Sprint Planning

    - Release Planning 이후 각 Release를 달성하기 위한 Sprint 계획 수립

    - 특징 : 20%버퍼 법칙 적용


    Sprint Tracking

    - 일일 미팅(Daily Scrum)을 수행하면서 계획에 따른 프로젝트 수행

    - 특징 : Daily Scrum, Burn down chart


    Ending Sprint

    - 정해진 기간 동안 Sprint가 종료되면, 정리 실시

    - 특징 : 계획된 일정, 예산 소진 시 까지


    Review Sprint

    - Sprint가 종료된 후에는 Sprint에서 구현된 산출물을 Review하는 단계

    - 구현된 코드, 산출물

    - 특징 : Test, Code Review


    Update Product Backlog

    - Review과정에서 나온 추가 요건이나 변경사항을 반영하여 Product Backlog update

    - 특징 : 우선순위 재조정, 요구사항 구체화


    Retrospective

    - Scrum팀에 운영중인 방법론 자체에 대한 Review, 문제 개선

    - 특징 : SWOT분석


    스크럼의 프로세스를 간단하게 요약하자면, 프로덕트 오너가 Product Backlog라는 요구사항들을 뽑아낸다. 이 프로덕트 백로그를 우선순위화해서 스크럼 팀에게 전달이 되면 이게 Sprint Backlog가 된다. 팀은 우선순위에 따라 하나하나 작업을 수행한다. 즉 스프린트 백로그는 하나의 작은 프로젝트라고 이해하면 된다. 
    작은 프로젝트 단위를 30일 정도에 처리하고, 이 과정에서 매일 오전에 15분 동안 서서 회의하며 프로젝트가 완료되면 리뷰와 회고를 통해서 자기반성, 자아성찰(?) 시간을 갖고 다시 새로운 스프린트를 수행한다.



    스크럼 구성원 및 산출물들

    스크럼 구성원

    Product Owner
    - 고객, 관리자, 팀원들과 협의를 통해 목표 설정
    - 요구사항 정의, Product Backlog 업데이트 수행
    - Product Backlog내의 Item 우선순위 정의
    - 요구사항이 적절하게 구현되었는지 검토하고 확인하는 역할 수행

    Scrum Team
    - Product Backlog에 따라 Sprint에서 구현하는 역할
    - 개발자, 디자이너, 설계자 등

    Scrum Master
    - 팀원을 코치하고 프로젝트의 문제 상황을 해결하는 역할
    - 프로젝트 관리자(PM)


    스크럼 산출물

    Product Backlog
    - 제품에 담고자 하는 기능의 우선순위를 정리한 목록
    - 제품 책임자가 우선순위 결정

    Sprint Backlog
    - 하나의 스프린트 동안 개발할 목록으로 사용자 스토리와  이를 완료하기 위한 작업을 태스크로 정의
    - 포스트잇 등에 테스크를 옮겨 적고, 벽면에 우선순위 별로 부착함
    - 스크럼 미팅통해 할일, 진행중, 완료 순으로 벽에 붙임
    - 소멸차트 이용 속도 확인

    Burn Down Chart (소멸 차트)
    - 개발을 완료하기까지 남은 작업량을 보여주는 그래프
    - 그래프의 하강 기울기를 통하여 스프린트의 속도를 조절


    스크럼 적용 현황 및 고려사항


    스크럼 적용 현황

    - 금융, 보험 등 보수적인 산업에 있는 기업과 Google, Yahoo, MS 등도 SCRUM을 선택

    - Agile 방법론을 실행하는 팀 중 약 50%가 Scrum을 사용하고, 20%가 Scrum을 XP 구성 요소와 함께 사용하고, 12%가 XP만을 사용

    - Kanban과 결합한 애자일 모델이 유행했으며, 최근에는 데브옵스(DevOps)로 전환하는 중


    https://dzone.com/articles/is-devops-agile



    SCRUM 적용 시 고려사항

    - 전체 프로젝트에 대한 큰 Mile Stone은 기존 개발방법론을 사용하고, SCRUM 방법론은 각 단계에 대한 Task를 위해서 사용

    - 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스가 중요



    참고문헌


    연관토픽



    댓글

    Designed by JB FACTORY