BT

Mapeando os Papéis do Desenvolvimento de Software Tradicional para o Scrum

por Vikas Hazrati , traduzido por Flávia Castro de Oliveira em 19 Mar 2009 |

Muitas organizações que tem embarcado na adoção do caminho Ágil, tem que enfrentar o desafio do mapeamento dos papéis do desenvolvimento de software para os três papéis que o Scrum fornece. Os Papéis tradicionais como o Gerente de Produto, Gerente de Projeto, Analista de Negócios, Designer, DBA etc. não mapeiam os papéis definidos pelo Scrum. Em uma série de visões, Mike Cottmeyer tenta efetivamente mapear os papéis para o Scrum.

Mike sugeriu que os papéis relacionados ao 'Scrum Master' e ao 'Scrum Team' são relativamente fáceis de preencher.

O Gerente de Projeto poderá se encaixar no papel de um Scrum Master, entretanto, isso envolve uma mudança de mentalidade. De acordo com ele

Os Scrum Masters são facilitadores de processos e dão suporte para o time. Os Gerentes de Projeto são normalmente responsáveis por gerenciar o time e garantir que o tempo, custo e o escopo sejam equilibrados. [...]

Os Scrum Masters não tem autoridade sobre o time. Os Scrum Masters atuam mais como serventes do time... O Gerente de Projeto é mais como um chefe.

Do mesmo modo o 'Scrum Team' deve envolver todos que estão envolvidos no levantamento pesado de construção do produto.

O time de desenvolvimento, os caras da base de dados e o QA podem provavelmente ser trabalhados muito bem no papel de Membro do Time. Estas pessoas tem responsabilidade direta pelo design, construção e teste do código.

Uma vez que os papéis acima são mapeados há ainda muitos papéis como Analista de Negócios, Analistas de Sistemas, especialistas em Experiência de Usuários, etc, que precisam ser mapeados para os papéis do Scrum. De acordo com Mike, todos esses papéis poderiam potencialmente deslizar para o papel de um Product Owner.

O Product Owner é o Gerente de Projeto, o Analista de Negócios, o Designer do Sistema, o Arquiteto com Experiência de Usuário e cada grupo de Negócios... todos transformados em um. O papel é deve realmente ser onipotente e onipresente.

No entanto, Mike reconhece que este é um grande papel em si. Então, ele sugeriu que em vez de uma pessoa só preencher todos esses papéis, poderia ser um Time do Product Owner onde muitas pessoas coordenassem juntas. O time poderia incluir

  • Gerente de Produto - Trabalha com os stakeholders, identifica requerimentos e ajusta as prioridades.
  • Gerente de Projeto - Mantém uma visão geral de todos os objetivos. Gerencia recursos, investimentos, dependências externas etc.
  • Analista de Negócio - Responsável por documentar os critérios de aceitação e documentar as conversações em torno da estória de usuário. Principal ponto de contato para o esclarecimento dos requerimentos durante o sprint.
  • Designer - Prepara alguns screenshots, wireframes, etc.

Ele representa a configuração como esta figura abaixo

Product Owner Team

Assim, em vez de trabalhar isoladamente, o Product Owner interage com vários outros papéis e ajuda a trazer seus conhecimentos coletivos e expertise para definir o contexto correto e fornecer coordenação.

Assim, agrupando papéis eficientemente, os papeis tradicionais podem caber nos três papéis sugeridos pelo Scrum. A chave é mapeá-los no lugar correto onde eles adicionariam valor para o time inteiro.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Mapeando os Papéis do Desenvolvimento de Software Tradicional para o Scrum by Denis Petri

Na minha humilde opinião o Gerente de Projeto esta mais para Scrum Master do que para Product Owner. Mas mesmo assim, não sei o quanto é válido realizar este tipo de comparação pois o Scrum tem os seus papeis assim como o XP, o desenvolvimento em cascata e assim vai. Para uma pequena comparação até pode ser válido, mas acho que o Scrum deve ser adotado a sua totalidade, sem comparações.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT