Sorry, this entry is only available in Português.
Olá pessoal, este post será o quarto da série sobre como acompanhar projetos pessoais com o Scrum.
Nos posts anteriores abordei o uso das Sprints, as reuniões de revisão e retrospectiva e também as reuniões diárias. Havia pensado em continuar a série escrevendo sobre as reuniões de planejamento, mas antes de abordar esse tema achei melhor falar um pouco sobre os papéis do Scrum.
No Scrum há 3 papéis a serem desempenhados: Scrum Master, Equipe de desenvolvimento e Product Owner (P.O.).
Como o próprio nome já diz, o P.O. é o dono do produto. Ele quem faz a ponte entre cliente e desenvolvedores. É função dele entender o que o cliente quer e com base nisso definir o que vai ser feito, quando será feito e quando será entregue.
O Scrum Master é o responsável por manter a casa em ordem. Ele que organiza as reuniões, remove obstáculos, garante que o processo corra bem, e atua junto a equipe para mantê-la motivada e produtiva.
Já a equipe de desenvolvimento, além de, é claro, ser responsável pela implementação do produto, deve ser auto-organizada e tem autonomia para decidir como o trabalho será feito.
No post que temos no FAQ Scrum (Quais são os papéis do Scrum) explica em maior detalhe esses papéis. Já esse outro post aborda as interseções entre os papéis.
O Scrum recomenda que os papéis não sejam acumulados por uma mesma pessoa, porém no caso do meu projeto pessoal tive que acumular não só esses 3 papéis, como também o papel do cliente.
De início, achei que seria tranquilo lidar com essa situação, até porque isso facilitaria muito para marcar reuniões :P, mas brincadeiras a parte, aos poucos fui percebendo que era preciso tomar alguns cuidados.
Cada um desses papéis tem uma função bem definida e sobretudo uma forma de pensar e de ver o problema. Com isso, ao acumular papéis é muito importante conseguir analisar a situação pelo ponto de vista de cada um deles.
No caso do meu projeto pessoal, por duas Sprints consecutivas não consegui entregar o planejado (ler um livro por Sprint) e percebi que era preciso realizar algumas mudanças… Para não ir contra alguns princípios do Scrum, precisei analisar a situação pelo ponto de vista de cada um desses papéis.
Do ponto de vista da equipe, percebi que havia um grave problema de motivação e uma dificuldade em superar obstáculos. Como Scrum Master, percebi que tínhamos uma meta muito rígida e que para pensar em mudanças precisava do P.O e provavelmente do Cliente. Como P.O. sabia que qualquer mudança na meta deveria continuar garantindo a entrega de um determinado volume de leitura periodicamente. Por fim, como cliente, percebi que essa meta poderia ser modificada, contando que o equivalente a um livro fosse lido em cada Sprint.
Com essa nova definição do escopo definida pelo cliente, agindo novamente no papel do P.O. percebi que caso as metas das Sprints fossem capítulos, poderia “entregar” capítulos de livros diferentes, desde que nunca entregasse capítulos de um mesmo livro fora de ordem. Como Scrum Master me comprometi a avaliar essa mudança no dia-a-dia da equipe, de modo a ter certeza que isso havia resolvido o problema. Por fim, como equipe e Scrum Master decidi evitar colocar mais de um capitulo de um livro novo em uma Sprint, de modo a poder conhecer um pouco de cada livro antes de entrar de cabeça nele. Dessa forma evitaria comprometer a Sprint com o livro que poderia ser de difícil leitura, e seria mais fácil prever quantos capítulos de cada livro conseguiria ler na Sprint seguinte.
Se fossemos analisar cada etapa dessa situação com a ótica de cada papel em uma equipe real e sem sobreposição de papeis, podemos EXEMPLIFICAR a situação com os seguintes acontecimentos:
- Na reunião de revisão o P.O reclama que a equipe não está conseguindo entregar o prometido.
- Na reunião de retrospectiva o Scrum Master e a equipe tentam entender porque o trabalho não está evoluindo bem e percebem que a falta de empatia com um livro é um impedimento para a leitura.
- Ao levar essa questão para o P.O., esse conversa com o cliente para entender porque é importante que seja lido um livro por Sprint .
- O cliente reporta que o objetivo do projeto é aumentar o ritmo de leitura e que deseja ter o equivalente a 12 livros lidos em 1 ano.
- O P.O. percebe que essa meta fixa de 1 livro por Sprint pode ser modificada, e sugere ao cliente que a meta seja uma quantidade de capítulos equivalente a um livro.
- Após o cliente aceitar, o P.O. passa então a priorizar capítulos ou partes de livros a serem lidos.
- Uma vez priorizado os capítulos, a equipe, Scrum Master e P.O. planejam juntos quais capítulos de quais livros devem entrar na Sprint, obedecendo a regra de nunca entregar capítulos de um mesmo livro fora de ordem.
- Scrum Master se compromete a acompanhar e avaliar a eficiência dessas mudanças.
- Scrum Master e Equipe alertam ao P.O. que é melhor evitar colocar muitos capítulos de um livro novo na Sprint.
- Scrum Master e Equipe definem que caso volte a ocorrer o problema de empatia com um determinado capítulo, a equipe tem agora liberdade para seguir a leitura com outro capítulo de um livro diferente, que esteja na Sprint ou se necessário incluir o próximo capítulo priorizado na Sprint.
Espero que com esse exemplo tenha ficado mais claro como atua cada um desses papéis. É importante perceber que embora tenham pontos de vistas diferentes e que cada um tenha que defender o seu lado, todos trabalham juntos, buscando soluções e visando que o projeto ocorra da melhor maneira possível.
Agora que já conhecemos melhor os papéis definidos pelo Scrum, no próximo post dessa série abordarei as reuniões de planejamento. Até lá!
Abaixo estão listados todos os posts dessa série:
-440x264.jpg?x13947)
