scrum ch3 - andstudy/forge GitHub Wiki

3장 스크럼의 실천법

• 실천법 실천법 실천법

  • 스크럼을 실천하는 방법을 가장 빠른시간에 가장 쉽게 전달해보자.

• 어설프게 땜질하기 전에 먼저 경험을 통해서 익히도록 하자.

  • 스크럼이 왜, 어떻게 돌아가는지를 책이 아닌 경험으로 직접 습득하기 전에는 이 책에 있는 스크럼 실천법을 그대로 따라와 주길 바란다.

---

• Scrum pseudo code

    list 제품백로그;
    list 스프린트백로그;
    list 장애리스트;
    product 제품증분;
    
    func_scrum()
    {
       init(제품백로그);
    
       // 스프린트 시작
       while( 제품백로그의 최우선항목 )
       {
         스프린트백로그 = 스프린트 계획 회의(제품백로그의 최우선항목);
    
         // 일일 스크럼 시작
         for( day=1; day < 스프린트기간; day++ )
         {
            장애리스트 += 일일 스크럼회의();
            resolve(장애리스트);
    
            제품증분 += 개발(스프린트백로그);
            update(스프린트백로그);
          }
    
         스프린트 검토 회의(제품증분);
         update(제품백로그);
        }
    }
  

• 설명

  • 고객에 의해서나 기획파트에 의하여 초기 제품 백로그가 작성되고 사업상의 중요도에 따라 정렬된다.
  • @스프린트 시작 - 제품 백로그에 최우선 항목이 있을경우
  • 스프린트 계획 회의에서 제품 백로그의 우선순위가 가장 높은 항목을 이번 스프린트의 목표를 선정한다. 그리고 그 목표를 달성할수있는 자세한 스프린트 백로그를 작성한다.
  • @ 일일 스크럼 시작
  • 매일 아침 일일 스크럼회의를 열고 팀원들에게 인지부조화 현상을 유도하고 장애요소를 파악한다.
  • 스크럼 마스터는 장애리스트의 장애요소들을 제거한다.
  • 스크럼 팀원들은 각자 맡은 스프린트 백로그의 태스크를 개발하고 스프린트 백로그를 항상 최신의 정보를 가지고 있도록 유지한다.
  • 일일 스크럼을 스프린트 기간동안 수행한다.
  • 스프린트 기간이 끝나면 지금까지 모아진 제품증분을 가지고 스프린트 검토 회의를 연다.
  • 스프린트 검토 회의에서 고객과 관련사람들에게 제품증분을 보여주고 피드백을 받아서 제품백로그에 반영한다.
  • 제품 백로그에 아무것도 없을때까지 다시 스프린트를 시작한다.

출처

• 등장인물

  • 스크럼 마스터
  • 스크럼 팀원
  • 제품 책임자

• 산출물

  • 제품 백로그
  • 스프린트 백로그
  • 장애리스트

• 프로세스

  • 스프린트 계획 회의
  • 스프린트
  • 일일 스크럼 회의
  • 스프린트 검토 회의

---

• 등장인물

  • 스크럼 마스터

    • 새로운 유형의 관리자.
    • 제품책임자 선정 -> 스크럼팀 조직 -> 제품 백로그 제작 -> 스프린트 계획,진행
    • 단호한 행동, 결단력과 불굴의 의지, 공론화하고 주도하는것을 불편해하지 않는사람

  • 스크럼 팀

    • 역동적인 팀. 개인들이 모이면 역동성이라는강점과 편견,원한,논쟁등의 부정적인 측면이 생김
    • 팀의 크기. 7명이 이상적. 8명 이상의 인력이면 작은 팀들로 쪼개기해서 스크럼들의 스크럼 활용.
    • 팀의 구성. 매우 숙련된 엔지니어가 최소한 한명필요. 스크럼팀에는 직위가 없음. 코딩을 거부하는 사람을 멀리한다.
    • 팀의 책임과 권한. 어느누구도 자신들에게 무엇을 하라고 시키지 않는다.
    • 자기조직적. 팀 구성원들끼리 업무를 정의하고 분배하는 작업을 스스로 한다.
    • 작업 환경. 개방된 업무환경

  • 제품 책임자

    • 고객의 의견을 대변하고 비지니스적인 관점으로 제품 백로그를 작성하는 사람
    • 고객이 될수도 있고 내부인력이 될수도있음

• 산출물

  • 제품 백로그

    • 개발해야할 기능들을 사업상의 중요한 순서대로 정열한 리스트
    • 개발과정에서 끊임없이 진화. 요구사항은 결코 변화를 멈추지 않는다.
    • 백로그는 역동적이다. 제품이 존재하는한 제품 백로그는 사라지지 않는다.
    • 제품 책임자 한사람만이 제품 백로그를 관리한다.
    • 백로그를 개발하는데 필요한 노력 추정하기. 추정하다보면 점점 정확해짐

  • 스프린트 백로그

    • 이번 스프린트의 목표 달성을 위해 필요한 태스크들의 상세한 목록

  • 장애리스트

    • 일일 스크럼 회의에서 파악된 장애요소들. 스크럼 마스터가 해결해 주어야함.

• 프로세스

  • 스프린트 계획 회의

    • 스프린트 시작전에 1번씩 하는 회의
    • 고객,사용자,제품 책임자와 스크럼팀이 모여 이번 스프린트의 목표를 결정.
    • 스프린트 목표란 제품 백로그의 구현을 통해 달성되는 어떤 목표.
    • 스프린트 목표에 맞게 스프린트 백로그 정의하기

  • 스프린트

    • 한정된 기간. 30일. 스프린트 동안에는 개발에 집중
    • 스프린트 동안에는 팀원들을 자유롭게 풀어주어야함.
    • 일단 창조적인 분위기로 흐르게되면 창조성,생산성 급격히 상승
    • 일일 스크럼 회의와 스프린트 백로그 update 는 꼭 해야함.
    • 비정상적인 스프린트 중단도 가능. 바로 새로운 스프린트 시작.

  • 일일 스크럼 회의

    • 의사소통의 장. 매일아침 15분씩. 스크럼 마스터가 주관
    • 회의실 만들고 닭과 돼지를 모아서 (닭은 닥쳐라) 회의 시작하기
    • 일일스크럼의 형식. 요점만 간추려서 간결하게 말해야한다.
    1. 무엇을 했는가?
    2. 무엇을 하려고 하는가?
    3. 무엇이 방해되는가?
    • 장애요소 식별하기. 스크럼 마스터가 제거할 책임있음
    • 의사결정. 최악의 경우라도 아무것도 하지 않는것보다는 낫다.
    • 추가회의필요시 후속회의 개최하기.

  • 스프린트 검토

    • 고객들에게 이번 스프린트의 결과물을 보여주기.
    • 피드백을 받아서 제품 백로그 update
    • 발표형식은 중요하지않음. 중요한것은 개발한 제품.