Estimativas Ágeis

Recentemente fui chamado para facilitar mais um treinamento de MS Project, e eu recusei. Algumas empresas se orgulham de ostentar na parede um belo gráfico de gantt para representar as relações entre as tarefas, os recursos necessários e a cronologia de entrega dos pacotes.

É impressionante a precisão. Em umas das minhas visitas consegui identificar que daqui a exatos 8 meses, ou seja, no dia 22 de novembro o recurso John Doe estará fazendo cotações de preços para compra de cadeiras, sendo que estará alocado part time no projeto e que para concluir esta atividade, ele depende do layout da sala. Vale lembrar aqui que todos os requisitos desta cadeira estão devidamente definidos aliás, todos os requisitos deste projeto já estão definidos.

Estimativas como as descritas acima são comuns e apresentam um alto grau de precisão, porém o percentual de acerto é baixíssimo. Outras questões são as seguintes: será que os requisitos permanecerão os mesmos? Será que daqui a 8 meses, ao invés de cadeiras não seria melhor comprar bancos ou sofás? E se o projeto for abortado, de que valeu todo aquele esforço de planejamento?

Estimativas sem acurácia são frequentes no planejamento tradicional. Por exemplo, se eu afirmo em meu cronograma, que determinado pacote de trabalho será entregue no dia 02, essa é uma estimativa de alta precisão, independente do dia real de entrega. Entretanto se ele ficar pronto no dia 15, essa estimativa foi completamente sem acurácia e errada.

Muitas de nossas estimativas são passadas sem se calcular o mínimo de esforço necessário para concluir a tarefa. Às vezes, passamos para agradar o cliente, ou não o perder. Talvez porque queiramos agradar o gerente ou até por medo de sair do projeto.

Uma das características do Gerenciamento Ágil de Projetos é que podemos começar o projeto com os requisitos que temos disponíveis. Podemos montar o nosso backlog à medida que avançamos no projeto. O esforço inicial de coleta de requisitos no gerenciamento tradicional leva tempo, e um esforço considerável da equipe, dependendo da complexidade do projeto.

O produto é construído em ciclos de iterações, e em cada um destes ciclos é apresentada uma pequena parte do produto. A primeira sprint, certamente representará o que gera mais valor para o cliente, pois o backlog é priorizado de acordo com o ROI. Os itens na parte superior do backlog são mais detalhados e permitem maior compreensão por parte do time.

O mais comum para se estimar tempo no scrum, mesmo que de forma relativa, são os story points. Na verdade, estão mais voltados para o esforço, do que propriamente tempo. O time de desenvolvimento é o único responsável para definir o tamanho das estórias. As melhores pessoas para estimar o esforço é quem desenvolve o produto. Parece obvio, mas isso é ainda muito ignorado em projetos. Acredite!

Uma alternativa para identificarmos o trabalho que ainda precisa ser feito, e também uma forma visual de acompanharmos o desempenho do time é o gráfico de sprint burndown. O gráfico mostra a quantidade de pontos de estórias no eixo y e no eixo x os dias relativos a sprint atual.

Muitos times ágeis optam por não marcar a linha ideal para evitar cobranças desnecessárias.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo!

Sobre o autor

Rodrigo Zambon

Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.