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.