스크럼(Scrum)

<스크럼(Scrum) : 애자일 방법론의 한 종류>
- eXtreme Programming(XP)
- kanban
- 크리스털 패밀리
- Feature-driven development
- Adative software development
- 익스트림 모델링


<스크럼(Scrum)>
- 반복주기 : Spring(1~4 Week) -> 프로젝트의 일정은 고정
- Sprint를 통해서 최종적인 산출물(잠재적으로 출시 가능한 제품) : Increment
- Sprint Backlog : Spring 동안에 수행해야하는 일 목록(목표)
- Product Backlog : 우선순위에 따라서 해당 Spring 동안 해야할 일을 가져온다
- Sprint Planning Meeting : 해당 Sprint 동안에 해야될 일을 선정하는 것 -> 우선순위가 높은 순서대로
- Daily Scrum Meeting : (Every 24hours) 15분 이내 모든 팀원들이 모여서 회의한다
- Scrum 개발팀(=Two pizza team) : 3명~9명(소규모)
- Spring Review : 고객으로부터 피드백을 받아서 고객의 가치를 좀 더 반영시키고자 하는 제품을 완성하기 위해서(이 제품에 관계 있는 모든 관계자들을 초청)
- Sprint Retrospective(회고) : Spring를 개선하기 위해서 필요(Srcum 팀만 참여, 외부인은 참여하지 않는다)
 


<3-5-3 규칙>
1. 스크럼팀을 구성할 3명의 역할
- Product Owner
- Srcum Master
- Team

2. 스크럼 프로세스를 수행할 때 5가지의 이벤트
3. 스크럼을 수행하면서 나오는 산출물 3가지



<스크럼 팀 : 스크럼 역할>
- 제품 책임자(Product Onwer(PO))
  - I decided what to do & why : 무엇을 만들어야 되는 지, 왜 만들어야 되는 지 

- 스크럼 마스터(Scrum Master(SM)) 
  - I focus on how to work better : 팀 구성원이 스크럼 프로세스에 따라서 제대로 수행할 수 있도록 도움을 주는 역할, 일을 더 잘 할 수 있도록 개발팀과 제품 책임자를 도와주는 역할

- 개발 팀(Team(3-9 Pax))
  - We do the work/development : 실제적으로 일을 하는 개발자들



<제품 책임자(Product Owner)>
- 고객이 원하는 바를 파악하여 이를 제품에 반영
- 제품이 추구하는 방향(vision, roadmap)을 설정하고 고객이 가장 가치가 있는 제품을 빨리 전달 받을 수 있도록 요구사항 우선 순위를 매김
- 고객으로부터 피드백을 받아 제품에 반영
- 개발 팀에게 고객의 니즈(needs)를 설명
☆ key point : 제품 백로그(Product Backlog)를 관리


<비젼(Vision)>
☆ 비전은 프로젝트의 방향성을 보여준다
- 프로젝트를 통해서 우리가 달성하고자 하는 것에 대한 간결하면서도 명확한 대답
- 모든 이해 관계자들이 의사 결정하는 기반과 프로젝트의 방향성을 제공
- 모든 프로젝트 이해 관계자들이 공유해야만 한다
  따라서 비전은 추상적이기 보다는 가능한 프로젝트를 통해 달성하고자 하는 것을 명확하고 간결해야 하며 수분 안에 이해될 수 있도록 표현한다
- '누가' 제품을 구매하는가? 목표 대상 고객이 누구인가?
- 고객은 '무엇'을 필요로 하는가?
- 제품의 '어떤 점'이 고객에게 가치를 전달하여 구매하게 하는가?
- 고객이 시장이 '다른' 제품보다 어떤 점이 이 제품을 선호하게 하는가?



<예제>
[예제] 어떤 소프트웨어 개발회사에서 H 대학교에서 운영하고 있는 도서관리 프로그램을 도서 이용률을 높이기 위해 확장하는 프로젝트(H-Lib)를 수행한다고 하자

- 목표 고객과 고객의 필요성 : H 대학교 도서관을 자주 이용하면 보답 받고자 하는 학생들을 위해
- 고객에게 가치 전달 : H-Lib은 도서 대여 횟수와 이용 시간에 따라 여러 용도로 사용할 수 있는 포인트를 제공하는 기능을 한다 
- 다른 제품과의 차별성 : 도서 대여 횟수에 따라 커피를 구매하거나 대여 기간을 연장할 수 있는 포인트를 제공한다


<스크럼 마스터(Scrum Master)>
- 사람들이 스크럼을 제대로 이해하고 수행하고 있는지에 대한 책임
- 이를 위해, 스크럼 마스터들은 스크럼 팀이 스크럼의 이론과 실천, 그리고 규칙들을 잘 따르고 있는지 보장해야 한다
- 해당 조직에 스크럼이 잘 자리 잡을 수 있도록 코칭
- 스크럼 팀을 도외주는 리터(Servant-Leader)



<개발팀>
- 자기 조직화(Self-Organization)
  - 팀원들이 외부의 명령이나 통제 없이 스프린트 목표를 달성하기 위한 최상의 방법을 결정

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

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

- 팀 전체로서 성공하고 팀 전체로서 실패
- 팀의 지속성(Continuity)



<스크럼 이벤트/Ceremonies>
- 스프린트 계획
- 일일 스크럼
- 스프린트 리뷰
- 스프린트 회고
- 스프린트


<예>
- 1차 스프린트(기본 로그인 기능)
  - 로그인 웹 페이지 생성
  - 웹 페이지에 사용자 id와 비번을 입력할 수 있는 텍스트 필드 추가
  - 로그인 버튼
  - 입력을 검증하는 기능 및 스타일링 없음(No CSS)
  - 로그인 버튼을 누르면 환영 웹 페이지를 보여준다

- 2차 스프린트(비밀번호 검증)
  - 입력 값에 대한 검증 기능 제공
  - CSS 추가하여 웹페이지 스타일링
  - 타당하지 않은 비번으로 입력했을 때 오류 메시지 생성

- 3차 스프린트(세션 기능)
  - 비밀번호를 잊어버렸을 때 재생성하는 기능
  - Remember me 기능 추가
  - 사용자가 로그인했을 때환영 웹페이지가 아닌 적절한 웹 페이지로 redirect


<스프린트 계획 절차>
1) 스프린트 목표 설정
2) 스프린트에서 개발할 사용자 스토리 선정
3) 스토리를 태스크로 분할



<일일 스크럼 미팅>
- 스탠드업 미팅이라고도 한다
- 매일 정해진 시간에 정해진 장소에서 개발팀이 모여 각자 어제 했던 일, 오늘 할 일, 작업을 수행하는 중에 문제가 되는 일과 도움이 필요로 하는 일에 대해 이야기 
- 개발자 자신이 맡고 있는 테스크를 완료하는 데까지 남은 시간을 이야기 한다
- 미팅 시간은 15분정도 간단하고 빠르게 진행하는 것을 원칙
- 만약 장애 요인이나 문제점이 있다면 미팅 후 바로 해결
- 일일 스크럼 미팅을 통해 팀의 "진척상황"이나 "이슈"들을 공유할 수 있고 '프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방'



<스프린트 리뷰>
- 스프린트가 종료되면 개발팀은 스프린트 동안 개발한 제품을 고객을 포함한 이해관련자에게 구현된 기능을 보여주면서 데모 수행
- 고객은 자신의 요구사항이 해당 스프린트 동안 잘 반영되었는지 평가를 하고 피드백
- 제품 오너는 스프린트 리뷰에서 도출된 여러 지적사항이나 개선 사항을 정리하여 다음 스프린트에 반영될 수 있도록 제품 백로그를 다시 갱신



<스프린트 회고>
- '스프린트가 끝나는 시점'이나 '일정 주기로 수행'
- 프로젝트를 진행하는 과정에서 드러난 좋았던 점, 여러 가지 문제나 미진한 점 등을 도출
- 보다 나은 방향으로 개선할 수 있는 방법을 모색
- 회고를 통해 이미 설정된 프로세스로만 프로젝트를 진행하는 것이 아니라
  프로세스가 계속적으로 개선되도록하여 변화하는 비즈니스 환경에 보다 능동적으로 적응할 수 있도록 한다


<스크럼 산출물>
- Product backlog
- Sprint backlog
- Increment(Potentially Shippable Increment/product) : 잠재적으로 출시 가능한 제품 종분



<제품 백로그 : 요구사항 목록>
- 제품에 필요한 모든 것을 기술한 우선순위가 있는 업무 목록

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



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



<Mike Cohn 사용자 스토리>
- 간결하게 작성
- 대회를 위한 매개체의 역할
  - User Story Template
  - As a [user role] : Who
  - I want to [desired feature] : What
  - so that [value/benefit] : Why


<예제>
- 구매자로서(who) 나는 과거에 구매한 물품들을 볼 수 있도록(why) 주문 이력을 확인하고 싶다(what)
- ATM 관리자로서(who) 나는 고객이 현금을 인출할 수 있도록(why) ATM에 현금을 채우고 싶다(what)
- 교직원으로서(who) 나는 학교에 자동차로 출퇴근하기 위해(why) 주차권을 구입하기를 원한다(what)
- 학생으로서(who) 나는 통과 여부를 빨리 확인하기 위하여(why) 시험 점수를 온라인으로 확인하고 싶다(what)
- 구매자로서(who) 나는 물품의 평판을 확인하기 위해(why) 선정된 물품의 리뷰를 보고 싶다(what)



<What's wrong?>
- 사용자로서(who) 나는 키워드 정보만으로 책을 탐색하고 싶다(what) : why가 없다
보충 -> 사용자로서(who) 나는 원하는 책을 찾는 시간을 절약하기 위해(why) 키워드 정보만으로 책을 탐색하고 싶다(what)



<사용자 스토리>
- 소프트웨어 사용자나 구매자에게 가치를 줄 수 있는 기능
- 스토리는 고객이나 개발자 모두 이해할 수 있도록 고객이 작성
- ☆스토리의 세 측면 3Cs
  - 카드(Card) : 고객의 요구사항을 문서화하기 보다는 표현하기 위한 것(대화의 초대)
  - 대화(Conversation) : 대화를 통해 세부사항을 구체화
  - 테스트(Confirmation) : 스토리의 완료 여부를 판단
- ex) : 구매자로서 나는 체크아웃하기 전에 장바구니의 물건들을 조정할 수 있도록 장바구니에 담겨진 물품들을 검토할 수 있다



<전통적 개발방식에서 요구사항>
- No 대화
- 모든 상세한 것은 문서화
- 모든 요구사항들을 같은 수준으로 상세화
  - 전혀 개발이 되지 않을 요구사항이나 나중에 발견한 경우는?



<애자일에서 사용자 스토리 : Conversation)>
- 대화는 이해의 공유(Shared understanding)를 촉진한다

 

<스토리와 테스트 : Confirmation>
- acceptance criteria(인수기준)을 만족해야 사용자 스토리를 완료할 수 있다



<스토리와 3Cs>
- As a [registered user(카드)], I want to [log in], so I can [access subscriber contest]



☆<INVEST : 좋은 사용자 스토리를 만들 때 6가지 항목>
- Independent(독립적)
  - 사용자 스토리는 가능한 의존성이 적어야 한다
  - 의존성이 많은 사용자 스토리는 개발 우선순위를 설정하는 작업을 복잡하게 한다
  - US1이 US2에 의존하지만 우선순위가 더 높은 경우는?

- Negotiable(협상이 가능)
  - 계약서가 아니다
  - 상세한 사항은 협상이 가능해야 한다
  - Placeholder for details
  - 보통 스토리를 개발해야 방식(how)을 특정하면 '협상 여지가 줄어든다'

- Valuable(가치)
  - 고객과 사용자에게 가치를 주어야 한다

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

- Small(작은), sized appropriately
  - 스토리는 알맞은 크기가 되어야 한다
  - Just-in-time
  - 다음 스프린트에서 개발될 사용자 스토리는 최소한 스프린트 내에 개발할 수 있는 크기로 분할

- Test(테스트 가능한)
   - 스토리의 완성여부를 판단할 수 있어야 한다



<제품 백로그의 특성>
- Deep
  - Detailed appropriately(적절한 세부사항)
  - Emergent(창발적, 발생적)
  - Estimated(추정)
  - Prioritized(우선 순위)


<Detailed Appropriately>
- 모든 PBI들은 동일한 수준으로 상세화하지 않는다
- 우선 순위가 높은 PBI들(다가오는 스프린트에서 작업 대상이 되는 PBI)은 바로 작업할 수 있는 정도의 크기로 분할되며 상세화된다
- 다른 PBI들은 크기가 상대적으로 크며 상세화가 덜 되어 있다



<Emergent(창발적, 갑자기 나타난다)>
- '비즈니스 환경 변화', '고객의 요구사항 변경' 등으로 제품 백로그는 고정되어 있지 않고 '계속해서 변경된다'
- PBI들은 제거될 수 있고 새로운 PBI가 제품 백로그에 추가되고 우선순위도 변경된다
- 요구사항은 계속 변경될 수 있다. 따라서 제품백로그도 고정되지 않고 지속적으로 변화가 일어난다


<Estimated>
- 각 PBI는 크기(추정치)를 가지고 있다
- 만약 우선 순위가 높은 PBI가 크기가 크다면 더 분할할 필요가 있음을 의미한다
- PBI의 크기를 추정할 때 스토리 포인트나 시간을 사용하는 경우가 많다
- 우선 순위가 높은 PBI는 크기를 스프린트 내에서 충분하게 개발 가능하도록 작게 분할 해야 한다


<스토리 포인트>
- PBI 추정 단위
- 크기를 상대적으로 나타내는 척도
- 스토리를 구현하는데 소요되는 상대적인 노력의 양과 개발 복잡도 그리고 내재된 위험성 등을 종합적으로 분석하여
  나타낸 값을 의미
  - 사용자 스토리의 규모를 표현하는 단위
  - 상대적 : 4점의 점수를 받은 스토리는 2점을 받은 스토리의 두 배 크기



<스토리 포인트 추정>
- 0, 1, 2, 3, 5, 8, 13, 21, 40, 100(피보나치수열)
- 5보다 약간 큰 스토리는? 
- 8보다 약간 작은 스토리는?
  - 스토리 포인트는 말 그대로 추정이다. 정확할 수도 없다. 스토리 포인트가 5인것과 6인것을 구분할 수 있는가?
-> 따라서 크기가 큰 추정치는 부정확하지만 크기가 작은 추정치 보다 정확하다고 할 수 있다

- 30인 스토리는 21로 추정할 수도 40으로 추정할 수도 있다. 따라서 크기가 클수록 정확도가 떨어진다
- 크기를 분할하면 정확도는 올라간다
- 스토리 포인트가 0인것은 이미 완료되었거나 시간이 거의 걸리지 않는 작업을 의미한다
- 보통 스토리 포인트가 13이상인 스토리는 분리할 필요가 있다. 만약 우선순위가 높은데 13이상인 스토리가 있다면 분할해야 할 것이다
- 우선 순위가 낮은 스토리는 에픽일 가능성이 크다
*Epic : Large user story



<스토리 포인트 추정>
- Planning poker 게임
  1. 스토리 낭독
  2. 질문 및 답변
  3. 추정 카드 선택 : 한 차수 이내 값
  4. 카드를 동시에 공개
  5. 추정치들이 서로 다를 경우 가장 높은 추정치를 내놓은 추정자와 가장 낮은 추정치를 내놓은 추정자가 이유 설명
  6. 수렴할 때까지 반복



<우선순위(MoSCoW)>
- M(Must)
  - 필수적인 기능이다.
    이 기능이 제공되지 않으면 제품으로써의 존재가치가 상실되지만 일단 제공되면 제품의 가치를 상승하는데 더 이상 기여를 하지 않는다
  - hear is "must". without it, there is no live organism. What is must in your application?
 
- S(Should have)
  - 중요하고 유용한 기능하며 가능하다면 포함되었으면 하는 기능이다
  - a hand is "should". Without it is hard. But you can survive even without hand. Well, in most cases

- C(Could have)
  - 만약 제공된다면 사용자의 만족도를 올릴 수 있는 바람직한 기능이다.
    현재 개발 일정에 여유가 없어 제공되지 않는다 할지라도 크게 문제가 되지 않는 기능을 의미한다
  - hair is "could". It is fine to have them, you even look nicer, but you will definitely survive without them

- W(Wont have)
  - 현재 개발 일정에서 누락되어도 아무 상관이 없는 기능을 의미한다
  - unnecessary waste




<우선 순위 기준>
- High customer value
- High benefit to the business
- Easy to be implemented(구현하기 쉬운 것)
- High risk(구현했을 때 어려움이 많은 것)
- High cost if not implement as soon as possible(바로 개발되지 않으면 비용이 많이 들어가는 것)
- Dependencies between items(아이템 사이에 의존성은 가능하면 없는 것)
- Contribute most to the next Sprint goal(다음 스프린트의 목표와 연관성이 많은 것)




<Prioritized>
- 다음 몇 개의 스프인트의 대사이나 첫 릴리즈 대상이 되는 PBI들에 대해 우선순위
  - 제품 백로그의 모든 PBI들을 우선순위하려고 노력하지 말라



<Srcum Events>
- Sprint
- Sprint Planning(스프린트 계획회의)
- Daily Scrum(일일 스크럼 미팅)
- Sprint Review
- Retropective(스프린트 회고)




<스프린트 계획(제품 백로그 -> 스프린트 백로그)>
- 스프린트 목표 달성을 위해 해야할 일을 우선 순위에 따라 제품 백로그에서 가져온다
- 스토리를 태스크로 분할
- 팀이 스프린트 목표 달성을 위해 스프린트 동안 할 수 있는 일만큼 가져온다
- 사용자 스토리는 스프린트 계획 회의 전에 스프린트동안 개발할 수 있도록 충분하게 상세화 되어 있으며 크기도 적절하게 분할 되어 있어야 한다

- 제품 백로그 : 스토리1, 스토리2, 스토리3, 스토리4
  - 스프린트 백로그 : 스토리(태스크, 태스크, 태스크, 태스크, 태스크)




<스프린트 계획회의(Sprint Planning)>
- ☆시간이 정해져 있는 것 : time boxed
- 스프린트를 준비하기 위한 회의
- Part1 : "무엇(What)"
  - 참가자 : 제품 책임자, 팀, 스크럼 마스터
  - 스프린트 목표 설정
  - 백로그 검토

- Part 2 : "어떻게(How)"
  - 참가자 : 팀, 스크럼 마스터, 제품 책임자(선택사항이지만 질문이 있으면 연락할 수 있어야 한다)
  - 팀이 스프린트 내에 할 수 있는 아이템 선정
  - 아이템(스토리)를 테스크 단위로 분할





<Part 2 : 스토리를 태스크로 분할>
1) 스토리에 대해 토론
2) 스토리를 태스크(task)로 나눈다
  - 일반적으로 스토리 하나를 개발자 한 명이 처음부터 끝까지 개발하지 않는다.
    개발자마다 전문분야가 있고 또 일을 분담하는 것이 스토리를 더 빨리 구현할 수 있기 때문이다. 
  - 스토리는 고객 또는 사용자 관점에서 기능을 서술. 개발자 관점으로의 전환 필요
  - ex) (스토리)사용자는 여러 기준으로 작업들을 검색할 수 있다 -> 기본 검색화면 구현, 상세 검색화면 구현, 결과 처리화면 구현, 기본(상세) 검색을 위한 질의어 작성 등
3) 각 태스크마다 개발자 한 명이 책임을 맡는다
4) 작업량 추정



<태스크 분할 및 소요시간 추정>
- 사용자 스토리를 태스크로 분할하고 각 태스크를 완료하는데 걸리는 시간을 추정
- 사용자 스토리 : 사용자 관점
- 태스크 : 개발자 관점
- Push X Pull(Self organizing)



<백로그 정제 회의(Backlog refinement(grooming) meeting)>
  - 에픽(한 스프린트 내에서 완성할 수 없을 정도로 큰 사용자 스토리)보다 작은 사용자 스토리로 분할하고 분할된 사용자 스토리들에 대한 스토리 포인트 추정
  - 제품 백로그의 PBI들이 DoR을 만족하도록 정제하는 회의이다
  - 다음 다가올 스프린트에 완성할 사용자 스토리들을 정제하는 작업
  - 새로운 사용자 스토리에 대한 크기(스토리 포인트) 추정
  - 필요하다면 기존의 사용자 스토리에 대한 재추정
  - 우선 순위 조정
  - 스프린트 10%이내 시간 할애
  - 백로그정제회의는 스크럼 이벤트에 속하지 않는다




<준비의 정의(Definition of Ready, DoR)>
- 제품 백로그에서 스프린트 백로그로 이동하기 위해 만족되어야 하는 요건 목록
  - 가치가 명확하게 기술되었다
  - 의존 사항이 모두 식별되었다
  - 인수 기준이 명확하며 테스트 가능하다
  - PBI가 스프린트 내에 완성할 수 있을 만큼 충분히 작게 추정되었다
- 스토리가 DoR 요건을 만족하면 스프린트에서 개발할 수 있는 준비 상태에 있다는 의미




<속도(Velocity) 추정>
- ☆속도 : 한 스프린트 동안에 완료된 스토리 포인트들의 합
- ex) 스크럼 팀은 이 속도를 기반으로 다음 스프린트 계획을 만들어 나가게 된다. 만약, 우리팀의 속도가 50이라면, 다음 스프린트에는 50포인트 정도의 스토리들을 해결할 수 있다는 것을 예측할 수 있고 거기에 맞춰 스프린트 계획을 세우게 된다
- 만약 스프린트백로그에 있는 모든 스토리를 예정보다 빨리 완성하면 제품백로그에서 우선순위에 따라 사용자 스토리를 가져온다
- 팀의 진도를 평가하는 수단
- 이터레이션(스프린트)동안 완성된 스토리들의 스토리 포인트의 총 합
- 속도는 '완전히 완료(Done)'된 스토리들의 스토리 포인트 합이다
  - Almost Done, Not started는 포함되지 않는다
- 스프린트가 끝나지 않았는데 계획된 모든 스토리들을 완전하게 완료했다면 새로운 스토리를 제품백로그에서 가져온다
- 속도를 나타내는 그래프 : ☆Velocity Charts



<완료의 정의(Definition of Done, DoD)
- Done(완료) 상태로 가기 위해 만족해야 할 요건 목록
- 모든 스토리에 적용
- DoD는 모든 스토리에 적용되는 체크리스트이지만 인수 기준은 개개인 특정 스토리에 적용된다. 따라서 스프린트 동안에 DoR을 만족하는 스토리를  DoD를 만족하도록 한다
- DoD의 요건을 만족하지 못하는 스토리의 스토리 포인트는 속도를 계산할 때 고려되지 않는다
- 백로그 정제 회의에서 스토리들을 준비 상태로 만든 후(DoR 요건을 만족)에 스프린트 동안 DoD 요건을 만족하도록 한다




<☆DoD(Definition of Done) 예시>
- Unit Tests(단위테스트) 통과
- 코드 리뷰
- 리그레이션 테스팅 통과
- 기능 테스팅 통과
- 인수 기준 만족(사용자 스토리에 있는 인수기준)
*인수 기준은 스토리마다 다르다
- 사용자 문서 갱신
- 성능 테스팅 통과
- UX 디자이너 승인
- 제품 책임자 승인




<날짜가 고정되었을 떄 개발 범위 결정>
- 속도가 20으로 추정되는 팀이 2달 프로젝트(2주짜리 4개의 스프린트)를 수행한다고 가정하면 개발 범위는 
  - 만들어 질 스토리 크기 : 0.6*20*4=48
  - 만들 수 있는 스토리 크기는 1.6*20*4=128
  *0.6은 초기 속도 추정치(스프린트 처음을 시작하기 전)의 최소 보정치이고, 1.6은 최대 보정치이다






<릴리즈 계획(출시계획)>
- 날짜(Time)/예산(Cost) 3요소를 고려하여 무엇(Scope)을 전달할 수 있을지를 추정 -> iron triangle
- fixed(고정적) : Schedule(Time), Resources(Cost, Budget) 
- variable(가변적) : Scope(Features, Functionality)
- Quality : 시간과 비용을 고정할 때 범위를 결정




<릴리즈 계획 -2>
- 위험을 감수하고 개발 진행하고 개발에서 획득한 지식을 바탕으로 개발 진행 여부를 결정
- 릴리즈 날짜를 연기하거나 개발 인력을 추가
- '기술적 채무'(앞으로 해야 할 일을 하는데 필요한 시간을 담보로 오늘 빚을 냄, 소프트웨어 개발 과정에서 장기적 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용을 선택)
*기술적 채무 : Technical Debts
-> 시간에 쫓겨 제대로 설계를 하지 않거나 테스팅을 충분히 하지 않을 때 기술적 채무가 발생한다
-> 기술적 채무가 있다면 너무 많이 쌓이기 전에 중간 중간 채무를 갚어야 한다
  - 나쁜 설계
  - 결함
  - 불충분한 테스트 범위
  - 자동 테스트 대신에 수동 테스트



<릴리즈 계획 -3>
- 출시해야 되는 일의 양이 개발 팀이 최대로 할 수 있는 일의 양보다 큰 경우에
  - 개발 중단
  - 릴리즈 날짜 연기
  - 개발 인력 추가
  - 기술적 채무(Technical Debts)



<스크럼 도구>
- 스크럼 태스크 보드 : 매일 기록하는 프로젝트 현황판(스토리/To Do/In Progress/Done)
  - To Do : 아직 시작 안된 태스크
  - In Progress : 개발 중인 태스크
  - Done : 완료된 태스크
  - 태스크의 상태는 이처럼 3가지가 기본이지만 이외에 다른 태스크의 상태를 추가할 수 있다
  - 지속적으로 팀에게 프로젝트의 진행상황을 보여준다

- Burn down charts : 시간에 따라 남아 있는 일을 그래프로 표현(이상적 라인/현재 스크럼 진행상황)
- Burn up charts : 프로젝트 동안 어느정도의 일이 추가되고 제거되는지 보여준다
  - x축 : 경과된 스프린트
  - y축 : 스프린트동안 한 일의 양, 프로젝트 동안 할 일의 양