2. 스크럼 준비

정의

프로젝트 제어에는 크게 2가지 접근법이 있다. 명시적 접근과 경험적 접근이다. 명시적 접근은 특정 프로세스를 완벽이 정의 할 수 있다고 가정한다. 동일한 인풋을 주면 매번 동일 한 결과를 도출한다고 정의한다. 하지만 경험적 접근법은 특정 프로세스를 불완전 하게 정의 된다고 가정한다. 동일한 인풋을 주어도 매번 다른 결과가 도출 된다고 가정한다. 불완전한 가정에서 프로세스를 통제하기 위해서는 자주 검사 하고 또 재정의 해서 상황에 맞춰 예측 결과 값을 수정 해야 한다.

소프트웨어 산업은 예전 제조업의 명시적 접근법을 사용해왔다. 하지만 소프트웨어 개발 자체가 경험적이기 때문에 명시적 접근은 실패 할 수 밖에 없다. 지금부터 프로세스가 경험적이라는 가정하에 새로운 접근법을 사용 해보자.

스크럼에서는 정해진 역활이나 개인에게 할당된 과업도 없다. 어떻게 일을 처리하고 제품 증분을 만드는지 주목해야한다. 지시를 기다리는 수동적 개인 집합에서 자기 조직화를 통해 어떻게 주도적으로 행동하는 팀으로 탈퇴 되어 가는지 관찰 해야 한다. 첫 스프린트가 끝날 즈음에 팀은 새로운 가치관을 습득하고 기존과 다르게 행동할 것이다.

예제

소란스러운 프로젝트

A 라는 프로젝트를 4개월동안 진행 했는대 팀만 만들어 졌을뿐 예산도 없고 필요한 인력도 더이상 뽑을수 없는 상태 였습니다. 4개월동안 결과 물이 없기때문에 경영진에게서 더 지원을 받기 힘들어지고 있었습니다.

가능한 것을 하라(the art of the possible)

추가 자원 없이 현재의 자원으로 가능한 문제를 목표로 잡고 스프린트를 시작했습니다. 스프린트 목표: A라는 프로젝트의 요구 명세를 정의하고 프로토 타이핑해서 가능한 부분만 구현했습니다.

자기 조직화

여러 문제 점이 있었지만 팀원들이 목표를 같이 정하고 중요성을 인지 했기 때문에 같이 문제를 풀었습니다.

경험적으로 반응하라.

프로토 타입을 구현 함에 있어 처음 계획하지 못한 문제점이 발견되었고 전체 구현으로 했을 경우 시간의 부족함을 느겼을 것입니다. 목표를 정의 할 때 가능하게 정의하는것이 중요합니다.

하루단위의 가시성 부여

스프린트 가운대 개발 팀원에게 다른 채널로 구현 명령이 들어온적이있습니다. 스크럼 마스터가 해당 채널을 설득해서 팀원이 스프린트 목표가 아닌 일에 자원을 소모하지 않게 했습니다.

점진적인 제품 인도

일부이지만 개발 가능한 부분을 구현했고 제공했다 결과적으로 권한과 예산을 빠르게 받을수 있었습니다.

알림

이 페이지는 원본 을 개인용으로 정리했습니다.