최근 바뀜 사이트맵

사이트 도구

스크럼_scrum

스크럼 (애자일 소프트웨어 개발)

정의

스크럼(scrum)은 반복적(iterative)이고 점진적인(incremental) 애자일 소프트웨어 개발 프레임웍이며, 애자일 소프트웨어 개발의 한 종류이다. 팀 공통의 목적을 위해 팀 전체가 하나가 되어 움직이는 유연하고 전체적인 개발 방법이다. 스프린트(Sprint)라는 주기를 일정시간(예를 들어 30일)으로 잡아 반복하며 주기가 끝날때 마다 직접 실행(혹은 출시; shippable) 가능한 프로그램을 제공한다.

역할

제품 책임자(Product Owner)

제품 책임자는 제품의 이해당사자, 고객의 목소리를 대변한다. 그리고 팀이 사업에 가치를 줄 수 있도록 보장할 책임이 있다. 프로젝트 책임자는 고객 중심의 아이템(일반적으로 사용자 이야기-user stories)을 작성하고, 중요성과 의존성에 기반해서 우선 순위를 부여한다. 스크럼 팀은 단 한 명의 제품 책임자를 두어야 한다. 제품 책임자는 스크럼 마스터와 역할이 묶여서는 안된다. 제품 책임자는 제품 개발의 사업적 측면에 추점을 맞추어야 하고, 이해 당사자와 협력하는 데에 대부분의 시간을 투자해야 한다. 그리고 팀이 어떻게 기술적인 해결 방법에 도달하는지에 대해서 간섭하지 않아야 한다. 이 역할은 익스트림 개발(XP; eXtreme Programming) 같은 애자일 프레임웍에서 고객 대리인에 상응한다.

커뮤니케이션은 제품 책임자의 가장 핵심적인 책임이다. 우선순위를 전달하고, 팀 멤버와 이해 당사자들과 공감하는 능력은 제품 개발을 옳은 방향으로 끌고가는 데에 중요하다. 제품 책임자는 팀과 이해 당사자 사이의 커뮤니케이션 격차에 다리가 된다. 제품 책임자는 이해 당사자들을 위한 팀 대리인, 이해 당사자 커뮤니티의 총괄적인 팀 대표로서 일한다.

이해 당사자에게 팀의 얼굴로서 프로젝트 책임자는 이해 당사자들과 다음과 같은 커뮤니케이션을 하게 된다.

  • 스프린트 리뷰에 참여하지 않은 주요 이해 당사자에게 솔루션 데모를 시연한다.
  • 배포를 정의하고 고지한다.
  • 팀 상태를 소통한다.
  • 마일스톤 리뷰를 조직한다.
  • 개발 절차에서 이해 당사자를 교육한다.
  • 우선 순위, 범위, 자금 조달, 일정을 협의한다.
  • 제품 백로그를 가시적이고 투명하고 분명하게 보장한다.

공감은 제품 책임자의 중요한 속성이다. 제품 책임자는 배경과 역할, 목표가 각각 다른 여러 이해 당사자들과 소통한다. 제품 책임자는 이렇게 각각 다른 관점으로부터 볼 수 있어야 한다. 청중의 욕구를 세부적인 수준에서 파악하는 것이 현명하다. 제품 책임자가 효과적으로 소통하는 능력은 이해 당사자의 요구를 정의하고, 이해 당사자 관심사 사이에서 우선 순위를 협의하고, 요구 사항의 적용을 효과적으로 보장하기 위해 개발자들과 협업하는 기술을 갖춤으로써 증진될 수 있다.

개발 팀(Development Team)

개발 팀은 각 스프린트가 종료될 때마다 실행 가능한 제품(PSIs; potentially shippable increments)을 책임진다.(스프린트의 목표) 팀은 각자 분석, 디자인, 개발, 검수, 기술 소통, 문서 등의 실질적인 업무를 맡는 3~9명으로 이루어진다. 개발 팀은 제품 증분(Product Increment)을 만들어 내는 데에 팀으로서 필요한 모든 기술을 자체적으로 충족(cross-functional)한다. 스크럼의 개발 팀은 프로젝트 운영 조직(PMOs; project management office)과 상호 작용이 있다 하더라도 자체적으로 구성된다.

스크럼 마스터(Scrum Master)

스크럼 마스터는 제품 목표 달성과 제품 인도에 이르기까지 팀의 능력에 장애물이 되는 요소를 제거한다. 스크럼 마스터는 전통적인 의미의 팀 리드나 프로젝트 매니저와는 다르지만, 팀과 혼란스러운 외부 환경 사이에서 완충제 역할을 한다.스크럼 마스터는 팀이 스크럼 프레임웍에서 합의된 절차를 따르도록 하고, 주요 세션을 용이하게 하며, 팀이 개선되도록 격려하여, 결과적으로 팀이 스크럼 프레임웍을 따르도록 한다.

  • 제품 책임자가 제품 백 로그를 보편적인 방식으로 유지하도록 하여 팀이 지속적으로 진행할 수 있도록 지원
  • 주요 이해 관계자의 의견을 바탕으로 팀이 제품에 대한 완료 정의를 결정하도록 지원
  • 제품에 고품질 기능을 제공하기 위해 스크럼 원칙 내에서 팀을 지도
  • 팀 내에서 자체 조직을 촉진
  • 스크럼 팀이 내외부 진행상의 장애물을 피하거나 제거하도록 지원
  • 정기적인 진행을 위한 팀 이벤트 촉진
  • 스크럼 원칙에 관한 주요 이해 관계자 교육
  • 자기 조직화(self-organization) 및 다기능 수행(cross-functionaity) 측면에서 개발 팀을 지도

프로젝트 매니저는 인력을 관리하는 책임을 가지지만 스크럼 마스터는 그렇지 않다는 점에서 뚜렷이 다르다. 스크럼에서 전통적인 의미의 명령이나 지시는 어려움을 초래하기 때문에 보통 프로젝트 매니저의 역할을 공식적으로 인정하지 않는다.

진행

스크럼의 기본 개발 단위는 스프린트(sprint), 혹은 반복(iteration)이다. 스프린트의 기간은 미리 정해져있으며 보통 1~4주, 일반적으로는 2주이다.

각 스프린트는 스프린트 백 로그 정의, 작업 식별, 목표 추청을 위한 스프린트 계획(sprint plannig)으로 시작한다. 각 스프린트는 스프린트 리뷰(Sprint Review)와 스프린트 회고(Sprint Retrospective)로 끝나며, 이해 당사자들에게 진행 상황을 보여주고, 다음 스프린트를위한 교훈과 개선 사항을 확인한다.

스프린트 계획(Plannig)

스프린트를 시작하는 시점에서 팀은 스프린트 계획 이벤트를 개최한다.

  • 스프린트 기간 동안 수행 할 작업 범위에 대해 알림
  • 스프린트 기간 동안 완료할 수 있는 백로그 아이템을 선택
  • 선택한 제품 백로그 아이템을 완수하는 데에 필요한 작업을 상세히 열거하는 스프린트 백로그 준비
  • 2주 동안의 스프린트 기간에 4시간으로 제한 (다른 스프린트 기간의 비례)
  • 첫 2시간은 전체 스크럼 팀(제품 책임자, 스크럼 마스터, 개발 팀)이 모두 모여 해당 스프린트에서 달성할 수 있는 제품 백로그 항목을 선택
  • 뒤 2시간 동안, 개발 팀은 제품 백로그 항목을 내놓는 데에 필요한 작업 항목을 분해하고, 스프린트 백로그를 확정한다.
    • 확인된 작업이 해당 스프린트 내에서 달성 가능하지 않는다면 일부 제품 백로그는 쪼개지거나 우선 순위에서 밀릴 수 있다.

개발 팀이 스프린트 백로그를 준비하면 스프린트 내에서 작업을 제공하기 위해 (보통 투표로) 의사를 결정한다.

일일 스크럼(Daily Scrum)

스프린트 기간 동안 매일 일일 스크럼(혹은 스탠드-업)을 개최한다.

  • 개발 팀의 모든 멤버가 다음과 같이 준비한다.
  • 일부 멤버가 없어도 정해진 시간에 시작한다.
  • 매일 같은 시간, 같은 장소에서 가진다.
  • 15분 안에 마친다.
  • 일반적으로 스크럼 팀 역학만 기여하지만, 누구든 환영한다.
  • 일일 스크럼 중에는 각각의 팀 멤버는 3가지 질문에 답한다.
  • 개발 팀이 스프린트 목표를 달성하기 위해 나는 어제 무엇을 하였는가?
  • 개발 팀이 스프린트 목표를 달성하기 위해 나는 오늘 무엇을 할 것인가?
  • 개발 팀이나 내가 스프린트 골을 달성하는 것을 방해하는 장애물이 있는가?

일일 스크럼에서 확인된 (장애물, 위험, 이슈, 지연 의존과 같은) 장애물은 스크럼 마스터가 수집해서 팀의 스크럼 보드나 공유된 ROAM(resolved, owned, accepted, mitigated) 보드에 표시하고, 해결을 맡기로 한 사람도 함께 표기한다. 일일 스크럼 동안 상세한 토론은 없도록 한다.

리뷰와 회고(Review and retrospective)

스프린트의 마지막에는 스프린트 리뷰스프린트 회고 2가지를 개최한다. 스프린트 리뷰에서 팀은

  • 완료된 것과 완료되지 않은 작업을 리뷰한다.
  • 이해 당사자들에게 완료된 작업을 시연한다. (a.k.a. 데모)

스프린트 리뷰의 가이드 라인

  • 완료되지 않은 작업은 시연되지 않아야 한다.
  • 2주 스프린트에 2시간 정도가 적당하다. (스프린트 기간에 비례)

스프린트 회고에서 팀은

  • 지난 스프린트를 반영한다.
  • 지속적인 프로세스 개선 행동을 확인하고 동의한다.

스프린트 회고의 가이드라인

  • 2가지 중요한 질문: 스프린트에서 잘된 것은 무엇인가? 다음 스프린트에서 개선될 수 있는 것은 무엇인가?
  • 2주 스프린트에 1.5시간 정도가 적당하다. (스프린트 기간에 비례)
  • 스크럼 마스터가 주도한다.

구성

  • 제품 백로그(Product Backlog)

개발할 제품에 대한 요구 사항 목록. 제품 책임자와 스크럼 팀은 사업적 가치 판단과 개발 예상 공수에 따라 일정을 예측하고 제품 백로그의 순서를 정하는데, 이것이 스프린트가 된다. 일반적으로 1~4주로 구성되며 2주가 가장 일반적이다.

  • 스프린트(Sprint)

제품 개발에 소요되는 반복적인 개발 주기 기간. 일반적으로 1~4주, 보통은 2주이다. 회사에서 정하는 이터레이션(iteration; 반복)이 개발 주기가 된다. 일반적으로 계획부터 제품 리뷰까지의 기간이 1스프린트이다. 하지만 경우에 따라서는 달라질 수 있다. 예를 들어 테스트로만 1주기를 채울수도 있다.

  • 스프린트 계획 회의(Sprint Planning Meeting)

스프린트 목표와 스프린트 백로그를 계획하는 회의. 제품 백로그를 분석하여 스프린트 주기에 맞게 개발 계획을 세운다. 제품 책임자는 실현하고자 하는 제품의 백로그를 우선 순위에 따라 확정하고, 이 우선 순위는 팀과 합의에 의해서만 변경할 수 있다.

  • 스프린트 백로그(Sprint Backlog)

스프린트 주기 동안 완료해야 하는 개발 팀의 우선 순위 작업 목록. 개발 팀은 과거의 스프린트 수행 실적에 근거하여, 실제로 목표를 달성할 수 있는 팀 역량을 예측하의 범위를 예측하여야 한다. 예정(to do), 진행(in progress), 완료(done)와 같이 현재 스프린트의 작업 현황을 확인하기 위해 작업 보드(task board)를 사용하기도 한다.

  • 일일 스크럼 회의(Daily Scrum Meeting)

날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유) 스프린트 백로그를 잘 완수하고 있는지 확인하는 짧은 회의.

  • 실행 가능한 제품(Product Increment, Potentially Shippable Increment; PSI)

이전 스프린트의 모든 작업을 포함하여 스프린트 동안 완료된 제품 백로그 항목의 총 집합. 스프린트의 결과로써 나오는 실행 가능한 제품. 제품은 스프린트의 종료 시점에서 스크럼 팀의 완료 정의(DoD; definition of done)에 따라 완료되어야 하고, 제품 책임자의 배포 여부 결정과 무관하게 완전히 기능을 갖추고 사용 가능한 상태여야 한다.

  • 번다운 차트(Sprint burn-down chart)

스프린트 백로그의 남은 작업을 보여준다. 매일 업데이트 되고, 스프린트 진행을 간단하게 나타낸다. 참고가 되는 빠른 시각화를 제공한다. 수평 축은 스프린트의 날짜이고, 수직 축은 각 날짜의 남은 작업(보통 남은 작업 시간 추정치)을 나타낸다.

스프린트 동안 이상적인 번-다운 차트가 작성된다. 스프린트 기간 동안 각 멤버는 스프린트 백로그에서 업무를 선택하여 작업한다. 마지막 날 남은 시간을 모두 완료로 변경한다. 이렇게 번다운 차트는 매일 갱신된다.

  • 배포 번업 차트(Release burn-up chart)

배포까지의 추적 진행을 가시적으로 보여준다. 각 스프린트의 종료에서 변경되고, 예측 범위를 산출하는 진행을 보여준다. 수평 축은 배포, 수직 축은 각 스프린트 종료에서 완료된 작업의 양(보통 완료 작업의 누적된 스토리 포인트 양)을 나타낸다. 진행률은 예측 범위를 나타내는 수평 축을 따라 커지는 선으로 그려진다. 배포 번업 차트는 어느 정도 분량의 작업이 완료되고, 추가되거나 제거되었는지(만일 수평 축 범위 선이 움직일 경우), 또 해야할 작업이 얼마나 남았는지 파악하기 쉽게 해준다.

용어

다음의 용어는 스크럼 프레임웍을 사용하는 제품 개발에서 종종 사용된다.

  • 스크럼 팀(Scrum Team) : 제품 책임자, 스크럼 마스터, 개발 팀
  • 제품 책임자(Product Owner) : 이해 당사자의 관심사를 대변하는 제품 백로그를 유지하는 책임을 가지며, 개발 팀이 맡은 작업 가치를 보장하는 사람.
  • 스크럼 마스터(Scrum Master) : 스크럼 프레임웍이 바르게 사용되도록 하며 그 이익을 극대화하는 것을 책임지는 사람
  • 개발 팀(Development Team) : 각 스프린트가 종료될 때마다 실행 가능한 제품의 개발을 책임지는 다기능을 가진 사람들의 그룹
  • 스프린트 번아웃 차트(Sprint burn-down chart) : 스프린트 동안 일간 진행 상태 표시
  • 배포 번다운 차트(Release burn-down chart) : 제품 백로그에서 완료된 기능의 진행 상태 표시
  • 제품 백로그(Product Backlog (PBL) list) : 요구 사항을 우선 순위대로 정리한 목록
  • 스프린트 백로그(Sprint Backlog (SBL) list) : 스프린트 동안 완료한 작업을 우선 순위대로 정리한 목록
  • 스프린트(Sprint) : 팀이 확정한 제품 백로그에 대해 개발이 이루어진 기간(보통 1-4주). 일반적으로 타임-박스(time-box) 혹은 이터레이션(irritation)으로 불리기도 한다. 타임-박스는 특정 프로젝트나 특정 작업을 위해 할당된 고정된 시간 기간을 의미한다.
  • 스파이크(Spike) : 컨셉을 연구하거나 간단한 시제품을 제작하는 데에 사용되는 고정된 시간. 스파이크는 스프린트와 스프린트 사이에 계획될 수도 있고, 대규모 팀의 경우 여러 스프린트 인도(delivery) 목표 중의 하나로 취급될 수 있다. 스파이크는 예산 확보, 지식 확장, 혹은 개념 증명을 위해 크고 복잡한 제품 백로그의 인도 전에 도입된다. 스파이크의 기간과 목표는 개발 시작 전에 제품 책임자와 개발 팀이 협의한다. 스프린트와 달리 스파이크는 유형적(tangible)이거나, 출시 가능(shippable)하거나, 가치있는(valuable) 기능성을 산출할 수도 있고 아닐 수도 있다. 예를 들어 스파이크의 목표는 행동의 과정에 대한 결정에 성공적으로 도달하는 것이 될 수 있다. 스파이크는 시간이 다 되면 목표가 달성되지 않았어도 끝이 난다.
  • 작업(task) : 스프린트 계획 또는 스프린트 동안 스프린트 백로그에 추가되는 일의 항목. 완료하는 데에 플요한 예측 시간을 포함한다. 일반적으로 작업은 하루 안에 완료할 수 있을 정도로 범위가 작아야 한다.
  • 완료 정의(Definition of done; DoD) : 제품 백로그가 완료되었는지 여부를 결정하는 종료 기준. 대부분의 경우 DoD는 모든 회귀 테스트(Regression Test)가 성공적으로 끝나야 한다. 완료의 기준은 스크럼 팀마다 다양하나, 하나의 팀 내에서는 일관되어야 한다.
  • 속도(Velocity) : 팀이 스프린트에서 할 수 있는 노력의 총량. 수치는 최근의 스프린트에서 완료한 작업을 평가(보통은 사용자 스토리 포인트)해서 나온다. 속도 자료 히스토리는 팀이 앞으로의 스프린트에서 얼마나 작업할 수 있는지 이해하고 지원하는 지침이다.
  • 장애(Impediment) : 팀 구성원이 최대한 효율적으로 작업하는 것을 방해하는 모든 요소.
  • 비정상적 종료(Abnormal termination) : 제품 책임자는 필요할 경우 스프린트를 취소할 수 있다. 제품 책임자는 팀, 스크럼 마스터, 경영진의 의견을 수렴한다. 예를 들어 경영진은 외부 환경이 스프린트의 목표의 가치를 무력화할 경우 해당 스프린트를 취소할 수 있다. 만일 스프린트가 비정상적으로 종료된다면 다음 단계는 종료 이유를 검토하고 새로운 스프린트 계획을 수립하는 것이다.
  • 스크럼벗(ScrumBut or Scrum but) : 팀의 필요를 위해 스크럼 원칙에 모순되는 방식으로 스크럼 프레임웍을 과도하게 변형하는 팀의 접근 방식을 설명하기 위한 용어. 공식적으로는 그러하나… 1) 다소 경멸적인 의미도 담고 있으므로 주의. 2)
    1. 부분적으로 애자일 프로젝트 관리 혹은 개발 방법론에 종사하는 사람.
    2. 세미-애자일, 혹은 유사-폭포수 개발 방법론에 종사하는 사람..
    3. 스크럼 방법론의 일부만 채택하는 사람.
    4. 일반적으로 “스크럼 하십니까?”라는 질문에 대한 대답에서 “그렇지만(but)“이라는 단어를 사용하는 사람.

비판

ScrumBut이라는 단어에서 알 수 있듯이 스크럼의 엄격한 기준에 대해 비판적인 시각도 존재한다. 다음 글을 참고.

스크럼_scrum.txt · 마지막으로 수정됨: 2018/07/01 17:29 (바깥 편집)