Minhas primeiras experiências com T-shirt size (estimativa por tamanho de camisa)

Um experimento após tanto errar estimando em horas

Resolvi compartilhar o que comecei a experimentar entre os meses março e abril de 2017. Não é algo definitivo ou o melhor dos cenários, mas através deste experimento, consegui que pessoas olhassem diferente para a tão solicitada estimativa em horas.

Cenário:

1 — Projeto em Java e AngularJS

2 — Requisitos com pouco detalhamento, mas estava claro o que precisava ser feito (ex: calcular taxa XPTO ao efetuar cadastro de ALGO. A necessidade do cliente estava clara, mas como calcula a taxa XPTO era um pouco obscuro).

3 — Nenhum desenvolvedor com total conhecimento do sistema, pois os desenvolvedores especialistas já haviam saído do projeto e da empresa. Porém, haviam 3 desenvolvedores que trabalharam em demandas específicas de menor impacto no sistema(não necessariamente pequenas).

4 — Cliente insatisfeito com os prazos que raramente eram cumpridos.

5 — Cliente exigindo estimativa em horas.

Ação

1 — Levantei os itens desenvolvidos entre dezembro/2016 a março/2017 (época que não tínhamos mais os desenvolvedores especialistas na ferramenta)

2 — Coloquei todas as tarefas numa planilha com as seguintes colunas:

  • numero da tarefa
  • descrição da tarefa
  • tamanho (que ficou em branco inicialmente)

3 — Entrevistei os 3 desenvolvedores que trabalharam em alguma tarefa entre dezembro/2016 a março/2017. Expliquei o que eles deveriam fazer que era lembrar da necessidade do cliente e dizer se era PEQUENO, MÉDIO ou GRANDE.

Um detalhe importante: eles deveriam dizer se era P, M ou G o que precisava ser feito para atender a demanda e não ter como referência a quantidade gasta de horas na tarefa, pois isto iria induzi-los a uma resposta, geralmente pendendo para um tamanho maior de camisa.

4 — Li cada um dos itens da planilha para eles lembrarem da demanda. Após a leitura, eles davam a opinião deles dizendo se era P ou M ou G.

Um detalhe importante: cada desenvolvedor estimou todas as demandas, não somente a que ele mexeu. Fiz isto para ter uma visão ampliada se as a visão da demanda estava uniforme.

Outro detalhe importante: evitei ao máximo abrir a ferramenta que tinha a descrição completa da demanda, pois lá já tinha a quantidade de horas gastas efetivamente. Isto influência na opinião de quem está estimando, pois ele toma aquele valor como referência.

Um último detalhe: todas as tarefas do período estavam na minha planilha, mesmo as que não tinham estimativas iniciais. Entendi que era importante considerar estas tarefas também pois elas tinham o tempo efetivamente gasto e isto iria me ajudar a ter um valor de P, M e G mais correto.

5 —Ocorreram algumas divergências de tamanhos entre os desenvolvedores. Mas como eram 3 respostas, considerei a que teve mais votos. Exemplo: 2 desenvolvedores votaram P e um votou M. Então o P ganhou (para o meu momento de experiência foi a forma mais correta que encontrei).

6 — Atualizei a planilha inicial com os valores de P, M e G

7 — Adicionei as colunas:

  • Quantidade real de horas gastas (total)
  • Quantidade real de horas gastas (desenvolvimento)
  • Quantidade real de horas gastas (análise)
  • Quantidade real de horas gastas (testes)
  • Quantidade estimada pelo desenvolvedor na época da tarefa
  • Desvio (diferença na quantidade de horas entre estimado e realizado pelo desenvolvedor)
  • % do desvio

Conclusão após este levantamento:

  • De 22 demandas que tinham estimativa inicial, somente 5 tiveram uma entrega próximo do estimado (considerando 10% de desvio, para baixo ou para cima).
  • Destas 5, somente uma teve um desvio abaixo de 5% do estimado (para baixo ou para cima).
  • Resumindo: cerca de 22% do nosso compromisso era efetivamente entregue de forma aceitável. E 78% das vezes errávamos.
Parte da planilha usada para análise
2 acertos entre 10 estimativas. :(

Ações para descobrir valores P, M e G

  • Separei as tarefas em P, M e G e identifiquei a quantidade de tarefas por tipo e somei as horas de desenvolvimento destas tarefas
  • Fiz a média destas horas.
  • Fiz a mediana só para ter mais uma outra informação.

Aplicação nas outras demandas:

Rodei em uma semana a estimativa por tamanho de camisa e o resultado foi este:

Conclusão:

  • Das quatro demandas que existiam, todas foram entregues antes do prazo.
  • O cliente ficou contente.
  • Uma demanda P era muito pequena e foi feita em 0,42h. Vimos a necessidade de criar um PP.
  • Com as horas efetivamente gastas recalculei o tempo do P, M e G.
  • Percebi que os valores foram se ajustando (ver imagem abaixo).
Valores iniciais
Após a primeiraiteração

E aí seguimos para a semana 2:

Após segunda iteração

Lições aprendidas

  • Após saber o tamanho do P, M e G o cliente pode se assustar com a quantidade de horas de alguns tamanhos (em especial o G). Mas é preciso conscientiza-lo que com o passar das iterações os valores irão se ajustar para algo mais próximo do real.
  • O cliente pode não concordar com esta estimativa e os valores, mas por que não tentar algo diferente? O cenário é a cada 10 demandas, entregamos 2. Por que não tentar algo que possamos entregar com mais assertividade???
  • As primeiras iterações você acerta facilmente e tende a terminar antes do prazo. Para um time que nunca entregava, isto é muito bom. Deve ser comemorado. Este foi o momento que o time voltou a ver valor em estimar.
  • Com o recálculo das demandas após cada iteração, os valores vão se aproximando de algo bem mais certeiro.
  • Estimar por tamanho é muito rápido. Paramos de perder tempo em horas de discussão e planning poker.

Paramos de perder tempo em horas de discussão

  • Funcionou para um projeto. Os valores de um projeto não servem para outro projeto. Podem ser números parecidos, mas não serão iguais.Seria algo semelhante ao tamanho G de uma marca de calça, provavelmente não será o mesmo G de outra marca.

Os valores de um projeto não servem para outro projeto. Podem ser números parecidos, mas não serão iguais

  • Podem existem demandas PP é bom considerá-las, senão o seu P pode ficar com valores bem divergentes. Ex: uma tarefa para colocar acentuação numa tela e uma tarefa para criar uma tela com listagem de dados e filtros. A primeira provavelmente será uma PP e a segunda provavelmente será uma P.
  • Podem existir demandas maiores que G. Resuma elas em GG e quebre as tarefas em tamanhos menores. Não use XGG.

Desfecho

Para minha surpresa e para a minha tristeza o projeto mudou de rumo e foi descontinuado. Para outros projeto, não foi possível aplicar esta prática por uma decisão específica.

Bom, mas eu descobri que existe uma maneira mais efetiva de estimar.

Se você tem alguma experiência nesta área e puder me ajudar, estou aberto a conversas no Slack do Agilidade.org (@fusca) ou no wagnerfusca@gmail.com ou aqui nos comentários.

Dica final:

Um material legal para ler sobre estimativas é material do Frederick PhillipsFredBrooks Jr — O mito/mítico homem hora ou homem mês:

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.