Porque as estimativas têm falhado?

DesenvolvimentoGerenciamento de ProjetosNegóciosProdutoSoftwareTecnologia

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.

Conciliar agilidade com qualidade é essencial no mercado de software. O mantenedor do funcionamento dos processos que envolvem de clientes a devs é o PO.⠀

Essa pessoa é a real dona do projeto, quem assume a responsabilidade, quem o defende com unhas e dentes.⠀

Ela vai garantir alinhamento da equipe com o mesmo ideal do produto, e que o cliente vai receber entregas constantes que geram valor.⠀

Aqui na nata temos POs no nosso time para garantir a agilidade e qualidade das entregas. Não abrimos mão!⠀

Quer saber mais sobre como a nata.house pode contribuir para o crescimento do seu negócio? Fale com um dos nossos especialistas! 

Receba conteúdos sobre inovação digital, novas tecnologias, design e desenvolvimento.

Entre em contato

Telefones

+55 31 98426-5166

+55 31 4042-1001

Endereço

R. Paraíba, 330, sala 1006

Belo Horizonte - MG - Brasil