Frustrações de uma pessoa desenvolvedora — tema: estimativa

“Eu não acho estranho uma pessoa errar uma estimativa. Acho estranho acertá-la com frequência” Rodrigo Yoshima

8 min readDec 21, 2020

Esse é o segundo post de uma série de postagens que relatam situações que acontecem no desenvolvimento de software, mas com a visão de quem coloca a mão em código fonte. O primeiro post pode ser conferido nesse link e fala sobre qualidade.

O tema de hoje será contado por mim e pelos meus amigos Daniel Wildt (linkedin), Guilherme Motta, Lucca Bonifácio Roder(linkedin) e Vinicius Campos Silva(linkedin) e um relato anônimo. Cada uma dessas pessoas tem uma história incrível e que merece a sua atenção e leitura concentrada.

Meu relato:

É segunda feira, 9h da manhã. Já estou com meu café e vou para a sala de reunião para aquela “alegre” reunião chamada planning. Já sei que vou ouvir o PO por 1h, mas minha mente vai entender só os primeiros 15 min que ele falar. E na sequência vamos ter que jogar o nosso baralho mágico, chamado planning poker.

Passada uma hora de explicação, o SM pergunta: “Alguma dúvida?” e ninguém fala nada. Então o SM fala: “vamos lá, escolham suas cartas”.

Eu olho pro lado, em busca de ver o que o meu amigo vai selecionar, afinal de contas, não quero passar vergonha e ser o único que vai jogar uma carta alta (tipo pontuação 20) e também não quero colocar uma carta de interrogação, pois o pessoal vai achar que eu sou burro. Mas uma coisa é certa, eu não entendi nada.

Chegou a hora de revelar os votos. Todos colocam 20 pontos!!! O PO se assusta e fala: “gente… não é tudo isso não, será que não é 8 ou 13??? Vai lá gente, vocês são feras demais, 20 é muito para um time tão bom quanto o de vocês.”

A gente finge que acredita no elogio. Eu respiro fundo e falo: “tá bom… é sempre assim… vai 13 então”. O PO e o SM comemoram. Eu só penso em acabar logo essa reunião chata.

Daniel Wildt

Já disse que uma feature levaria 248 horas e meia. E MEIA. E essa era a estimativa pessimista. :P

Teve um outro caso de uma feature que terminei em 1/3 do tempo previsto e me pediram pra não sinalizar que estava pronto, para não gerar questionamento sobre a estimativa errada. :)

Anônimo

A história frustrante que vivi com estimativa é sobre o uso de ponto de função para estimativa de software. A gestão desejava que as contagens fossem feitas, entretanto, ninguém acreditava nessa estimativa, nem o time de desenvolvimento e nem a área de negócios.

A gestão desejava que as contagens fossem feitas, entretanto, ninguém acreditava nessa estimativa, nem o time de desenvolvimento e nem a área de negócios.

Mesmo tentando trazer o contexto de métricas estatísticas para os times como o leadtime, throughput e wip, não conseguimos força para evoluir por que existia esse apego da alta gestão para usar o ponto funcional como estimativa.

O time calculava o ponto funcional para agradar a gestão, mas não usava a informação para nada. Era passada outras estimativas para o negócio que também não era pautada em dados históricos. Continuamos com problemas de confiança entre negócio e TI, negócio falando que TI nunca entrega no prazo e TI sempre falando que negócio muda o tempo todo.

Guilherme Motta

Alguns anos atrás, nossa equipe no Brasil trabalhava remotamente com uma grande empresa americana. Iniciamos um projeto com um time distribuído entre Brasil e EUA.

Nesta equipe, que já havia trabalhado junta em outros projetos, já trabalhávamos conceitos relacionados a métodos ágeis (e boas práticas de engenharia de software) e na época esse cliente estava tendo boas experiências trabalhando com Scrum.

Eventualmente, a pessoa responsável pela gestão desse projeto apresentou um plano, distribuindo o escopo conhecido em 9 meses, 18 sprints de duas semanas.

O backlog havia sido todo estimado pelo time utilizando Planning Poker e as estimativas foram feitas baseadas em esforço, resultando em números da sequência Fibonacci que pareciam fazer sentido.

Ao final do primeiro Sprint, algumas conversas estranhas aconteceram:

Incluímos na nossa velocity trabalho parcialmente completo
Quebramos histórias de usuário para “captalizar” na entrega da Sprint trabalho que não havia sido concluído
Adicionamos novas tarefas, com estimativas atribuídas depois do trabalho feito
entre outras bizarrices..

Ao final do primeiro Sprint, o time havia entregue exatamente X pontos, e para minha surpresa, era exatamente o número de pontos que havia sido proposto no planejamento do projeto para a entrega da primeira Sprint.

Ao final do segundo Sprint, mesma coisa. Criação de novas User Stories, remoção de tasks, movimentação de escopo entre Sprints, qualquer coisa para chegar no tal número planejado para a velocity da segunda Sprint.

E assim foi o projeto, 9 meses e 18 sprints onde foi entregue exatamente o número de pontos planejado 9 meses antes.

A pessoa responsável pelo projeto recebeu um prêmio/reconhecimento ao final do trabalho por excelência em planejamento, gestão e estimativa.

Na realidade, o que de fato ocorreu, é que nossas métricas e reportes tinham como objetivo se alinhar com o plano inicial. O time percebeu mas optou por ignorar e fazer o melhor possível para entregar valor para o nosso no cliente.

Este projeto, foi uma das experiências que me estimulou a aprender mais sobre gestão e um grande aprendizado sobre o que não fazer.

Lucca Rodder

O que falar sobre estimativa???? Olha confesso que é algo que me causa ansiedade mas, gosto de compartilhar minhas experiências e meu ponto de vista sobre o assunto rs.. Vamos lá…

Olha para ser sincero as experiências não foram tão boas, primeiro que a maioria dos projetos já tinham prazos definidos e segundo as pessoas desenvolvedoras mais experientes analisavam o projeto antes da própria equipe e davam uma estimativa "aproximada" baseados em experiências próprias, isso é muito crítico pois, nem sempre essas pessoas que deram essa estimativa "aproximada" participavam de fato da equipe que participava do desenvolvimento, ou seja, quando projeto ia para equipe que iria desenvolver geralmente já chegava com prazo "mais ou menos" definido e a estimativa das funcionalidades parecia para mim algo apenas para cumprir um protocolo e uma tentativa de achar um meio termo para o prazo final da entrega.

Um ponto muito difícil nisso tudo são os imprevistos e as mudanças no meio do desenvolvimento, não pelas mudanças que essas são comuns mas, por entrar mais coisas no backlog para a sprint atual e não despriorizar outras tarefas fazendo com que tivéssemos vários atrasos nas entregas. Um problema para mim é o desgaste emocional que isso causava, toda retrospectiva parece ser uma lavação de roupa suja e nós sempre escutarmos a frase dos nossos líderes "Mas vocês estimaram", isso me deixava com a sensação de que a estimativa no projeto era exclusivamente para achar culpados pelas falhas e que os líderes não caminhavam lado a lado com as pessoas desenvolvedoras.

A lição aprendida por mim é que uma maneira assertiva de se fazer uma estimativa é usarmos como base outros projetos já trabalhados que possuem tech stack semelhantes, a senioridade do time semelhante e os desenvolvedores do projeto estimarem. Não podemos estimar apenas como base na nossa própria experiência mas, olhar o cenário em volta e responder algumas perguntas tais como:

Quantas pessoas possuem uma experiência alta nessa tech stack?
Quantas pessoas já desenvolveram funcionalidades parecidas com essa?
Como podemos durante o projeto ajudar as pessoas a se desenvolverem?
Caso as pessoas mais experientes do projeto tiver um imprevisto, os outros membros do time conseguiriam fazer essa tarefa nesse mesmo tempo?
As histórias estão prontas para desenvolvimento, ou está faltando informações muito importantes?
Como está a saúde emocional da equipe?

O segredo é questionar muito, pensamento coletivo e liderança apoiando. Quando uma pessoa percebe que possui um suporte o trabalho flui muito melhor.

Os desenvolvedores do projeto sabem muito bem quantas histórias cabem em sprint e quanto tempo leva para desenvolver as funcionalidades.

Tem uma frase que gostaria de deixar aqui.

Se você não é uma das pessoas que coloca a mão no código no projeto, você não está apto a opinar sobre quanto tempo leva para transformar uma tarefa em código para esse projeto.

Vinicius Campos

Compartilhando um pouco sobre as estimativas na época em que eu trabalhava em consultoria. Costumava ser frustrante e acredito que muito próxima a realidade de outras pessoas. Em uma das minhas experiências profissionais, tínhamos que estimar a escrita das documentações técnicas e funcionais, analisar todas as linhas de classe/métodos que seriam alteradas, a prática de testes sempre era considerada metade do tempo de desenvolvimento, além de considerarmos suporte ao cliente no pós-entrega e ao final da “estimativa” a nossa planilha de estimativa adicionava 20% de tempo para garantir uma “segurança” para o prazo. Lembro de discussões nossas para aumentar horas em um lugar e colocar em outro para “facilitar” a aprovação, não considerando a nossa real capacidade de absorver o projeto. Ou seja, passava uma falsa sensação de que tudo estaria sob controle.

Essa estimativa passava pela aprovação do cliente, que algumas vezes pedia para reduzir a estimativa dos testes/suporte ou até mesmo removê-la para ficar mais barato. Eu pensava o quão custoso e sustentável seria este tipo de comportamento a longo prazo.

Além disto, tínhamos que registrar diariamente as horas empregadas no projeto, que apenas serviam para reforçar que o planejamento daria errado. Nossas estimativas tinham a premissa que:

Consideravam que uma pessoa é produtiva 100% do tempo;
Não tínhamos dependências de outras áreas/pessoas;
Espera de aprovação de pull requests que apenas o cliente fazia (e algumas vezes levava dias);
Dúvidas que poderiam surgir ao longo do projeto e mudanças na solução;
Problemas com ambientes de desenvolvimento;

Entre outras que faziam parte do nosso desafio no dia a dia.

O problema ao final era que o trabalho feito sempre era maior que o planejado e vendido ao cliente. E jamais essa estimativa era revista durante o projeto vigente causando situações desconfortáveis quanto ao nosso progresso e nos projetos seguintes para estarmos mais próximos à realidade, sendo que qualquer nova estimativa, principalmente para mais em projetos futuros, era questionada e ajustávamos a um valor “adequado”.

Conclusão

Pare de acreditar em estimativas. Pare de oprimir as pessoas com essa prática e pare de gerar uma insegurança emocional nas pessoas desenvolvedoras que erram estimativas. As pessoas erram estimativas porque estimativa não funciona, não é porque as pessoas não são competentes!!!

Mas se tiver que usar estimativas, não use números. Use proporções de grandeza (P, M, G e se for maior que G, precisa ser quebrada). Eu tenho gostado do formato que o paulocaroli usa no Lean Inception, na etapa de funcionalidades:

Disponível em https://www.caroli.org/wp-content/uploads/2018/10/RevTecNegUX-ImprimirA1.pdf

Se tiver que usar números e prazos, técnicas de previsibilidade vão te ajudar a ser mais assertivo. Materiais como do Raphael Albino e Caco poderão te ajudar:

Aqui eu relato um pouco de uma experiência que começou a dar certo, com T-shirt size (estimativa por tamanho de camisa)

Mas se ainda assim você quer continuar usando pontos e números, saiba que o Jira permite estimar com precisão em decimais!!!! Vai lá! agora você vai acertar #sqn