스크럼 마스터가 작업을 할당 할 수 있습니까?

우리는 프로젝트에서 스크럼을 따르고 있습니다. 스크럼 마스터가 우리에게 작업을 할당하는 대부분의 시간을 봅니다. 그러나 나는 많은 스크럼 서적에서 스크럼이 다른 방식으로 작동하고 ( '풀 (pull)'접근법) 팀 구성원이 작업이나 기능을 선택한다고 읽었습니다. 스크럼 마스터가 작업을 올바른 접근 방식으로 할당합니까? 아니면 민첩한 이데올로기에 반대합니까?

Scrum Wikipedia Article에 따르면 , 스프린트 작업은 ScrumMaster에 의해 할당되지 않습니다 :

스프린트 백 로그의 작업은 할당되지 않습니다. 대신, 설정된 우선 순위 및 팀 구성원 기술에 따라 필요에 따라 팀 구성원이 태스크를 등록합니다. 이를 통해 팀 자체 구성 및 개발자 구매를 촉진합니다.

또한 ScrumMaster의 정의는 사람들이 Scrum 프로세스의 규칙을 준수하도록하는 책임을진다는 것입니다.

ScrumMaster Scrum 프로세스를 책임지고 올바른 사용법을 사용하고 그 이점을 극대화하는 사람.

ScrumMaster는 단순하고 간단한 작업을 할당하지 않습니다. 팀은 자체 구성하고 팀의 결정에 따라 누가 결정을 내릴지 결정합니다.

이것이 진정한 스크럼입니다. 그러나 많은 조직에서 이러한 변형을 사용할 수 있습니다.

그것이 작동하는 방식이지만 이론적으로 잘 작동하는 모든 것과 마찬가지로 항상 실제로 작동하지는 않습니다.

외부로부터의 의존성, 고객 요구 및 드라이버가 있습니다. 모두가 작업하고 싶은 멋진 위젯에서 작업하기 전에해야 할 일이 있습니다.

내부에서 운전하는 기본 개발자 능력이 있습니다. 어떤 것은 힘들고 어떤 사람들은 더 나아집니다. 물론, 무한한 타임 라인 내에서 일할 때 나는 그것을 알아낼 수 있습니다. 그러나 어떤 일을 끝내야 할 때 가장 빨리 그 일을하도록 가장 잘 배치 된 사람에게 배정하는 것이 직업을 얻는 사람입니다.

그런 다음 지나치게 통제하는 Scrum Master 및 / 또는 자신의 신발을 듣지 않고 자신의 신발을 묶을 수없는 개발자와 같은 성격 문제가 있습니다. 예를 들어, 우리 팀은 둘 다 가지고 있습니다. 이러한 경우 스크럼에 대한이 작은 사실을 모든 사람이 무시하는 것이 더 좋습니다.

즉, 프로세스가 지시하기 때문에 그렇게하지 마십시오. 작동합니다. 나머지를 조이십시오.

물론 인간 존재의 또 다른 기본 사실도 있습니다. ... 어쩌면 스크럼 마스터가 실제로 누구인지조차 모를 수도 있습니다. 아마 그 제목을 가진 사람이 아닐 수도 있습니다. 어쩌면 당신은 하나도 없을 것입니다.

못.

스크럼은 이것에 대해 완전히 명확합니다. 개발팀은 그룹으로서 스프린트 백 로그의 아이템을 완성 할 책임이 있습니다. 그들은 또한 개발을 완료하는 방법을 완전히 통제하고 있으며 아무도 그 방법을 말할 수 없습니다.

코치로서 스크럼 마스터는 어떤 이유로 든 팀이 스프린트 목표를 놓칠 위험에 처했을 때이를 지적하는 역할을합니다. 그러나 그는 그들에게 어떻게 대처할 것인지 알아 내고 나서 나가라고 요청해야합니다.

또 다른 방법은 팀이 스프린트를 완료하게하고 결과 부족에 대한 책임을지게 한 다음 스프린트 회고에서 논의하게하는 것입니다.

다른 이념과 마찬가지로, 규칙 책을 버려야하거나 신중하게 무시해야 할 때가 있습니다.

적절한 것으로 판단하십시오. 누군가가 사실상의 프로젝트 관리자가되거나 사람들을 괴롭히는 것에 대해 조심하십시오.

받아쓰기에 의한 작업 할당 (X는해야 함)과 토론 및 동의에 의한 할당에는 큰 차이가 있습니다. 때로는 계약이 미지근한 것일 수 있습니다.

그런 다음 팀이 지시해야 할 수도 있습니다.

그러나 나는 당신이 흔들림이나 판단의 여지가없는 서한까지 그 과정을 따라야한다고 주장하는 모든 과정에 대해 걱정하고 있습니다. 그러한 과정은 사고를 대신합니다.

내 생각에 scummaster는 그렇게해서는 안되며 팀 구성원은 직접 작업을 수행해야합니다. 우리 팀의 경우와 같이 scrummaster가 관리 만 수행하는 경우 아무런 문제가 없습니다. 우리의 스크럼 마스터는 종이 스크럼 보드가 Excel 파일과 동기화 상태를 유지하도록합니다. 스크럼 마스터의 역할은 방해받지 않고 작업을 수행 할 수 있도록 도와주는 것입니다. 이것이 우리가 일하는 방식입니다. 스크럼 마스터가 왜 이런 일을하는지 아십니까? 그는 프로젝트 관리자가 쓸데없는 것을 두려워합니까? 그는 팀이 스스로 작업을 수행하지 않을까 두려워하고 있습니까? 회고하는 동안 이것을 논의하는 것이 좋습니다.

저는 두 가지 유형의 환경 (작업을 개인에게 푸시하고 개인이 작업을 가져 오는 곳)에서 스크럼 마스터였습니다.

푸시 팀은 개발 리소스를 서로 바꿔 놓을 수 없었습니다. Windows 클라이언트 작업은 Windows 개발자로, 웹 작업은 웹 개발자로 이동해야했습니다. 따라서 세션을 계획하는 동안 작업을 리소스로 푸시 할 수있었습니다. 또한 추진을 중단 할시기를 알기 위해 개별 용량 계획을 세울 수도있었습니다.

pull 방법은 모든 리소스가 어떤 작업을 수행 할 수있는 팀에서 잘 작동했습니다. 그러나 계획 세션 동안 개별 용량 계획을 수행 할 수 없었으며, 충분한 속도가 충분한 지 알기 위해 평균 속도에 의존해야했습니다. (속도에 대한 좋은 아이디어를 얻기 전에 ~ 3-4 스프린트가 소요되었습니다).

Push vs. Pull의 장단점을 설명 하는 흥미로운 기사 를 발견했습니다 .