Ícone do LinkedIn Ícone do RSS

17 Ago 2020 | 9 minutos • Agilidade

Trabalhando com Scrum - Papéis

Post 2/5

Ingrid Machado

Ingrid Machado

Engenheira de computação, especialista em engenharia de software. Autora deste querido blog.

Image de capa do post 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:

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:

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:

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:

Scrum Master trabalhando com o time de desenvolvimento

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

Scrum Master trabalhando com a organização

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

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!


  1. Referência: PRESSMAN, Roger S.; MAXIM, Bruce R.. Engenharia de software: uma abordagem profissional. 8 ed. ↩︎

O link do post foi copiado com sucesso!

Mais conteúdos de Ingrid Machado

Imagem de capa do post Iniciando com um novo time

25 Fev 2022 • Agilidade

Iniciando com um novo time

Quem acompanha o que eu escrevo já deve ter percebido o quanto eu gosto de listas e roteiros para encarar diversas situações. Eu até recebi um feedback sobre como eu me saio bem quando eu tenho um ...

6 minutos

Imagem de capa do post Retrospectiva

18 Fev 2022 • Agilidade

Retrospectiva

Trabalhar por um período indefinido no mesmo time exige que se mantenha a melhoria contínua como prática. De outra forma, a manutenção do trabalho de qualidade é inviável. Pensando nisso, a agilida...

6 minutos

Imagem de capa do post Modelo Spotify

28 Jan 2022 • Agilidade

Modelo Spotify

Existem vários artigos sobre o modelo Spotify. Inclusive, existem diversos artigos falando que o modelo Spotify não é mais usado pelo próprio Spotify. Mesmo assim, acredito que é importante saber d...

3 minutos

linkedin icon
LINKEDIN
Twitter icon
TWITTER
RSS icon
RSS

Ingrid Machado © 2019 - 2022

• Ingrid Machado © 2019 - 2022

• Layout por Victoria Facundes • Desenvolvido por Cristhian Rodrigues

VOLTAR AO TOPO

voltar para o topo