Planning Poker: Estatística ou Negociação?

Você que leu o título e, talvez, não entendeu direito o que uma coisa tem a ver com a outra. A ideia desse artigo é trazer na discussão esses dois pontos que aparentemente soam diferentes. Vamos decorrer de alguns conceitos que, talvez, parecem não fazer parte do nosso dia-a-dia. Entretanto, vivemos isso no cotidiano — negociação e estatística. Antes de começarmos essa jornada juntos, te proponho a se concentrar e, em cada parte da leitura, fazer uma analogia no seu dia-a-dia no processo de desenvolvimento de software.

Sem mais enrolação. Vamos lá!

A falsa matemática.

É comum do ser humano, em sua diversas experiências, achar que só porque utiliza números também está utilizando a estatística. Em desenvolvimento de software é comum usar escalas, como: Fibonacci (1, 2, 3, 5, 8, 13…); valores ordinários; ou até mesmos sequências como P, M e G para representar um valor de uma tarefa ou histórias. Esses números não tem relação com desempenho — estatística. Ou seja, não quer dizer que a partir desses números dá para calcular média, mediada, moda, desvio padrão. Isso porque essas metodologias estão relacionadas a negociação.

Pode estar pensando: “Como assim?! Até hoje eu aplico essas dinâmicas para obter os números e “metrificar” os times. Como não funciona?

Vou explicar! Inicialmente, colocando um monte de pessoas na sala e discutir se a tal história é 5, 8, 20 ou P, M, G está relacionada ao entendimento do que deve ser feito — e não o mérito da performance. Entrar num tal acordo onde as explicações divergem e algumas se sobressaem é cansativo. Quantas vezes nos deparamos que, caso o especialista fala que a história vale 5, todo mundo fala a mesma coisa — ele acaba usando a persuasão. Exemplos: “isso é o dobro do tamanho daquilo”; “é só criar 3 funções que já resolve.”; “se ele está falando, é isso mesmo.”. E essa certa confiança e persuasão ocultam um conceito muito interessante.

Efeito Dunning-Kruger

Não é porque a pessoa fala que sabe e convence que sabe, quer dizer que ela sabe.

Esses é um dos conceitos mais interessantes que quero trazer na nossa discussão. No desenvolvimento de software existem muitas (põe muitas) variáveis externas que são relevantes para afirmar que uma atividade é fácil, tem escala M, pontuação 5, etc. Isso está relacionado na percepção individual e não no coletivo. Isso mesmo! Ou seja, o especialista convence que a pontuação da história é 5 ou se a tarefa é P, mas o desenvolvedor júnior é a pessoa que vai realizar a atividade. Então, foi pro ralo essa pontuação. Pois, pessoas fazem parte do processo e estão inseridas no desenvolvimento. Não serviu como base para nenhuma comparativa. Fatores externos influenciam e não são trazidos para essa dinâmica de negociação.

Mas você pode estar pensando: “Durante as interações levantamos várias situações externas, etc.”
Realmente, pode ser que sim. Mas, no final, sempre vai acabar com um acordo para uma tal pontuação.

Se a intensão é promover uma dinâmica de interações, eu aconselho não usar pontuações ou algo do tipo. Isso pressiona as pessoas. Use frases que estimulam o conhecimento. Como:

• Quais as dificuldade acredita existir nesse desenvolvimento?

• Quais cenários de erros são possíveis para essa funcionalidade?

• Quais são as influências externas para essa tarefa?

Utilize estratégias de empoderamento. Use e abuse de documentações, diagramas e fluxogramas. Construa um documento que diariamente (ou periodicamente) evolua o entendimento de todos — isso eleva a maturidade das pessoas. Dissemine o conhecimento sem a necessidade de estabelecer rankings, scores e pontuações.

Deixo a dica de um vídeo bem interessante sobre uma documentação chamada Design Doc — e, também um artigo.

Prevendo o futuro (ou não)

Até aqui é tudo muito lindo, muito bonito. Mas precisamos saber quando vai ser entregue tal tarefa. Quando vai lançar em produção tal funcionalidade.

Novamente, começo o a explicação falando que é comum da história do ser humano querer “prever o futuro”. Quantos rituais históricos de diversas culturas conhecemos que servem para adivinhar o acontecimento. E, você acha que a tecnologia da informação ficaria fora disso?

Quando um grupo de pessoas ou, às vezes, apenas uma pessoa fala que uma funcionalidade vai ser entregue em 4 semanas de trabalho simplesmente porque conhece é a armadilha certa para cair na Lei de Goodhart. Parafraseando-o: “Quando uma medida torna-se uma meta (ou alvo), ela deixa de ser uma boa medida.”

Ou seja, isso não é previsão de nada. Simplesmente, cria uma expectativa de um certo prazo e vira uma meta a ser cumprida. E sabemos que meta a ser cumprida a qualquer custo em desenvolvimento de software é uma decisão muito arriscada.

A Verdadeira Estatística: As Métricas DORA

Enquanto as estimativa tentam adivinhar a performance com opiniões, as métricas DORA olham para a realidade empírica do desempenho do time.

Se você quer saber o nível de maturidade e eficiência de um time, deverá aplicar as métricas: Frequência de Deploy; Tempo de espera para as Mudanças; Taxa de Falha em mudanças; e, Tempo de Restauração.

Essas 4 métricas são consideradas ideais para avaliar se um time é considerado baixo, médio ou alto desempenho. Anualmente, é apresentado o estudo Accelerate State of DevOps para apresentar os números e estudos atuais.

Por final, se quiser saber o tempo de entrega de uma determinada funcionalidade é importante obter o cycle time de cada etapa do fluxo de desenvolvimento e identificar as estatística de moda, mediana, média, desvio padrão. Ou seja:

“O time tem uma média de entrega de 1 funcionalidade a cada 7 semanas; Sendo que normalmente (moda) entrega em 4 semanas; Porém, metade delas (mediana) consegue entregar em 5 semanas; Mas, quando tem muitos impedimentos e problemas externos, temos os pontos fora da curva (outliers), que chegam a puxar o prazo para até 13 semanas.”

Perceba que fica mais claro para analisar o desempenho e gerenciar as expectativas dessa forma — muito melhor do que falar que em 4 semanas vai entregar tal coisa. Ainda de sobra, é possível identificar os problemas de cada etapa de desenvolvimento e trabalhar para melhorá-los.

Não pense que acabou, deixarei dois artigos aqui para você se aprofundar.

Como melhorar a eficiência de fluxo — Parte 1

Como melhorar a eficiência de fluxo — Parte 2

Até um próximo artigo!