Skip to content

scrum ch3

Jump to bottom
Jongbin Oh edited this page Jun 2, 2013 · 1 revision

3장 스크럼의 실천법

  • 실천법 실천법 실천법

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

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

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

  • Scrum pseudo code

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

  • 설명

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

3

출처

  • 등장인물

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

  • 산출물

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

  • 프로세스

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

  • 등장인물

    • 스크럼 마스터

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

    • 스크럼 팀

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

    • 제품 책임자

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

  • 산출물

    • 제품 백로그

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

    • 스프린트 백로그

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

    • 장애리스트

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

  • 프로세스

    • 스프린트 계획 회의

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

    • 스프린트

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

    • 일일 스크럼 회의

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

    • 스프린트 검토

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