Artigo - Erros e acertos na aplicação de Scrum em um ambiente de engenharia – Parte 2
O Planning Poker é a forma mais popular de fazer estimativas dentro das metodologias ágeis. Ele pode ser "jogado" utilizando diferentes parâmetros, mas a forma mais clássica usa uma sequência de Fibonacci adaptada: a vantagem desse método vem do fato de que a diferença entre os números aumenta à medida que são utilizados valores maiores na sequência (a diferença entre 8 e 13 é 5, maior que a diferença entre 1 e 2, que é 1). Comisso, é possível mapear de modo mais adequado o aumento da quantidade de indefinições que ocorre quando estimamos tarefas grandes demais.
Conforme já havíamos relatado na primeira parte desse artigo, passamos a estimar tarefas por esforço, que era medido em pontos.Tomamos uma tarefa bem conhecida de todos e atribuímos a ela o valor 1, justamente para servir de parâmetro de comparação. Com isso, as tarefas seguintes são estimadas de forma relativa àquela escolhida como base.
Em outros casos, a apresentação de uma tarefa levava os membros a colaborarem entre si: ao falar de uma instalação para a qual seria necessário um levantamento, por exemplo, descobria-se que esse levantamento já havia sido feito para outra atividade, o que levava a reduzir o esforço inicialmente estimado. A equipe assim passou a trocar dados, informações e dicas de forma que dificilmente aconteceria se não houvesse o Planning Poker, oque contribuiu para reduzir o tempo e o esforço de algumas atividades.
No início, colocamos tudo que havia a ser feito no backlog, o que gerou um número gigantesco de itens, e passamos a trazer os itens para os Sprints de cada semana. Isso, no entanto, não funcionou muito bem: o grande número de itens tornava o processo confuso, o burndown (percentual do projeto que falta para ser feito) parecia não evoluir como esperávamos, e nos vimos fazendo documentos iguais para áreas diferentes(fazendo por exemplo diagramas de interligação de acionamentos idênticos para áreas diferentes como britagem, metalúrgica e outras). Diante disso, decidimos mudar a forma de fazer, já que percebemos que não estávamos reaproveitando o trabalho já desenvolvido.
Passamos a criar apenas os itens macro, como"diagramas de interligação", por exemplo, e, em vez de criarmos vários subitens para todos os pequenos diagramas e diversas atividades que precisavam ser feitas, o que tornaria a coisa confusa, criávamos apenas os itens específicos para aquela Sprint, o que estava sendo trabalhado no momento e o que viria a ser votado no Planning Poker para ser trabalhado na próxima sprint. As coisas passaram a fluir melhor, com as tarefas mais claras e maior engajamento da equipe.
O que aconteceu foi que, à medida que a obra foi sendo desenvolvida com o Planning Poker, a adaptação e o Refinamento do Backlog, esse último passou a não ser mais tão necessário, já que os próprios membros da equipe passaram a vislumbrar as atividades a serem realizadas na próxima Sprint. Poucas tarefas passavam por questionamentos e discussões durante as reuniões de Planejamento, sem reduzir a assertividade dos membros da equipe com relação às estimativas das tarefas a ser realizadas. Ou seja, a equipe se tornava cada vez mais autônoma e menos dependente tanto do Scrum Master comodo próprio Product Owner.
A longo prazo, a equipe assim se viu mais unida e se aproximou de um processo de autogestão, o que foi excelente para reduzir o estresse e preservar as relações humanas, já que não havia necessidade do líder procurar cada um e lembrá-los de suas tarefas dia após dia, o que eventualmente levava a mal-entendidos, esquecimentos e falhas. O fato de cada um ter em mente o que era necessário fazer permitiu a executar a obra de maneira mais dinâmica,entregando mais valor em menos tempo. Esse foi sem dúvida um dos maiores ganhos observados pelo uso do Scrum.