Trabalhando com Scrum - Papéis

No post anterior, falei sobre desenvolvimento ágil e fiz uma introdução sobre o Scrum. No post de hoje, vou falar a respeito dos papéis definidos pelo framework.

Posts da série:

• Trabalhando com o Scrum - Introdução
• Trabalhando com o Scrum - Papéis
• Trabalhando com o Scrum - Cerimônias
• Trabalhando com o Scrum - Artefatos
• Trabalhando com o Scrum - Exemplo de uma Sprint

Time Scrum

De acordo com o Scrum Guide, o time Scrum é formado pelo Product Owner, pelo time de desenvolvimento e pelo Scrum Master. Ele é composto de pessoas com conhecimento e independência suficientes para definir o trabalho a ser feito e como ele deve ser feito. O time Scrum realiza as entregas do produto “Done” de forma iterativa e incremental, maximizando as oportunidades para feedbacks.

Essa definição inicial do Scrum Guide já apresenta alguns termos que você pode estar se perguntando o significado, então seguem as definições:

O processo de desenvolvimento de software ágil deve ser adaptável de modo incremental. Isso significa que deve ser possível alterar rapidamente o projeto e as condições técnicas (adaptação) e essas adaptações devem estar alinhadas com o feedback do cliente (incremental/adaptação apropriada). Nesse formato, temos incrementos de software (protótipos executáveis ou partes de um sistema operacional) que devem ser entregues em curtos períodos de tempo, de modo que as adaptações sigam o mesmo ritmo das mudanças. Essa abordagem iterativa capacita o cliente a avaliar o incremento de software regularmente, fornecer o feedback necessário para o equipe de software e influenciar adaptações feitas no processo para incluir o feedback adequadamente. ^[1]

Iterativo: processo onde o produto progride sucessivamente.

Incremental: o produto é liberado em versões, que vão evoluindo constantemente, ganhando novas funcionalidades. Cada versão é um incremento de produto.

Feedback: retorno do cliente a respeito do produto que está sendo desenvolvido. No processo iterativo, o feedback do cliente é considerado a cada nova versão liberada.

Done: Entregas incrementais de produto “Done” garantem que uma versão utilizável do produto sempre está disponível.

Traduzindo todas as definições, o time Scrum deve ser capaz de definir o produto que será desenvolvido e como ele será desenvolvido. Ele também deve ser capaz de liberar versões utilizáveis deste produto em curtos períodos de tempo, para que seja possível que o cliente possa avaliá-lo e dar feedbacks. Assim, o produto desenvolvido vai sendo ajustado a cada iteração e o resultado final é cada vez mais próximo do que o cliente deseja.

Para facilitar, daqui em diante vou me referir ao time Scrum somente como time.

Como citado no início, temos 3 papéis distintos dentro do time:

Product Owner

O Product Owner (PO) é o responsável por maximizar o valor do produto desenvolvido pelo time de desenvolvimento e é a única pessoa responsável por gerenciar o Product Backlog. De acordo com o Scrum Guide, a gestão do Product Backlog inclui:

• Expressar claramente os itens do Product Backlog;
• Ordenar os itens do Product Backlog de forma a atingir os objetivos;
• Otimizar o valor do trabalho desempenhado pelo time de desenvolvimento;
• Garantir que o Product Backlog é disponível e claro para todos, além de mostrar o trabalho futuro do time de desenvolvimento;
• Garantir que o time de desenvolvimento entende os itens do Product Backlog.

Se você nunca trabalhou com Scrum antes, talvez esteja se perguntando o que é o Product Backlog. Como estou seguindo a mesma estrutura do Scrum Guide, ele será explicado em detalhes no post sobre os artefatos do Scrum. Mas, por enquanto, é suficiente saber que ele tem todos os requisitos do produto.

O PO é responsável pelo trabalho realizado pelo time e é o único que pode definir os itens que estarão no Product Backlog. Por mais que diversas pessoas queiram fazer mudanças no produto, todas as alterações devem passar pelo PO, independente de quem solicitou a mudança. Por isso, é muito importante que a organização entenda o papel do PO e veja ele como o verdadeiro dono do produto. Assim, as suas decisões são respeitadas e todas as mudanças levarão em consideração o roadmap do produto e todo o trabalho que já foi feito.

O papel de PO é desempenhado por uma pessoa com conhecimento de negócio, que tem uma visão clara do produto sendo desenvolvido. Sendo ele a única fonte de requisitos para o time de desenvolvimento, é importante que o PO mantenha todas as decisões visíveis, com os itens do Product Backlog especificados e priorizados.

Existem diversas ferramentas para gerenciar projetos com Scrum e que apoiam o PO no gerenciamento do Product Backlog. Elas possuem áreas para criar, priorizar e organizar todos os itens. Além de ser uma forma de disponibilizar o Product Backlog para que todos os interessados possam acompanhar a sua evolução.

Apesar de não estar previsto para essa série de posts em específico, pretendo no futuro falar sobre uma destas ferramentas e mostrar como ela serve de apoio no dia a dia.

Time de desenvolvimento

O time de desenvolvimento é formado por profissionais que desenvolvem o incremento de produto “Done” a ser entregue no final de cada Sprint. Este incremento é a entrada de cada Review e apenas o time de desenvolvimento pode criar este incremento.

A Review é uma das cerimônias do Scrum que eu citei lá no primeiro post e ela vai ser descrita em mais detalhes no post sobre as cerimônias do Scrum. Mas em uma definição bem curta, a Review é a cerimônia onde vemos o trabalho que foi desenvolvido pelo time.

O time de desenvolvimento é estruturado e empoderado pela organização de forma que consiga organizar e gerenciar o próprio trabalho. Segundo o Scrum Guide, ele possui as seguintes características:

• É auto-organizado. Ninguém pode dizer ao time de desenvolvimento como que ele vai transformar o Product Backlog em incrementos de produto com potencial para ser entregue;
• É multifuncional, pois possui todas as habilidades necessárias como time para criar o incremento de produto;
• O Scrum não reconhece títulos para os membros do time, independente do trabalho feito pela pessoa;
• Cada integrante do time pode ter uma especialização, mas a responsabilidade do trabalho a ser desenvolvido é do time como um todo.

Em relação ao tamanho do time de desenvolvimento, o Scrum recomenda que seja pequeno o suficiente para se manter ágil e grande o suficiente para fazer um trabalho significativo dentro de uma Sprint. Esse número flutua entre 3 e 9 membros, sem contar o PO e o SM.

As especialidades das pessoas que vão compor o time de desenvolvimento dependem muito do produto que está sendo desenvolvido. Para um time pode fazer sentido que se tenha um analista de marketing, para outros faz sentido ter um UX designer. Tudo depende do produto que está sendo desenvolvido. Sendo assim, o time deve ser composto de pessoas com todas as habilidades suficientes para entregar versões de produto funcionais, de forma independente.

Apesar de o Scrum não reconhecer títulos para os integrantes do time de desenvolvimento, é normal que se fale a respeito da especialização de cada integrante do time de desenvolvimento. Tendo como exemplo um time de desenvolvimento que desenvolve software, precisamos de desenvolvedores back-end, front-end, testadores e assim por diante. Mas o que precisamos ter em mente é que todo o time de desenvolvimento é responsável pela entrega. Não ser o testador não significa que está isento da responsabilidade sobre a qualidade do produto.

Além da responsabilidade, temos que ter um time de desenvolvimento que saiba trabalhar junto, o que resulta em pessoas se apoiando, independentemente da tarefa a ser executada. Conforme o tempo vai passando e conseguimos criar um senso de time, baseado nos valores do Scrum, todos se apoiam e trabalham para atingir os objetivos de forma natural.

Scrum Master

O Scrum Master (SM) é o responsável por promover e suportar o Scrum como definido no Scrum Guide. Ele é um líder servidor para o time Scrum e ajuda a todos os que interagem com o time a entender quais interações são úteis e quais não são.

Apesar dessa definição inicial, desempenho o meu trabalho como Scrum Master com algumas alterações em relação que prega o Scrum Guide. Sei que este desvio não é aceito oficialmente, mas a minha experiência na prática sempre me trouxe oportunidades de ajustes e acredito que não devemos impedir mudanças que serão benéficas. Dito isso, sigo com a definição do Scrum Guide nesta seção e falo mais sobre essas diferenças no post sobre as cerimônias.

O Scrum Guide define 3 visões diferentes do Scrum Master e como o trabalho dele apoia o PO, o time de desenvolvimento e a organização:

O Scrum Master trabalhando com o Product Owner

O Scrum Master apoia o Product Owner de várias maneiras, incluindo:

• Garantir que os objetivos, escopo e domínio do produto são compreendidos por todos do time da melhor maneira possível;
• Encontrar técnicas para um gerenciamento efetivo do Product Backlog;
• Ajudar o time a entender a necessidade de itens claros e concisos no Product Backlog;
• Compreender o planejamento de produtos em um ambiente empírico;
• Garantir que o PO sabe como organizar o Product Backlog de forma a maximizar o valor;
• Compreender e praticar a agilidade;
• Facilitar as cerimônias do Scrum conforme solicitado ou necessário.

Scrum Master trabalhando com o time de desenvolvimento

O Scrum Master apoia o time de desenvolvimento de várias maneiras, incluindo:

• Instruir o time de desenvolvimento na auto-organização e na interdisciplinaridade;
• Ajudar o time de desenvolvimento a criar produtos de valor elevado;
• Remover impedimentos para o progresso do time de desenvolvimento;
• Facilitar as cerimônias do Scrum conforme solicitado ou necessário;
• Instruir o time de desenvolvimento em ambientes organizacionais onde o Scrum ainda não foi totalmente adotado ou compreendido.

Scrum Master trabalhando com a organização

O Scrum Master apoia a organização de várias maneiras, incluindo:

• Liderar e instruir a organização na adoção do Scrum;
• Planejar a implementação do Scrum na organização;
• Apoiar os colaboradores e os stakeholders a compreender e aceitar o Scrum e o desenvolvimento empírico de produtos;
• Promover mudanças que aumentem a produtividade do time;
• Trabalhar com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.

Note que o Scrum Master possui diversas atribuições e só pode desempenhar o seu papel de forma saudável se estiver trabalhando com times no tamanho recomendado e sem diversos times sob a sua responsabilidade. Apesar de ser possível assumir vários times, não vejo a possibilidade de se fazer todo o trabalho esperado com qualidade quando um limite não é imposto. O Scrum Master deve ser uma pessoa organizada e disponível, que esteja alinhada com os valores do Scrum. Isso é muito importante, considerando que ele é o responsável por disseminar o framework e por garantir que está sendo aplicado corretamente.

Diversas ferramentas apoiam no trabalho do Scrum Master, inclusive já comentei sobre uma delas aqui. As ferramentas que apoiam no trabalho do PO também servem para a organização do trabalho do SM, principalmente na facilitação de cerimônias remotas. Sobre facilitação de reuniões remotas, existem dois posts no blog com dicas a respeito. Se você vai atuar como SM e, assim como eu, gosta de assumir a facilitação das reuniões, acredito que estas dicas irão te ajudar a extrair o maior valor possível em cada cerimônia.

Esta foi a segunda parte da série a respeito do Scrum. Agora você já conhece os papéis definidos pelo framework e já vai conseguir entender melhor a participação de cada um deles nas cerimônias que serão descritas no próximo post.

Aguardo os seus comentários e até a próxima!

Copiar link