Fibonacci, User Story Points e Frutas

Um time de profissionais com alguma experiência em desenvolvimento de software tem plenas condições de planejar sprints em algumas horas ou dias, a única premissa é desapegar dos detalhes e discutir apenas a complexidade, o suficiente para comparar e inferir o seu tamanho.

É claro que precisamos ter antes um tanto de auto-conhecimento e clareza no fluxo de trabalho necessário, responsabilidades, DoR e DoD, o restante é básico, como profissionalismo, empatia, senso de pertença e evitar erros conhecidos.

Na chincha, o tipo de estimativa é irrelevante, quer seja T-Shirt Size, User Story Points, Dias Ideais ou Jujubas, … a técnica usada para estimar não muda em nada a quantidade de software que uma equipe é capaz de construir em uma sprint de 10 dias.

Independente de ter sido estimado com tamanho M ou ter 5 pontos, ser 4 dias ideais ou precisar de 7 jujubas, não mudará o fato mais importante que é saber se ele junto de algumas outras histórias cabem ou não em um sprint de 10 dias úteis.

User Story Points

User Story Points usa a série de Fibonacci, uma sequência de números inteiros, começando por 1 e 1, com os subsequentes correspondendo à soma dos dois anteriores [1, 1, 2, 3, 5, 8, 13, 21, …], que em estimativas de software é usual fixar um teto, com frequencia 13 ou 21.

O uso desta série para estimativas de histórias tem o objetivo de desapegar dos detalhes e nos preocuparmos apenas com aspectos que determinem a mudança de patamar. Desta forma, quanto maior a incerteza, maior a história e maior a distância entre os números da escala.

Salada de frutas

Vejamos uma boa analogia sobre a arte de estimar usando Fibonacci e o estabelecimento de referências e comparações. Para visualizar o que estou afirmando proponho um exercício com a imagem abaixo, uma mesa com vários tipos de frutas.

Se o nosso projeto é desenhar e colorir frutas, posso estimar a partir do tamanho em área, perímetro, volume, mas existe também a existência de detalhes, número de cores, a abstração disso tudo podemos chamar de complexidade.

Complexidade diz respeito ao todo, shape, diâmetro, cores, mas se antigamente estimávamos listando cada um e todos estes detalhes, em metologias ágeis uma breve discussão sobre suas peculiaridades é suficiente para perceber se é mais ou menos complexo que outros.

Após discutir sobre as frutas, é possível estabelecer o que seria a menor fruta em sua complexidade geral, para desenhar, pintar e entregar. Feito isso, vamos estimando comparativamente cada uma das outras.

Na prática, não há uma regra óbvia, cada time poderá estabelecer uma base e comparação para a sua estimativa, semelhante mas não necessariamente igual. Mesmo assim, se realizada de forma adequada e consciente, responsável, é provável que tudo dê certo.

Usando pontos sob o paradigma de complexidade relativa, a estimativa não é pelo tamanho da fruta, nem número de côres, mas pela complexidade comparativa, na percepção de esforço que teremos quando tivermos que desenha-las e colori-las.

Talvez o limão fosse o tamanho 1, será nossa referência de unidade, porque é liso, todo amarelo, o morango é menor, mas mais difícil de desenhar e colorir, por isso o 3, o abacaxi se equivale a abóbora grandona, bem maior, mas com shape menos complexo.

Isso não é muito diferente de software, as principais informações são as integrações, excepcionalidades inerentes a regras de negócio, sofisticação diferenciada, não queremos saber detalhes daquilo que é comuns, apenas do incomum.

Parafraseando Pareto e Juran, entre tantos detalhes triviais em cada tela de um sistema, haverá poucos detalhes vitais que as diferenciem em complexidade … uma percepção que se apura a cada experiência, porque afinal, estimativa se aprende estimando.

Já participei de projetos em que o time tinha alçada e decidiu não mais estimar, apenas discutir, entender e decidir quais caberiam em cada sprint. conforme prioridade e valor. Não é muito diferente dos outros tipos de estimativas, porque no final queremos apreender o que cabe ou não.

Mas por hora não entrarei muito nesta discussão, porque números, métricas, PxR e outras matemáticas ainda são necessárias para a maioria aprender, crescer e aperfeiçoar-se como profissionais … com números tudo fica um tanto mais explícito.