Se você trabalha com a gestão de projetos, provavelmente em algum momento já esteve na discussão do: “estimar ou não estimar?”
Quando se está à frente de um projeto de desenvolvimento de software, esse é um assunto que não tem como não falar sobre. Alguns dizem que é desperdício, outros dizem que é obrigatório.
Vamos refletir mais sobre esse assunto e analisar alguns pontos?
Inspirado pelo #NoEstimates e canal de agilidade.slack.com e Fábio Akita, quem comanda a autoria do nosso Blog hoje é o André Vinícius Andrade, PO aqui na nata.house. Continue a leitura e confira!
O que é estimativa?
Estimativa: cálculo de valor aproximado; avaliação aproximada que se realiza sobre alguma coisa.
Projeção, neste contexto, pelo dicionário quer dizer: cálculo feito por antecipação a partir de dados anteriores.
Afinal, por que as estimativas têm falhado?
Estimativas têm falhado porque, como a própria definição diz, estimar não é exato. Estimativa é apenas uma estimativa.
Elas devem ser utilizadas para aumentar a previsibilidade e saber a ordem de grandeza de tempo de uma tarefa (uma semana, um mês, 3 meses ou 1 ano).
Projeções devem ser utilizadas a partir de dados anteriores para analisar se o time conseguirá realizar todas as atividades propostas até a data final (data de expectativa de entrega).
Quando não estimar?
1 – Quando o projeto carrega muitas incertezas
Quando existem muitas incertezas no projeto, sejam técnicas ou de negócios, é aconselhável resolver essas incertezas antes de dar estimativas para o projeto.
Uma das maneiras de remover essas incertezas é utilizando de “spikes”, onde o time investe em possíveis soluções e discute qual será utilizada ou de design sprints nas quais o cliente pode ter uma noção de como ficará, e os desenvolvedores de como fazer.
2 – Quando o projeto já está estabelecido, maduro e preditivo
Quando um time já tem uma experiência no projeto/produto métricas não é necessário estimar.
Por exemplo:
O time tem um histórico de velocidade com tarefas pequenas, médias e grandes. Com base na mediana de cada um deles é possível projetar o tempo que levará para desenvolver uma nova tarefa, não sendo assim necessário estimar.
Quando estimar?
Estimar é útil na maioria dos outros casos. Traz previsibilidade e discussão sobre o que precisa ser feito em todo o time.
Como realizar estimativas?
A primeira coisa a se pensar é se a tarefa está grande demais em complexidade ou incerteza. Nesse caso, essas pendências precisam ser removidas primeiro.
Se ainda assim as tarefas estiverem grandes é uma boa prática dividir em tarefas menores.
Técnicas para estimar
Planning poker
Este método particular é conhecido e comumente usado quando as equipes têm que fazer estimativas de esforço para um pequeno número de itens (menos de 10).
O Planning Poker é baseado em consenso, o que significa que todos devem concordar com o número escolhido.
Nesta técnica, cada indivíduo tem um baralho de cartas com números da sequência de Fibonacci, em que cada número é a soma dos dois últimos números (por exemplo, 0, 1, 1, 2, 3, 5, 8, 13 e assim por diante).
Uma grande vantagem desse método é que todos têm a chance de entender como implementar o item. Além de poder calcular a velocidade do time posteriormente.
Eu gosto bastante de utilizar a matriz de complexidade. Ao estimar uma tarefa é importante saber o risco de cada uma.
Matriz de incertezas – Raphael Albino
Estimativas em horas
Uma vez que, no início do projeto a equipe não tem nenhum dado sobre a velocidade, ter uma estimativa em horas para dimensionar o projeto pode ser necessário.
É importante que as estimativas sejam feitas por quem vai desenvolver a aplicação e que estes tenham o máximo de conhecimento possível sobre.
Estimativa ballpark
Uma forma de estimar em horas, é com as estimativas ballpark. Um tempo aproximado para cada tarefa.
- 1 mês (talvez 1 mês e meio, mas definitivamente menos de 2)
- 3 meses (é mais de 2 meses, menos de 6 meses)
- 6 meses (é mais de 4 meses, menos de 9 meses)
- é mais de 6 meses, provavelmente menos de 1 ano
Priorizar, Priorizar e Priorizar
De acordo com o princípio de Pareto, 80% do valor está em 20% das funcionalidades e é responsabilidade do PO, junto com o cliente identificar quais são essas funcionalidades e executá-las primeiro.
🐈Inspeção é a chave. Inspeções devem ser feitas regularmente para verificar se o projeto está caminhando para o rumo certo.
Conclusão
Para que um projeto dê certo, é necessário enxergar todas as restrições existentes (tempo e o custo), enxergar o objetivo (priorizar as tarefas), começar com os itens de maior valor primeiro, inspecionar para ver se as funcionalidades estão conforme esperadas e adaptar se não estiverem.
Então, sabendo a velocidade de entrega da equipe em relação a um período de tempo, é possível projetar o fim do projeto. É necessário deixar essa projeção transparente e atualizada.
