스크럼 마스터 체크리스트

스프린트 초기

  • 스프린트 계획회의 후 스프린트 정보 페이지를 만든다.
    • 위키 상황판에 여러분의 스크럼 페이지 링크를 추가하라.
    • 페이지를 출력하여 여러분 팀 앞 사람들이 지나다니는 벽에 붙여라.
  • 새로운 스프린트가 시작되었다는 것을 전원에게 공지하라. 메일에는 스프린트 목표와 스프린트 정보 페이지의 링크를 포함시켜라.
  • 스프린트 통계 문서를 갱신하라. 여러분의 추정 속도, 팀 크기, 스프린트 길이 등을 추가하라.

매일

  • 일일 스크럼 회의가 제때에 시작되고 마치도록 하라.
  • 스프린트 일정계획을 준수할 수 있는 만큼만 스프린트 백로그에서 스토리들을 추가/삭제하라.
  • 제품 책임자가 이러한 변경사항을 알게 하라.
  • 팀이 스프린트 백로그와 소멸차트를 항상 최신으로 유지하라.
  • 제품 책임자와 개발 총책임자에게 문제/장애 요소들이 발견되거나 해결되었다는 것을 보고하라.

스프린트 종료

  • 스프린트 데모를 실시하라.
  • 하루나 이틀 전에 데모가 있다는 것을 모든 사람들에게 알려라.
  • 전 팀원과 제품 책임자가 함께 스프린트 회고를 실시하라. 개발 총 책임자도 초대하라. 그가 팀이 얻은 교훈이 널리 전파하는 데 도움을 줄 수 있을 것이다.
  • 스프린트 통계 문서를 갱신하라. 실제 속도와 회고의 주요 내용들을 추가하라.

코드 가지치기

  • 메인 라인(혹은 줄기)을 일관된 상태로 엄격히 유지하라. 이것은 아무리 못해도 전체 코드가 컴파일되고 모든 단위 테스트를 통과해야만 한다는 것을 의미한다. 이렇게 하면 어떤 순간 에도 작동하는 릴리스를 만들어낼 수 있게 된다. 지속 빌드 시스템을 갖추어, 매일 저녁 코드를 빌드하고 테스트 환경에 자동으로 배포할 수 있다면 더 좋다.
  • 각 릴리스마다 태그(이름표)를 달라. 여러분이 제품이나 인수 테스트를 하기 위해 릴리스할 때마다, 메인 라인에 정확히 어떤 버전이 릴리스되었는지를 식별하는 버전 태그를 달아야 한다. 이것은 여러분이 나중에 언제든지 과거로 돌아가서 해당 지점에서 유지보수 가지(branch)를 만들 수 있다는 것을 의미한다.
  • 꼭 필요할 때만 가지를 새로 만들라. 경험상 좋은 방법은, 오직 해당 코드라인의 정책을 깨뜨리지 않고는 기존 코드라인을 사용할 수가 없을 때만 새로운 코드라인의 가지를 만드는 것이다. 확실치 않을 때는 가지를 만들지 말라. 왜냐구? 활성화된 각각의 가지는 관리와 복잡도 측면에 비용을 유발하기 때문이다.
  • 가지는 주로 생명주기를 달리 할 때 사용하라. 여러분이 각 스크럼 팀 별로 고유한 코드라인을 갖도록 결정할런지는 모르겠다. 하지만 동일한 코드라인에서 장기적인 변경작업과 단기적인 문제수정 작업을 함께 진행한다면, 여러분이 단기적인 문제수정 결과를 릴리스하기가 무척 힘들 것이다.
  • 자주 동기화하라. 여러분이 가지에서 작업한다면, 무언가 빌드가 될 때마다 메인 라인에 동기화하라. 매일 여러분이 일을 시작할 때는 메인 라인을 여러분 가지에 동기화하라. 이렇게 하면 다른 팀들에서 수정한 최신 내용이 여러분의 가지에 반영된다. 이런 방식이 여러분에게 머지 지옥(merge-hell)을 선사할지라도, 과거 손놓고 동기화가 될 때까지 기다리던 때보다 낫다는 사실을 받아들여라.

스크럼과 XP