Por maiores que sejam as vantagens em utilizar metodologia ágil, alguns contextos necessitam atenção especial para certos detalhes e podem requerer algumas adaptações na metodologia. É o caso da engenharia. E, ainda que a bibliografia sobre Scrum, DevOps e outros métodos cresça a cada dia, materiais relatando eventuais problemas e as formas de evita-los ainda são quase inexistentes.

Em minha experiência atuando como Scrum Master em uma equipe de engenheiros pela ihm Stefanini, o sucesso veio, mas em meio a muitos problemas, tentativas de soluções e consequentes aprendizados. Na primeira parte deste artigo, que você pode ler aqui, abordamos os principais problemas enfrentados, como a dificuldade em fazer estimativas e as indefinições nas tarefas e processos. Nesta segunda parte, falaremos das ferramentas e recursos que podem ajudar em sua solução.

Planning Poker

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.

Cada membro da equipe recebe um baralho com cartas com os valores da sequência adaptada (1, 2, 3, 5, 8, 13, 20, 40, 100). Durante a reunião de Planejamento da Sprint, as tarefas escalonadas são discutidas individualmente e cada membro da equipe dá uma estimativa utilizando uma das cartas, que devem ser jogadas simultaneamente para que não haja influência de uns sobre os outros. Feito isso, os membros que apresentaram a maior e a menor estimativa justificam suas opções e todos votam novamente, até que haja consenso, não sendo, portanto, uma mera questão de maioria.

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.

Posteriormente, modificamos os valores base escolhendo tarefas bem conhecidas para representar o 2 e o 5, para dar uma capacidade de comparação um pouco mais extensa. É mais fácil estimar um 8 ou um 13 comparando com o 5 ao invés do 1.

Utilizando o Planning Poker nos deparamos com diversas situações. A discussão em grupo acabava trazendo aspectos não pensados inicialmente, e mesmo dados que não haviam sido levantados antes. Todos opinavam sobre a tarefa, até os que não a executariam, o que permitia visitar o problema sob outras perspectivas. O que ocorria era que frequentemente as pessoas que traziam uma determinada tarefa eram surpreendidas, com seu valor se revelando ora acima ora abaixo do que haviam sido estimadas por elas inicialmente.

Nos casos em que a tarefa se mostrava mais complexa que o previsto, essa nova avaliação levava a repensar se ela deveria mesmo ser trazida para essa Sprint, assim como seu escopo e suas indefinições. Em muitos casos as tarefas foram redefinidas, divididas em duas ou mais partes, de forma a priorizar aquelas que estavam melhor definidas e, portanto, mais fáceis de serem executadas.

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.

O uso do Planning Poker permitiu aumentar a assertividade das estimativas feitas em 56% conforme pudemos acompanhar pelo ScrumWise. Isso foi fundamental para o planejamento, além de aumentar a confiança da equipe no sentido em que os membros passaram a sentir que seriam capazes de executar o que tinha sido proposto para cada Sprint quase em sua totalidade.

Adaptação do backlog

Quando se usa o Scrum, o mais tradicional é colocar no backlog tudo que está na análise de requisito e que, portanto, precisar ser validado. À medida que o projeto se desenvolve, é possível alterar esse backlog, definindo novas prioridades e preterindo ou mesmo descartando alguns itens. Isso é perfeitamente possível para projetos comuns, de pequeno porte e que começam do zero. Quando se tem projetos de larga escala e que envolvam plantas que já estejam em operação, no entanto, as coisas podem ser diferentes.

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.

A lição que ficou é que preciso montar e gerenciar o backlog de forma que ele efetivamente ajude e facilite o trabalho, o que é afinal a função da ferramenta. Por mais que a recomendação fosse incluir todos os itens, o que poderia parecer mais completo e organizado, constatamos na prática que isso não ajudava, já que itens de diferentes sprints por vezes se misturavam e acabavam confundindo. Para projetos de larga escala e aqueles em que não se tem todo o escopo definido de início, pode ser melhor ir definindo o backlog à medida que se executa o projeto, o que inclusive poupa horas de digitação para tentar definir todas as tarefas.

Refinamento do backlog

O refinamento do backlog nada mais é que um repasse das tarefas entre o Product Owner com cada um dos membros da Equipe de Desenvolvimento, fazendo um acompanhamento para saber como está o andamento das atividades e sobretudo escalonar as tarefas a serem trazidas na próxima reunião de Planejamento da Sprint. Isso ajuda a dar mais clareza no que precisa ser feito e na continuidade de cada atividade. Além disso, observamos outros ganhos de longo prazo.

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.