Pare de estimar com sua equipe. Use métricas!

Olá!

Neste artigo vamos ver como é possível tirar essa penosa atividade das costas da nossa equipe técnica!

 

Você gestor já parou para pensar que a estimativa do seu desenvolvedor é limitada à visão que ele tem do projeto? E isso não é uma falha dele! É algo natural, veja abaixo o porquê.

Ao visualizar o Kanban acima podemos entender melhor onde ele estima, porém a demanda tem todo um ciclo de vida que deveria fazer parte da estimativa que será entregue ao cliente.

Você pode estar pensando: 

“Mas se eu fizer isso o cliente vai achar muito caro!”

Cuidado! O que está sendo demonstrado aqui é o ciclo de vida da demanda ー o que é muito importante conseguirmos quantificar e mostrar para o cliente, pois isso será o que teremos de mais próximo da realidade e melhor que qualquer estimativa feita no feeling de um conjunto de pessoas jogando Planning Poker[0] ou dizendo se é P, M ou G[1].

 

Para contabilizarmos o tempo efetivo gasto no desenvolvimento precisamos definir onde será ou serão os touch time. Ou seja, o momento onde há um trabalho efetivo de desenvolvimento. No caso deste artigo, para simplificarmos considere somente a Coluna Doing.

 

Estimativa x Métricas

Entendido até aqui, podemos partir para um comparativo entre estimar com sua equipe ou somente utilizando métricas!

 

Cenário 1 – Utilizando a equipe para estimar

Projeto XPTO – Release 2

• Demandas identificadas para o release: 20
• Demandas já entregues no release 1: 30
• Valor hora do projeto: R$ 150,00
• Desenvolvedores na equipe: 5
• Metodologia utilizada: Scrum

 

A primeira coisa que será feito antes de iniciar o desenvolvimento é a cerimônia chamada de Release Planning (RP), onde podemos considerar que serão chamadas todas as pessoas da área de desenvolvimento envolvidas no projeto para serem apresentadas às demandas e a partir disso fazerem as estimativas em conjunto.

 

Normalmente dentro dessa cerimônia se utiliza geralmente uma dessas duas técnicas: Planning Poker ou PMG. Vamos utilizar as duas aqui.

 

Supondo que nossa RP levou 6 horas, com todo mundo saindo muito cansado e chateado de ter ficado ali viajando nas ondas das “estimativas assertivas”, chegamos no seguinte resultado:

 

Cenário 2 – Utilizando somente métricas para apoiar a construção da estimativa

Projeto XPTO – Release 2

• Demandas identificadas para o release: 20
• Demandas já entregues no release 1: 30
• Valor hora do projeto: R$ 150,00
• Desenvolvedores na equipe: 5

Neste cenário já temos a entrega de uma release anterior de 30 demandas. O que nos diz que temos informações disponíveis. Abaixo seguem alguns exemplos de métricas que podem ser geradas a partir do monitoramento das transições dos cartões entre as colunas do Kanban.

Este é um gráfico de dispersão onde o eixo X são as demandas e o eixo Y o Lead time delas. As 3 linhas pontilhadas são os percentis[3] de 60, 80 e 95, ou seja, em 60% dos casos uma demanda pode levar X dias para sair de ready for development e chegar em Done.

O padrão de percentil utilizado em estimativas na Taller hoje é na casa dos 80%. Ou seja, a margem de risco é de 20%. Quanto menor o percentil utilizado, proporcionalmente maior será o crescimento do seu risco.  

Este segundo gráfico é mais uma forma saber como está o Lead time das suas demandas entregues.

 

Para simplificarmos esse cenário vamos trabalhar somente com estes 2 gráficos, mas existem outros N que podem trazer mais dados para apoiar na construção de uma estimava.

 

Supondo agora que eu, como Analista de Negócios, tenho essas informações disponíveis e levo cerca de 1 h sozinho para levantar 3 tipos de estimativas.

É importante lembrar que aqui estamos lidando com o Lead Time e não somente com Cycle Time de Doing. Para fins didáticos vamos tirar uma média entre os prazos em meses do P60 e P80 isso nos dará um valor de 3,02 meses de projeto, ou seja 1813 h.

 

Média prazo = (3,66 + 2,39) / 2 = 3,02 meses

Média horas = (1432 + 2195,2) / 2 = 1813 h

 

Importante!

Caso venha aquela pergunta: No caso de um novo projeto, sem releases entregues ainda? 

Na Taller o que fazemos é puxar informações históricas de projetos semelhantes e utilizamos seus dados para ter uma estimativa inicial e, a medida em que as demandas são entregues neste novo projeto, deixamos de usar as informações históricas e passamos a usar os dados do próprio projeto.

 

Comparação entre os 2 cenários

No primeiro cenário onde foi utilizado o planning poker ou PMG, podemos contabilizar o seguinte:

 

• Uma reunião onde devem estar as seguintes pessoas:
  • 1 AN / PO
  • 1 SM
  • 5 Devs

Em nosso caso otimista a estimativa desses 20 demandas levou cerca de 6h. Mas tem um detalhe, foram 6h de cada um dos membros da reunião, ou seja, foram gastas 42 h e se multiplicarmos pelo valor hora do projeto isso dará um total de R$ 6.300,00.

 

Se pararmos para pensar, uma estimativa acabou de consumir 1 semana de trabalho de uma pessoa do time de desenvolvimento! Imagine só colocar no papel todas as outras cerimônias de estimativa?

No segundo cenário, com a utilização dos dados históricos do projeto, conseguimos chegar no seguinte custo:

 

• 1 Analista de Negócio com conhecimento de capturar as métricas e utilizá-las

 

Dentro de um período de 1 hora, ou seja R$ 150,00, é possível levantar uma estimativa muito mais próxima da realidade pois estamos utilizando dados históricos ao invés do feeling das pessoas e que ainda estão sendo representadas por uma camada de incerteza (planning poker ou PMG).

 

E nesta análise temos o Lead time como base de ciclo de vida do card. No caso do cenário 1 a base de ciclo de vida é somente do Cycle time Doing, pois é onde o time de desenvolvimento está. É quase certo que a pessoa que ocupa a posição de PO, vendo a estimativa do cenário 1 colocará gordura. Fazendo com que passe da estimativa feita a partir de números.

 

Se interessou e quer saber mais sobre como obter esses dados estatísticos de forma automática? Vamos conversar!

A Taller está lançando, para um pequeno grupo, nosso software que coleta essas informações do Kanban diretamente do seu Jira. Assim você tem mais previsibilidade e métricas para seu time e seus clientes.

 

Legendas:
Planning Poker[0] - Uma forma de conseguir "estimar" o esforço de desenvolvimento de um conjunto de demandas já "bem especificadas", no google tem diversos posts explicando sobre essa técnica.

PMG[1] -  É uma outra técnica semelhante ao Planning poker, só que neste caso não se usa um baralho, o time já possui um idéia de tamanhos PP - Pequeno Pequeno, P - Pequeno, M - Médios, G - Grande, GG - Grande Grande, depois é convertido também dias ou horas.