3. scrum

대학교/소프트웨어공학론

3. scrum

CodeJin 2023. 4. 24. 01:48

※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※

Scrum

scrum이란

agile 방법론의 한 종류
agile은 하나의 방법론이기 때문에, agile 원칙을 지키는 방법론들은 모두 agile 방법론이라고 할 수 있다.
scrum 역시 agile 방법론을 지키는 방법론이고, 즉 agile 방법론의 한 종류이다.

scrum process

agile에서의 iteration을 scurm에서는 sprint라고 한다.
- sprint의 소요시간은 해당 프로젝트 시행동안 고정된다. 2주면 2주, 10일이면 10일
sprint가 끝나고 잠재적으로 출 시할 수 있는 제품을 increment라고 한다.
sprint backlog
- sprint 기간동안 해야할 일이 담긴 목록
- Product backlog에서 우선순위에 따라 가져온다.
Product Backlog
- Product owner가 고객, 사용자로부터 수집한 요구사항을 모은 것으로, 프로젝트 전 기간동안 해야할 일의 목록
- product owner는 고객에게 더 높은 가치를 줄 수록 당연히 우선순위를 더 높게 책정한다.
Sprint Planning meeting
- Product Owner, team, scrum master가 모여 product backlog에서 sprint 기간동안 할 일을 정하는 회의
Daily Scrum Meeting
- 매일, 15분 이내로 짧게 진행하는 회의
- 짧은 시간 진행되어야하기 때문에 team은 3~9명정도로 구성된다.
- stand up meeting(짧게, 일어서서), 2-pizza meeting(피자 2판 시켜 먹으면 끝나는 시간)이라고도 함
- project 현황을 공유하는 아주 중요한 회의
sprint review
- increment를 만들고, 고객에게 피드백을 받는 시간
- 피드백을 받고, 고객의 가치를 수용하고 반영하기 위함 → agile
sprint retrospective
- sprint review 종료시 하는 회고
- sprint를 개선하기 위한 회의

3-5-3 rules

Scrum Roles(3)
- Product Owner
  - 무엇을/왜 만들어야 하는지 결정
  - 고객이 원하는 바를 파악하여 제품에 반영
  - 제품이 추구하는 방향(vision, roadmap) 설정
  - 고객이 가장 가치가 있는 제품을 빠르게 전달받을 수 있도록 우선순위
  - 고객으로부터 피드백 반영
  - 개발팀에 고객의 니즈 설명
  - (**매우 중요**) Product Backlog 관리
  - vision
    - 프로젝트의 방향성
    - 누가 제품을 구매하는가? / 목표 대상 고객이 누가인가?
    - 고객은 무엇을 필요로 하는가?
    - 제품의 어떤 점이 고객에게 가치를 전달하여 구매하게 하는가?
    - 다른 제품보다 어떤 점이 이 제품을 선호하게 하는가?
- Scrum Master
  - 모든 구성원(PO, Team members)이 scrum process에 따라 일을 수행할 수 있도록 조력
  - scrum 일을 하면서 방해되는 장해물이 있을때 이를 치우는 것도 일
  - 해당 조직에 scrum이 잘 자리잡도록 코칭, 즉 scrum 팀을 도와주는 리더(servant-reader)
  - 하나의 대장이라기보다는 Team의 일원으로써 행동
- the Team
  - 개발하는 팀
  - 3~9명
  - self-organization
    - 팀원들이 외부 압박 없이 스프린트 목표를 달성하기 위한 최상의 방법 결정
  - Cross-functional
    - 다양한 배경과 지식을 가진 팀원들로 팀 구성
    - product backlog의 항목을 가져와 스프린트동안 완성하여 동작하는 네품을 만들 수 있는 기술 제공
  - 팀 전체로서 성공하고 팀 전체로서 실패함
  - 팀의 지속성
Scrum Events / ceremonies(5)
- Sprint Planning Meeting
  - product backlog에서 우선순위에 따라 가져와 sprint의 목표 설정
  - sprint에서 개발할 사용자 스토리 선정
  - 스토리를 태스크로 분할
    - 스토리 하나는 개발자 한명이 개발하지 않고, 스토리를 분할하여 만들어진 태스크를 개발자 한명이 맡는다.
  - product backlog → Sprint backlog
    - Capacity based Scrum Planning
      - Capacity: 한 스프린트동안 Scrum Events활동(sprint제외), 백로그 정제 회의를 제외 오로지 프로젝트에 관련된 일에 사용할 수 있는 팀의 가용시간
      - 사용자 스토리를 태스크로 분할하고, 각 태스크를 완료하는데 걸리는 시간을 추정한다. 이를 팀의 capatcity가 넘지 않을때까지 반복하여 user story를 추가함
    - user story는 sprint planning meeting 전에 sprint동안 개발할 수 있도록 충분히 상세화되어야 있으며 크기도 적절하게 분할되어있어야 한다.
    - BackLog refinement(grooming) meeting (Scrum Events가 아니다!!)
      - epic(large user story)을 작은 user story로 분할하고 스토리 포인트 추정
      - 다음 sprint에 완성할 user story들을 정제(refinement)하는 작업
      - 새로운 user story에 대한 스토리 포인트 추정 및 (필요시)기존의 user story의 스토리 포인트 재추정
      - 우선순위 조정
      - sprint의 10% 이내 시간 할애
    - DoR (Definition of Ready)
      - product backlog에서 sprint backlog로 이동하기 위해 만족되어야 하는 요건 목록
      - 가치가 명확히 기술되었는가? 의존 사항이 모두 식별되었는가? 인수기준이 명확하고 테스트 가능한가? PBI가 sprint 내에 완성할 수 있을 정도로 충분히 작게 추정되었는가?
    - Velocity
      - 한 sprint동안 완료된 스토리 포인트의 합
      - 팀의 진도를 평가하는 수단
      - 추정 속도와 실제 속도는 다를 수 있기 때문에, 불확실성으로 인한 보정치가 정해지기도 한다.
    - DoD (Definition of Done)
      - 스토리가 종료상태로 가기 위해 만족햐야할 요건 목록
      - team에서 정함
      - DoD의 요건을 만족하지 못하는 스토리의 스토리 포인트는 velocity 계산시 고려되지 않는다
      - 과정
        
        Unit Tests 통과
        
        코드 리뷰
        
        리그레션 테스팅 통과
        
        기능 테스팅 통과
        
        인수 기준 만족
        
        사용자 문서 갱신
        
        성능 테스팅 통과
        
        UX 디자이너 승인
        
        제품 책임자 승인
      - 등등 항목은 달라질 수 있지만, DoD 항목은 모든 스토리에 적용된다. 하지만 인수 기준은 각각의 스토리에 따라 다르다
- Daily Meeting
  - 매일, 15분 정도 정해진 장소, 시간에 빠르고 간단하게 진행함(stand up meeting, 2-pizza meeting)
  - 어떤 일을 했는가, 어떤 일을 할 것인가 모여서 회의함.
  - 팀의 진척상황이나 이슈를 공유함
- Sprint review
  - Sprint 종료시 모든 Product Owner, Scrum master, team, 고객 등이 모여 피드백을 공유
  - 데모를 수행하며 요구 사항이 제대로 반영되었는지 피드백
  - Product Owner는 여기서 도출된 여러 지적, 개선 사항을 Product Backlog에 반영
- Sprint Retrospective
  - sprint 종료시, 또는 일정주기로 수행
  - 프로젝트 진행과정에서 좋았던 점, 문제, 개선점을 도출하여 개선
  - 이미 설정된 프로세스만으로 프로젝트를 진행하는 것이 아닌, 프로세스가 계속적으로 개선되도록 함
    → 변화하는 비즈니스 환경에 능동적 적응
  - sprint review는 제품의 개선을, sprint retrospective는 sprint, 프로젝트를 개선하기 위함
- Sprint
artifact(3)
- Product Backlog
  - 제품에 필요한 모든 것을 기술한 우선순위가 있는 업무 목록
  - 각각의 항목을 PBI(Product Backlog Item)라고 함
  - PBI의 종류
    - 기능
    - 비기능 : 성능 등등...
    - 오류 수정
    - 지식 슥듭 (spike)
  - user story
    - agile에서는 사용자의 요구사항을 User story 형태로 표현하는 경우가 많다.
    - Mike Cohn User story
      - who? what? why?
      - 간결하게 작성함
      - 대화를 위한 매개체의 역할
      - 가치가 너무 명확한 경우에는 세 요소(who, what, why)를 생략할수는 있지만, 가능한한 기술하는게 좋다
    - 사용자, 구매자에게 가치를 줄 수 있는 기능
    - 고객, 개발자 모두가 이해할 수 있도록 고객, 또는 product owner가 대신 작성
    - 3Cs
      - Card(카드) : 고객의 요구사항을 문서화하기 보단 표현하기 위한 것(대화의 초대)
      - Conversation(대화) : 대화를 통해 세부사항 구체화, 이해의 공유 촉진
      - Confirmation(테스트) : 스토리의 완료 여부 판단, acceptance criteria(인수 기준)을 통과해야 함
    - INVEST
      - Independent
        
        user stroy는 dependency를 최소화해야함
        
        dependency가 높으면 개발 우선순위 설정 작업이 복잡해짐
        
        dependency를 완전히 없애라는 것은 아님. 어쩔수 없는 상황이라면 어쩔수 없겠지만, 가능한 한 최소화하라는 뜻.
      - Negotiable(what)
        
        user stroy는 계약서가 아님
        
        상세한 사항은 협상 가능해야한다
        
        placeholder for details
        
        story를 개발하고 방식을 특정하면 협상 여지가 줄어든다
        
        ex) DB는 오라클을 무조건 사용해야한다. (mysql이나 좋은 오픈소스 많은데 왜??)
        
        회원 로그인시 얼굴 인식을 통해 로그인하여 구독 컨텐츠에 접근할 수 있으면 좋겠다 (왜 하필 얼굴 인식??)
        
        특정 방식을 사용해야만 하는 법률적 이유, 규격, 표준 등의 이유가 있다면 Negotiable하지 않아도 된다.
      - Valueable(why)
        
        가치를 주어야함
      - Estimable
        
        크기를 추정하여 필요한 노력과 비용을 추정할 수 있어야 한다.
        
        너무 큰 story(epic)은 분할
        
        정보가 없는 스토리는 spike작업을 한다.
      - Small(Size appropriately)
        
        스토리의 크기는 알맞은 크기가 되어야 한다
        
        just-in-time(sprint)
      - Testable
    - DEEP : product backlog가 가져야하는 4가지 특성
      - Detailed appropiately
        
        우선순위가 높을수록 잘 상세화
        
        낮을수록 상세화가 덜 됨
        → 적절한 상세화
      - Emergent(창발적, 발생적)
        
        환경 변화, 요구사항 변경등의 여러 이유로 product backlog는 고정되지 않고 계속해서 변함
        
        pbi들은 제거될 수 있고 추가될 수 있고 우선순위도 변경될 수 있다.
        
        agile 선언에서는 계획을 따르는 것이 아닌 변화에 반응하는 것에 더 가치를 둠
      - Estimated
        
        각 pbi는 크기(추정치)를 가짐
        
        우선순위가 높은 pbi 의 크기가 큼 → 더 분할할 필요가 있음
        → 우선순위가 높은 pbi는 가능한 높은 정확도를 가지도록 크기를 추정해야함
        → " 는 스프린트 내에서 충분히 개발 가능하도록 분할
        
        pbi의 크기 추정 → 스토리 포인트(pbi 크기 추정 단위), 시간을 사용하는 경우 많다
        
        스토리 포인트
        
        스토리를 구현하는데 필요한 상대적인 노력의 양과 개발 복잡도, 그리고 내재된 위험성등을 종합적으로 분석하여 나타낸 값
        
        추정에는 피보나치 수열을 많이 사용한다. 이때 수열의 값과 살짝 오차(예를 들면 스토리의 크기가 5보다는 살짝 크고 8보다는 약간 작다면?)가 있을 것 같아도 크게 상관 없다. 말 그대로 추정이니까
        
        plainning poker 게임으로 추정
        
        보통 추정치가 13이 넘어가는 경우, 분할할 필요가 있음
        
        추정치가 크다 → epic일 확률이 크다
      - Prioritized
        
        우선순위가 있어야 한다.
        
        MoSCow
        
        Must : 필수적인 기능. 없으면 제품으로서 존재가치가 상실되지만 일단 제공되면 제품의 가치를 상승하는데 더이상 기여를 하지 않음.
        
        Should have : 중요하고 유용한 기능이며 가능하다면 포함되었으면 하는 기능
        
        Could have : 만약 제공되면 만족도가 오를 바람직한 기능. 여유가 없으면 제공되지 않더라도 큰 문제는 없는 기능
        
        Wont have : 누락되어도 아무 상관이 없는 기능
        
        모든 pbi에 대해 우선순위하려고 노력하지 말라
- Sprint Backlog
  - 해당 sprint에서 해야하는 일을 담은 backlog
- Sprint Retrospective

릴리즈 계획

Iron triangle
- schedule, resource 고정하고 scope 조절
- 개발 범위는 스토리의 크기의 범위
  - 속도 20, 보정치 (0.6, 1.6)이 2달동안 2주짜리 sprint 4개 진행 가정
  - 만들어질 스토리 크기 = 20 * 0.6 * 4 = 48
  - 만들 수 있는 스토리 크기 = 20 * 1.6 * 4 = 128
- 해야할 일이 우리가 최소로 할 수 있는 양보다는 크고 최대한 할 수 있는 양보다는 작을 때?
  - 위험 감수하고 개발 진행 → 개발에서 얻은 지식을 바탕으로 진행 여부 결정
  - 릴리즈 날짜 연기, 개발 인력 추가
  - 기술적 채무(Technical debts, 시간에 쫓겨 제대로 설계하지 않거나, 테스팅을 충분히 하지 않을 때 발생) 소프트 웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용 선택. 기술적 채무가 쌓이면 더 커지기 전에 중간 중간에 채무를 갚아야 한다.
- 최대 할 수 있는 양보다도 많은 양을 해야할때
  - 개발 중단
  - 연기
  - 개발 인력 추가
  - 기술적 채무

스크럼 도구

스크럼 태스크 보드
- 매일 기록
- 각 스토리 별로 to-do, in progress, done 태스크를 기록
- 상태는 필요에 따라 더 추가 가능
Burn down chart
Burn up chart