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

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

Seções

Processos e Práticas

Tópicos

Adoção de Agile ,

Agile nas empresas ,

Adoção ,

Scrum ,

Agile ,

Papéis

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

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.

1. Voltar ao topo

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

   por 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.

   Responder

• Mais antigos >