Estava outro dia conversando com meu gerente de projeto e uma reclamação que eu sempre tive com a forma de gestão da empresa é a de usar uma equivalência entre story points e dias/horas de trabalho. E isso não é uma novidade para qualquer um, já que o story point é algo que normalmente defino como esotérico.
esotérico (e·so·té·ri·co)
adjetivo
- Relativo ao esoterismo.
- Pouco compreensível pelo comum dos mortais. = HERMÉTICO, OBSCURO ≠ EXOTÉRICO
Origem etimológica:grego esôterikós, -ê, -ón, que pertence ao interior, esotérico.
“esotérica”, in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2024,
Dicionário Priberam
Me atenho à segunda definição, é algo meio etéreo, mas cheguei em uma definição melhor nessa conversa com meu gerente: o story point é tipo a jarda ou a polegada na época medieval, cada reino tem o seu tamanho, já que eram medidas relativas ao rei: A jarda era a distância do nariz do rei ao seu polegar com o braço esticado, e a polegada era exatamente o dedão do cara.
No caso do story point, o rei é a somatória da equipe e do projeto. Então, a única comparação possível de SPs é com sprints anteriores na mesma equipe e no mesmo projeto: a conhecida velocidade da equipe. E mesmo assim não dá pra dizer que: “Já que a equipe entregou X SPs no sprint passado, então 1 SP é igual a X/10”. Não é, nunca vai ser, e sempre vai falhar se for usada essa lógica. Mike Cohn fala sobre isso em seu blog (em inglês):
Mas quando digo que story points são sobre esforço e que esforço é medido em tempo, não significa que equipes poderiam dizer “Um story point é igual a oito horas.” Nem perguntar “Um story point são quantas horas?” Igualar story points a um certo número de horas é uma má ideia. Não faça isso
Igualar horas a story points elimina o principal motivo para usar story points: Story points são úteis porque eles permitem que membros da equipe que trabalham em velocidades diferentes comuniquem e estimem a quantidade de trabalho colaborativamente.
Mike Cohn – https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours
Naveen Kumar Singh resume bem ao dizer que é um problema de geração, e divide as pessoas em pré-ágil e pós-ágil. Para os que começaram a trabalhar antes das metodologias ágeis se firmarem no meio, é difícil transformar esforço em pontos; já os que já começaram trabalhando com tecnologias ágeis, a conversão de pontos em horas é um problema.
Mas eu ainda acho que o maior problema está em formas de gestão de trabalho industriais serem usadas para TI. Gestão de projetos físicos se atém a índices mensuráveis: margem de erro, volume de produção (quilogramas, litros, metros), quantidade de peças com erro… E tudo isso é impossível de ser realizado em TI quando falamos de software. Já vi diversos índices usados para tentar medir o código, incluindo aberrações como quantidade de linhas de código.
Mas o maior problema é que criatividade não pode ser medida. Se você der o mesmo problema para 30 desenvolvedores você terá várias repostas similares, mas poderá agrupá-las em algumas soluções bem diferentes, com diferentes graus de robustez, manutenibilidade e até eficiência.
Mais de uma década atrás eu fiz um curso de Análise de Pontos por Função, uma métrica mais utilizada para contratos e precificação e software. É trabalho de corno, analisar todas as telas, contar campos, se tem validação, se tem somatória, se é o crud inteiro, se é relatório, etc… E chega-se à um valor de pontos de função, que normalmente é acordado X dinheiros por ponto e então, multiplica-se um por outro e faz-se a cobrança.
E os pontos de função também não podem ser convertidos em tempo. Eu entendo a necessidade de se prever faturamento, produtividade, prazo de entregas e tudo mais. Mas o erro está em usar uma régua ruim para inferir tempo ao esforço estimado. Da mesma forma que não dá pra fazer um bebê em 1 mês com 9 mulheres, 8 tarefas de 1 story point não tomam o mesmo tempo de uma tarefa de 8 SPs.
Então como devemos medir a produtividade da equipe? Como prever as entregas dos produtos, das funcionalidades? Pela velocidade da equipe. Em projetos novos, ou equipes novas, e no mais comum equipe nova para um projeto novo, é muito comum a flutuação da quantidade de entregas entre os sprints. Isso se deve a dois fatores principais: a falta de conhecimento sobre o projeto e a falta de entrosamento da equipe.
Desconhecer o projeto leva a estimativas erradas, a não ver uma peculiaridade necessária, a esquecer de que o front end deve funcionar em mobile também. Nisso uma tarefa é subestimada e acaba sendo mais difícil que o esperado. Já a falta de entrosamento da equipe faz com que o mais especialista não seja alocado à tarefa, ou que seja mal-avaliado o desempenho total da equipe.
Pela minha experiência com diversas equipes e projetos o primeiro sprint é subestimado e a equipe não consegue fechar o prometido; o segundo sprint leva menos SP e acaba entregando mais exatamente por usar a velocidade do anterior e a equipe ter um maior entrosamento e já saber mais do projeto do que no primeiro sprint. Somente a partir do terceiro sprint é que as promessas começam a ficar mais próximas das entregas.
Além disso, toda análise inicial em projetos ágeis é feita de forma superficial, não se faz toda a análise do projeto, com diagramas de fluxo de dados, fluxo de entidade relacionamento, especificação de processos, e etc… A perda de tempo com essa documentação de análise estruturada foi o que deu luz as metodologias ágeis. E o ágil abraça a mudança. A metodologia se adapta constantemente para atender a necessidade, então o story point acaba sendo uma medida incerta para projetos incertos.
O próprio SAFe diz que “story points são relativos, sem nenhuma conexão com alguma unidade de medida. O tamanho de cada estória é estimado relativo à menor estória que recebe o tamanho de 1. Uma sequencia de Fibonacci modificada (1,2,3,5,8,13,20,40,100) é aplicada para refletir a incerteza das estimativas, especificamente em números maiores (20, 40, 100).”
Adicionalmente, como dito anteriormente, 40 story points de uma equipe não são a mesma coisa do que 40 story points em outra equipe. Então pra que usar o Story point?
Para acompanhar o andamento do projeto e estimar os próximos passos. Dada a incerteza inerente ao desenvolvimento de software, com mudanças de tecnologia e de mercado entre outras, o story point permite vislumbrar em quantos sprints um conjunto de tarefas estimadas pode ser entregue.
E um sprint é uma unidade de tempo. E só assim podemos converter story points em dias, mas deve-se levar em consideração o trabalho do grupo inteiro e não apenas uma estória e sua estimativa de complexidade ou esforço. Então a previsão deve ser X sprints para entregar Y story points e nunca X dias por story point, pois esse valor nunca é preciso.