ScrumDevelopmentProcess

KenSchwaber가 OOPSLA 95에서 발표한 페이퍼. 이 페이퍼를 통해 SCRUM이 소개되었다.

초기 버전의 SCRUM에서는, 스크럼 마스터, 프로덕트 오너 등의 역할이 미리 규정되지 않았다는 것이 특이하다.

Overview

시스템 개발의 새 격언은 이런 것들이다:

경쟁력 있는 개인들로 이루어진 작은 팀들이, 제약된 공간에서 그들 스스로 소유하고 제어하면서 일하는데, 큰 개발 조직보다 훨씬 퍼포먼스가 좋을 것이다.
객체 지향(object-oriented) 환경에서의 제품 개발은 매우 유연하고 적응적인 개발 프로세스를 필요로 한다.

이 페이퍼에서 우리는 이러한 격언을 고려한 개발에의 새로운 접근법을 개괄할 것이다. 이 접근법은 Scrum 방법론이라고 부른다. 럭비 - 공을 잡고 그것을 앞으로 이동시키는 책임이 있는 그룹 - 에서의 스크럼을 본땄다.

Scrum은 관리에 연관이 있다. 기존에 존재하는 제품의 향상과 유지에, 새로운 관리 기법과 위에 나열한 격언의 장점을 취하면서. Scrum은 시스템 개발 노력의 신규 혹은 리엔지니어링에는 연관이 없다.

제품 출시는 아래의 변수들에 기반하여 계획된다:

개발 프로젝트에 대한 이 변수들의 효과는 계속 변화하는 출시 타이밍과 내용에 나타나 있다. 성공적인 개발 방법론은 반드시 이 변수들을 고려해야 한다.

전통적인 개발 방법론들은 위의 변수들에 대해 개선 사이클의 시작 시점에만 대응하도록 설계되었다. 보헴의 나선형 방법론과 그 변종들처럼 조금 더 최근의 접근법들도 변화하는 요구사항에 대응하는 능력에 있어서는 여전히 제한이 많다.

반면에 Scrum 방법론은 꽤 유연하다. 그것은 제품 출시 계획을 위한 관리된 메커니즘을 제공하고 프로젝트가 진행됨에 따라 위의 변수들을 관리한다. 이것은 조직이 프로젝트를 어느 시점에서건 변수에 따라 적절하게 출시할 수 있도록 한다.

객체 지향 기술은 Scrum 방법론을 위한 기반을 제공한다. 객체, 또는 제품 기능(product feature)은 분리되고 관리 가능한 환경을 제공한다. 절차적인 코드는, 그것과 얽혀있는 많은 인터페이스들과 함께, Scrum 방법론에는 적절하지 않다.

Scrum 방법론의 요소들은:

백로그: 현재 제품 릴리즈에는 충분히 해결되지 않는 제품 기능 요구사항들. 버그들, 결함들, 고객 요청 개선사항, 경쟁 제품 기능들, 경쟁 edge 기능, 기술적 업그레이드들이 백로그 아이템이다.
출시/개선: backlog items that at that point in time represent a viable release based on the variables of requirements, time, quality, and competition.
패킷들: 백로그 아이템을 신규 릴리즈에 구현하기 위해 변경되어야 할 제품 컴포넌트나 객체들
스크럼 팀들: 백로그 아이템들을 신규 릴리즈에 구현할 책임을 가진 여러 개인들로 구성된 팀.
변화들(변경점들): 백로그 아이템을 구현하기 위해 패킷에 발생해야 하는 변화들
문제들: 변경점을 구현하기 위해서는 반드시 해결되어야 할, 발생한 문제들.
이슈들: 패킷이나 변화, 문제들로 분류되지 않은 프로젝트 전반, 그리고 프로젝트 이슈들.