SCRUM - Papéis

O ScrumMaster

O ScrumMaster é responsável por garantir que o Time de Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda o Time de Scrum e a organização a adotarem o Scrum. O ScrumMaster educa o Time de Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda o Time de Scrum a entender e usar auto-organização e multidisciplinaridade. O ScrumMaster também ajuda o Time de Scrum a fazer o seu melhor em um ambiente organizacional que pode ainda não ser otimizado para o desenvolvimento de produtos complexos.

Quando o ScrumMaster ajuda a realizar essas mudanças, isso é chamado de “remoção de impedimentos”. O papel de ScrumMaster é o de líder-servidor para o Time de Scrum.

O Product Owner

O Product Owner é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo.

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro conjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o contrário. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e recompensador ao mesmo tempo.

O Time

Times de desenvolvedores transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Times também são multidisciplinares: membros do Time devem possuir todo o conhecimento necessário para criar um incremento no trabalho. Membros do Time frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de dados. No entanto, o conhecimento que os membros do Time devem compartilhar - isto é, a habilidade de trabalhar um requisito e transformá-lo em um produto utilizável - tendem a ser mais importantes do que aqueles que eles não dividem.

As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a Times. Todos contribuem, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas.

Não há títulos em Times, e não há exceções a essa regra. Os Times também não contém subtimes dedicados a áreas particulares como testes ou análise de negócios. Times também são auto-organizáveis. Ninguém – nem mesmo o ScrumMaster – diz ao time como transformar o Product Backlog em incrementos de funcionalidades entregáveis. O Time descobre por si só. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo.

O tamanho ótimo para um Time é de sete pessoas, mais ou menos duas pessoas. Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade. Mais do que isso, o time poderá encontrar limitações de conhecimento durante partes da Sprint e não ser capaz de entregar uma parte pronta do produto. Se há mais do que nove membros, há simplesmente a necessidade de muita coordenação. Times grandes geram muita complexidade para que um processo empírico consiga gerenciar. No entanto, temos encontrado alguns Times bem-sucedidos que excederam os limites superior e inferior dessa faixa de tamanhos.

O Product Owner e o ScrumMaster não estão incluídos nessa conta, a menos que também sejam porcos, trabalhando em tarefas do Sprint Backlog. A composição do Time pode mudar ao final da Sprint. Toda vez que o Time muda, a produtividade ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição do Time.

Fonte: Scrum.org - http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf#view=