[소프트웨어공학] 스크럼

스크럼을 설명하기에 앞서 애자일 방법론을 먼저 살펴보겠다.
애자일 방법론의 종류로는,

• eXtreme Programming(XP)
• kanban
• 크리스털 패밀리
• Feature-driven development
• Adaptive software development
• 익스트림 모델링
• scrum

스크럼은 애자일 방법론 중의 하나이다.

1. 스크럼 프로세스 개요

3-5-3으로, 스크럼을 구성하는 3가지 역할, 스크럼 프로세스를 수행하는 5가지 이벤트, 스크럼을 수행하면서 나오는 3가지 산출물으로 이해한다.

2. 스크럼 역할

스크럼 팀은 제품 책임자, 스크럼 마스터, 개발 팀 3가지 역할이 있다.

1) 제품 책임자(Product Owner)

• 고객이 원하는 바를 파악하여 이를 제품에 반영

• 제품이 추구하는 방향(vision, roadmap)을 설정하고 고객이 가장 가치가 있는 제품을 빨리 전달받을 수 있도록 요구사항에 우선순위를 매김

• 고객으로부터 피드백을 받아 제품에 반영

• 개발 팀에게 고객의 니즈(needs)를 설명

• 실제적인 책임을 짐
  => 제품 백로그(product backlog) 관리

  비전

  • 프로젝트를 통해서 우리가 달성하고자 하는 것에 대한 간결하면서도 명확한 대답
  • 모든 이해 관계자들이 의사 결정하는 기반과 프로젝트의 방향성을 제공
  • 모든 프로젝트 이해 관계자들이 공유해야만 한다. 따라서 비전은 추상적이기보다는 가능한 프로젝트를 통해 달성하고자 하는 것을 명확하고 간결해야 하며 수 분 안에 이해될 수 있도록 표현

누가 제품을 구매하는가? 목표 대상 고객이 누구인가?
고객은 무엇을 필요로 하는가?
제품의 어떤 점이 고객에게 가치를 전달하여 구매하게 하는가?
고객이 시장의 다른 제품보다 어떤 점이 이 제품을 선호하게 하는가?

2) 스크럼 마스터(Scrum Master)

• 사람들이 스크럼을 제대로 이해하고 수행하고 있는지에 대한 책임

• 스크럼 마스터들은 스크럼 팀이 스크럼의 이론과 실천, 그리고 규칙들을 잘 따르고 있는지 보장

• 해당 조직에 스크럼이 잘 자리 잡을 수 있도록 코칭

• 스크럼 팀을 도와주는 리더(servant-leader)
  ** 여기서 리더는 통제하고 지시하는 일이 아니라 조력하는 일을 함

  3) 개발 팀

• 자기 조직화(self-organization)
  팀원들이 외부의 명령이나 통제 없이 스프린트 목표를 달성하기 위한 최상의 방법을 결정
  ** 스스로 알아서 최적의 방법을 결정한다는 것이 전통적인 개발 조직과는 다름

• Cross-functional
  - 다양한 배경과 지식을 가진 팀원들로 팀을 구성
  - 제품 백로그의 항목(들)을 가져와 스프린트동안 완성하여 동작하는 소프트웨어를 만들 수 있는 일련의 기술을 제공

• 적절한 규모(Two pizza team)
  3~9명

• 팀 전체로서 성공하고 팀 전체로서 실패

• 팀의 지속성(Continuity)
  제대로 scrum 팀원을 구성하기 위해서는 어느 정도 시간이 필요

  Tranditional Team vs Agile Team

• 전통적인 팀의 경우, 계층 구조로 이루어져 있어 프로젝트 리더가 일을 지시, 통제

• 애자일 팀의 경우, 외부에서 지시나 통제 없이 개발 팀이 한 팀이 되어 단일한 목표를 향해 개발
  ** Scrum master가 product manager가 아님, 동등한 입장에서 자기조직화가 될 수 있도록 일을 도움

3. 스크럼 이벤트/ceremonies

** 모든 Scrum Event에는 시간이 제한되어 있다. (time-boxed: 주어진 시간이 끝나면 종료시킨다.)

1) 스프린트

2) 스프린트 계획

스프린트 목표 설정 - 스프린트에서 개발할 사용자 스토리 선정 - 스토리를 태스크로 분할

• 해당 스프린트동안 해야될 일 = 스프린트 목표 설정

• 스프린트 목표 달성을 위해 해야할 일을 우선순위에 따라 제품 백로그에서 가져옴
  -> 팀이 스프린트 목표를 위해 스프린트동안 할 수 있는 일만큼 가져옴

• 스프린트를 준비하기 위한 회의
  part1: "무엇(what)"
  - 참가자: 제품 책임자, 팀, 스크럼 마스터
  - 스프린트 목표 설정
  - 백로그 검토
  part2: "어떻게(how)"
  - 참가자: 팀, 스크럼 마스터, 제품 책임자(선택 사항이지만 질문이 있으면 연락할 수 있어야 함)
  - 팀이 스프린트 내에 할 수 있는 아이템 선정
  - 아이템(스토리)를 태스크 단위로 분할
  1) 스토리에 대해 토론
  2) 스토리를 태스크(task)로 나눔
  - 사용자 스토리는 사용자 관점, 태스크는 개발자 관점
  ** 태스크 분할 및 소요 시간 추정
  - 사용자 스토리를 태스크로 분할하고 각 태스크를 완료하는 데 걸리는 시간을 추정
  - 이와 같은 과정을 팀의 가용시간이 넘지 않을 때까지 반복하여 사용자 스토리 추가
  3) 각 태스크마다 개발자 한 명이 책임을 맡음
  4) 작업량 추정

  3) 일일 스크럼

• 스탠드업 미팅

• 매일 정해진 시간에 정해진 장소에서 개발팀이 모여 각자가 어제 했던 일, 오늘 할 일, 작업을 수행하는 중에 문제가 되는 일과 도움을 필요로 하는 일에 대해 이야기함

• 개발자 자신이 맡고 있는 태스크를 완료하는 데까지 남은 시간을 이야기함

• 미팅 시간은 15분 정도로 간단하고 빠르게 진행하는 것을 원칙

• 만약 장애 요인이나 문제점이 있다면 미팅 후 바로 해결

• 일일 스크럼 미팅을 통해 팀의 진척 상황이나 이슈들을 공유할 수 있고 프로젝트 후반에 문제점이 갑자기 발생하는 것을 예방

  4) 스프린트 리뷰

• 스프린트가 종료되면 개발팀은 스프린트동안 개발한 제품을 고객을 포함한 이해관련자에게 구현된 기능을 보여주면서 데모를 진행

• 고객은 자신의 요구사항이 해당 스프린트동안 잘 반영되었는지 평가를 하고 피드백

• 제품 책임자는 스프린트 리뷰에서 도출된 여러 지적사항이나 개선 사항을 정리하여 다음 스프린트에 반영될 수 있도록 제품 백로그를 다시 갱신

  5) 스프린트 회고

• 스프린트가 끝나는 시점이나 일정 주기로 수행

• 프로젝트를 진행하는과정에서 드러난 좋았던 점, 여러 가지 문제나 미진한 점 등을 도출

• 보다 나은 방향으로 개선할 수 있는 방법을 모색

• 회고를 통해 이미 설정된 프로세스로만 프로젝트를 진행하는 것이 아니고 프로세스가 계속적으로 개선되도록 하여 변화하는 비즈니스 환경에 보다 능동적으로 적응할 수 있도록 함

• Scrum master, 제품 책임자, 개발팀이 참여 (외부의 이해당사자 참여 X)

스프린트 리뷰 = 제품 평가
스프린트 회고 = 프로세스 평가

4. 스크럼 산출물

1) Product backlog

• 제품에 필요한 모든 것을 기술한 우선순위가 있는 업무 목록 (요구사항 목록)

  업무 분류	백로그 업무 항목(PBI, Product Backlog Item)
  기능	도서관 이용 회원은 자신의 적립된 포인트 조회할 수 있다.
  비기능	도서관 이용 회원은 찾고자 하는 도서를 저자명을 이용하여 1분 이내에 조회 결과를 받아볼 수 있다.
  오류 수정	포인트 계산 기능에서 발견된 오류를 수정한다.
  지식 습득(스파이크)	개발자로서 나는 검색 엔진 설계의 타당성 확인을 위해 시제품을 만들어 확인한다.

  ** 스파이크: 기술적 의문에 대한 해결책을 구한다든지 제품에서 제공하는 기능과는 직접적 관련은 없으나 만들기 위해 여러 가지 지식을 습득하기 위한 작업

• 제품 백로그 특성 - DEEP

  1) Detatailed appropriately(적절한 세부사항)

• 모든 PBI들은 동일한 수준으로 상세화하지 않는다.

• 우선 순위가 높은 PBI들(다가오는 스프린트에서 작업 대상이 되는 PBI)은 바로 작업할 수 있을 정도의 크기로 분할되며 상세화된다.

• 다른 PBI들은 크기가 상대적으로 크며 상세화가 덜 되어 있다.

• 우선 순위에 따라 상세화 정도가 달라진다.
  ** 전통적 개발 방식에서는 요구사항들이 우선 순위에 상관없이 모두 동일한 수준으로 상세화되기를 요구한다.

  2) Emergent(창발적, 발생적)

• 비즈니스 환경 변화, 고객의 요구사항 변경 등으로 제품 백로그는 고정되어 있지 않고 계속해서 변경된다.

• PBI들은 제거될 수 있고 새로운 PBI가 제품 백로그에 추가되고 우선 순위도 변경된다.

• 애자일 선언문에서 애자일 방법은 계획을 따르는 것보다 변동에 반응하는 것에 더 가치를 둔다.

• 스프린트 리뷰동안 받은 고객의 피드백 등을 바탕으로 제품 책임자가 제품 백로그를 갱신(제거/추가/우선 순위 변경)한다.

  3) Estimated(추정)

• 각 PBI는 크기(추정치)를 가지고 있다.

• 만약 우선 순위가 높은 PBI가 크기가 크다면 더 분할할 필요가 있음을 의미한다.

• PBI의 크기를 추정할 때 스토리 포인트나 시간을 사용하는 경우가 많다.

• 우선 순위가 높은 PBI는 가능한 높은 정확도를 가지도록 크기를 추정해야 한다.

• 우선 순위가 높은 PBI는 크기를 스프린트 내에서 충분하게 개발 가능하도록 작게 분할해야 한다.

• 보통 13 이상인 스토리는 분할할 필요가 있다. 만약 우선 순위가 높은데 13 이상인 스토리가 있다면 분할해야 할 것이다.

• 우선 순위가 낮은 스토리는 에픽일 가능성이 크다.
  ** Epic: large user story (아주 큰 스토리)
  -> 한 스프린트동안 개발하지 못할 큰 사용자 스토리로 취급하기도 함

• 가치가 너무 명확한 경우에는 생략하여 기술하는 경우도 있지만 가능한 기술하는 게 좋다.

• 우선 순위가 낮을수록 Stoty Point가 커짐

  스토리 포인트

• 스토리를 구현하는데 소요되는 상대적인 노력의 양과 개발 복잡도 그리고 내재된 위험성 등을 종합적으로 분석하여 나타낸 값을 의미

• 사용자 스토리의 규모를 표현하는 단위이자, PBI 크기 추정 단위

• 스토리 포인트는 크기를 상대적으로 나타내는 척도
  ex) 4점의 점수를 받은 스토리는 2점을 받은 스토리의 두 배 크기

• 스토리 포인트를 추정할 때 피보나치 수열을 많이 이용
  (피보나치 수열의 특징은 숫자가 클수록 간격이 커짐)

• 크기가 크게 추정된 사용자의 스토리는 불확실성이 있다는 의미
  -> 크기가 큰 추정치는 부정확하지만 크기가 작은 추정치는 보다 정확하다고 할 수 있음

• 스토리 포인트가 0인 것은 이미 완료되었거나 시간이 거의 걸리지 않는 작업을 의미

• 스토리 포인트가 무한대인 것은 스토리 추정이 불가하거나 정보가 너무 없다는 것을 의미

• 크기를 분할하면 정확도는 올라감

• 스토리 포인트를 추정하는 대표적인 방법 - Planning poker 게임
  1) 스토리 낭독
  2) 질문 및 답변 (제품 책임자-> 답변)
  3) 추정 카드 선택: 한 차수 이내 값
  4) 카드를 동시에 공개
  5) 추정치들이 서로 다를 경우 가장 높은 추정치를 내놓는 추정자와 가장 낮은 추정치를 내놓는 추정자가 이유를 설명
  6) 수렴할 때까지 반복
  -> 그룹의 합의를 바탕으로 하는 방법

  4) Prioritized(우선 순위)

• 다음 몇 개의 스프린트 대상이나 첫 릴리즈 대상이 되는 PBI들에 대해 우선 순위
  • 제품 백로그의 모든 PBI들을 우선순위할 필요 없음

우선순위(MoSCoW)

• M(Must)
  필수적인 기능, 이 기능이 제공되지 않으면 제품으로서의 존재 가치가 상실되지만 일단 제공되면 제품의 가치를 상승하는데 더 이상 기여를 하지 않음
• S(Should have)
  중요하고 유용한 기능, 가능하다면 포함되었으면 하는 기능
• C(Could have)
  만약 제공된다면 사용자의 만족도를 올릴 수 있는 바람직한 기능, 현재 개발 일정에 여유가 없어 제공되지 않는다 할지라도 크게 문제가 되지 않는 기능
• W(Wont have)
  현재 개발 일정에서 누락되어도 아무 상관이 없는 기능

사용자 스토리

애자일 방법에서는 사용자의 요구사항을 사용자 스토리(User Stroy) 형태로 표현하는 경우가 많다.

• Who(이해당사자가 누군지), What(어떤 기능을 요구하는지), Why(왜 요구하는지;어떠한 가치를 얻기 위해 요구하는지) 3가지 구성요소로 Mike Cohn가 제안한 포맷

  ex1) 구매자로서 나는 과거에 구매한 물품들을 볼 수 있도록 주문 이력을 확인하고 싶다.
  ex2) 학생으로서 나는 통과여부를 빨리 확인하기 위하여 시험 점수를 온라인으로 확인하고 싶다.

• 간결하게 작성

• 대화를 위한 매개체 역할

• 소프트웨어 사용자나 구매자에게 가치를 줄 수 있는 기능

• 스토리는 고객이나 개발자 모두 이해할 수 있도록 고객이 작성
  - Scrum Master의 도움 받아 고객을 대신해 제품 책임자가 작성할 수 있음

• 시스템을 제공하는 개발자의 관점이 아닌 항상 Who(사용자, 이해관계자, 구매자)의 관점

• 스토리의 세 측면 3Cs

  • Card(카드): 고객의 요구사항을 문서화하기 보다는 표현하기 위한 것(대화의 초대)
    - 포스트잇 카드, 인덱스 카드 등 이용 -> 내용을 쉽게 변경하거나 추가하기 위해
    - 대화의 시발점(대화의 매개체)
  • Conversation(대화): 대화를 통해 세부사항을 구체화
  • Confirmation(테스트): 스토리의 완료 여부를 판단

  전통적인 개발 방식에서 요구사항

• No 대화, 대화가 제한적 -> 모든 상세한 것은 문서화

• 모든 요구사항들을 같은 수준으로 상세화(우선순위에 상관없이)

• 대화 없이 문서화된 요구사항을 볼 경우, 같은 요구사항을 보더라도 각자 다르게 생각할 수 있음
  -> 고객이 요구하는 시스템을 제대로 만들 수 없음

• 처음부터 모든 기능을 만들기 위해 노력

  애자일에서 사용자 스토리: Conversation

• 대화는 이해의 공유(Shared understanding)를 촉진

  스토리와 테스트: Conversation

• acceptance criteria(인수 기준)를 만족시켜야 사용자 스토리가 완료되었다고 봄

  좋은 스토리가 가지는 6가지 조건: INVEST

• Independent(독립적)
  - 사용자 스토리는 가능한 의존성이 적어야 함
  - 의존성이 많은 사용자 스토리는 개발 우선순위를 설정하는 작업을 복잡하게 함
  -> 개발 순서가 정해져버림
  -> 의존성이 생길 경우
  1. 제품 책임자, 개발 팀이 서로 소통하여 의존 관계가 있는 스토리를 한 스크립트 내에서 개발
  2. 의존 관계가 있는 스토리들을 하나로 병합

• Negotiablel(협상이 가능)
  - 계약서가 아니라는 점
  - 상세한 사항은 협상이 가능해야 함
  - Placeholder for details
  - 보통 스토리를 개발해야 방식(how)을 특정하면 협상 여지가 줄어듬
  - who(role), what(action), why(value) 중 what(action)에 관한 것
  - 협상이 가능하지 못한 사용자의 스토리는 action이 고정되어 선택할 수 없게 됨
  

• Valueable(가치)
  - 고객과 사용자에게 가치를 주어야 함
  - who(role), what(action), why(value) 중 why(value)에 관한 것

• Estimable(추정이 가능한)
  - 크기를 추정하여 필요한 노력과 비용을 추정할 수 있어야 함(story point 단위)
  - 너무 큰 스토리(epic)는 분할
  - 정보가 없는 스토리는 정보를 획득하는 작업(스파이크)를 함
  

• Small(작은)
  - 스토리는 알맞은 크기가 되어야 함(Sized appropriately)
  - Just-in-time
  - 다음 스프린트에서 개발될 사용자 스토리는 최소한 스프린트 내에 개발할 수 있는 크기로 분할
  -> 나중에 개발될 사용자 스토리들은 당장 인수 조건을 기술하지 않아도 됨(모든 사용자 스토리가 인수 조건을 가져야 하는 건 아님)

• Test(테스트 가능한)
  - 스토리의 완성여부를 판단할 수 있어야 함
  - 스프린트가 끝나면 동작하는 increment 안에서 contribution할 수 있도록 테스트 조건 통과 필요

  2) Sprint backlog

  3) Increment(Potentially Shippable Increment/product)