A Taller é uma empresa de desenvolvimento de software ágil e lean (enxuto). Na Taller nós valorizamos os indivíduos e as interações entre eles mais do que os processos e ferramentas e nós preferimos responder às mudanças do que seguir um plano. Softwares são sistemas complexos e, por isso, seu desenvolvimento é muitas vezes difícil de ser medido. Sendo assim, traduzimos este conteúdo que trata de estimativas de previsões em desenvolvimento de software, com o intuito de compartilhar com você um pouco da forma como trabalhamos, pois ele se “encaixa como uma luva” no que acreditamos quando se fala de estimativas no desenvolvimento de sistemas.
Eu gosto da pirâmide de cliente que David Bland sugeriu. Sempre que estou discutindo uma ideia para um produto com nossos potenciais clientes, costumo pensar neste termos. Na maioria das vezes as pessoas saltam para a construção de uma coisa/parte, sem realmente validar se o problema existe mesmo.
Há um problema na nossa área, embora isso seja quase universalmente uma dor de cabeça. Não só existe, mas as pessoas iriam adorar ver uma solução razoável. O problema é estimativas.
Há uma discussão acalorada em curso sob o rótulo de #NoEstimates. Este rótulo é enganoso, embora as pessoas tendam a juntar um monte de idéias diferentes, as vezes incoerentes, a respeito desse assunto. Ao mesmo tempo, o conhecimento das abordagens disponíveis é muito limitado.
Palpite de especialista
Uma opção que a maioria escolhe na falta de outras ideias é perguntar a alguém com conhecimento por um palpite inteligente. Supomos que alguém com experiência no assunto daria estimativas de qualidade.
A falácia do planejamento, descrita por Roger Buehler mostra que nós falhamos ao estimar tarefas que temos experiência a respeito. Não apenas isso — mais experiência em fazer tarefas parecidas não ajudam a melhorar as estimativas.
Não significa que não podemos mudar a qualidade das estimativas fornecidas pelos especialistas. Douglas Hubbard argumenta que o processo de calibração pode melhorar significativamente a qualidade de tais estimativas. Essa técnica não parece ser nem remotamente conhecida e muito menos popular, na indústria de software.
Story Points e Velocidade
Times ágeis quase universalmente devem saber sobre estimativas porStory Points combinado ao acompanhamento da Velocidade. Utilizando a medida abstrata dos Story Points em teoria nos faz focar no tamanho relativo das tarefas. Nós evitamos pensar quanto tempo real seria necessário para a construção de cada uma das tarefas. Dan Kahneman em seu profundo livro Thinking Fast and Slow lista um número de tendências que tornam muito difícil para nossos cérebros chegarem a estimativas razoáveis baseadas em tempo.
Nós usamos Velocidade, que é o número de Story Points finalizadas em um período de tempo, para descobrir o progresso e planejar a continuação dos trabalhos.
O grande valor que obtivemos pelo uso desta técnica foi a introdução do uso de dados históricos para projetar o trabalho futuro. Fundamentalmente, nós usamos o histórico de Velocidade para chegar a uma ideia sobre o quanto uma equipe pode realizar no próximo período de tempo.
Ao mesmo tempo, há muitas disfunções tipicamente observadas com esta abordagem. Além do mais, depois de estudar os dados de dez mil equipes Ágeis, Larry Maccherone reportou que a Velocidade não é melhor em descobrir o ritmo do progresso do que simplesmente contar funcionalidades concluídas (produção). Só recentemente Steve Rogalsky relatou o mesmo depois de medir Velocidade e produção por mais de um ano.
Dimensionamento
Uma ideia um pouco mais abstrata é usar outras formas de dimensionamento diferentes de Story Points. O mais popular é o t-shirt:P, M, G, etc. Normalmente os tamanhos não são números que podemos simplesmente comparar um com o outro.
Isso cria um desafio que, por sua vez, nos dá uma ideia mais clara sobre os itens de trabalho que já construímos. Precisamos calcular quão maior um item de “tamanho G” é comparado a um “tamanho M”. Isto significa uma análise mais aprofundada dos dados históricos para descobrir as diferenças.
Sabemos mais, no entanto o argumento de Larry Maccherone ainda é válido. O dimensionamento não parece ser melhor para avaliar o ritmo de trabalho do que uma simples medição da vazão.
Vazão
Vazão (um número de itens concluídos num dado tempo) é provavelmente a medida mais leve que pode ser usada para estimar o trabalho. Neste caso nós não estimamos itens individuais de qualquer forma. Nós apenas nos baseamos em um grande número de funcionalidades e algumas percepções que obtemos depois de analisar os dados passados.
Há uma melhoria desta abordagem que eu considero de grande valor. Durante as discussões sobre o dimensionamento ou Story Points às vezes há um argumento que um item de trabalho é muito grande e deveria ser dividido em partes menores. Outro argumento semelhante é quando uma equipe realmente não tem ideia sobre uma funcionalidade. Isso torna tal funcionalidade mais arriscada.
É por isso que minha escala favorita para funcionalidades ou história é: 1, grande demais, não tenho ideia. Você pode comprar um baralho com estas cartas se quiser um.
Esta abordagem limita a discussão sobre a estimativa para o mínimo e ainda fornece informações valiosas sobre itens de trabalho.
Simulação
Passo-a-passo nós evoluímos do uso de suposições ou avaliações individuais e nos baseamos mais em dados históricos. E podemos fazer ainda melhor. Uma abordagem seria medir a vazão semana após semana. Isso nos equipa com uma gama de valores possíveis de vazão e baseado nisso podemos chegar ao pior e ao melhor cenário possível.
Desta forma nós poderíamos obter um intervalo de estimativa. Que é melhor que uma estimativa de pontos. Contudo, podemos fazer ainda melhor que isso.
Podemos usar simulações estatísticas, conhecidas como o método Monte Carlo, para simular diversos resultados possíveis. Dado que nós teríamos milhares de dados de pontuação, eles iriam formar uma distribuição de possíveis resultados. Podemos usar isso para prover uma probabilidade de que estaríamos prontos em certa data a partir de todas as datas disponíveis, por exemplo, há 60% de chance de que iremos estar prontos ao final de Março, 70% de chance de que será na metade de Abril, etc.
Agora já temos algo significativo. Não é apenas um simples intervalo. É uma lista compreensiva que mostra um monte de possíveis cenários futuros.
Tempo de ciclo e trabalho em progresso
Há mais, porém. No caso anterior nós utilizamos vazão como a mais simples métrica de proxy disponível. No entanto, temos dados históricos mais significativos que podemos utilizar.
O tempo de ciclo é o tempo decorrido desde o início do trabalho em certa funcionalidade até ela ser finalizada. O trabalho em progresso (WIP – work in progress) é o número de itens que foram iniciados e não foram finalizados até o dado momento. Uma coisa boa é que nós só precisamos de duas datas por item de trabalho para calcular ambos, tempo de ciclo e WIP: data de início e data de fim.
Um grande ganho de tal estratégia é que podemos começar uma simulação mesmo com uma amostra de dados razoavelmente pequena. Não precisamos esperar longas semanas até ter dados suficientes para a vazão. Também se leva em conta a situação atual. Nós veríamos diferentes dinâmicas e previsibilidade em um time com um monte de trabalho em progresso e longos tempos de ciclo e times que limitam o WIP e tem tempos de ciclo curtos.
Para aqueles que desejam se aprofundar sobre como essa simulação pode ser feita, recomendo Forecasting and Simulating Software Development Projects, do autor Troy Magennis.
Estimativas e Previsões
No título do post me referi tanto a estimativa quanto a previsão. Até agora me referi apenas ao primeiro. Qual é a outra coisa, então? As últimas abordagens, que empregam simulação estatística em vez de palpites de especialistas, são normalmente chamados de previsão.
Onde exatamente acaba a estimativa e se inicia a previsão no caminho que eu acabei de guiá-lo? Pessoalmente, eu não acho que a resposta para esta pergunta é o que importa. O que importa é estar consciente dos métodos e conhecimentos disponíveis e entender como eles funcionam.
Aliás, essa é a razão pela qual eu não estou muito envolvido na discussão de #NoEstimates, mesmo se algumas coisas que eu fomento, por exemplo a escala de estimativas ou simulações 1 / Grande demais / Não faço idéia, sejam freqüentemente rotulados assim.
Quando eu falo sobre previsões, e eu apenas falei superficialmente sobre isso, frequentemente escuto um comentário. As pessoas mencionam que isso parece atraente mas bastante complexo. Seria ótimo se alguém pudesse testar os resultados produzidos sem investir muito trabalho pesquisando todos os detalhes.
Bem, eu tenho ótimas notícias. Na Lunar Logic estamos rodando alguns experimentos sobre previsão e estamos procurando times e organizações que queiram testar alguns resultados iniciais. É bastante simples – baseados em alguns dados históricos nós provemos a previsão para o próximo lote de trabalho e então validamos a qualidade da previsão juntos. Me mande um e-mail se estiver interessado.
** Esta é uma tradução livre do post Estimation and Forecasting, de Pawel Brodzinski.
Sobre o autor do texto original
Pawel Brodzinski lidera a Lunar Logic, uma empresa de software Web na Cracóvia, Polônia, que é um exemplo de sucesso da implementação dos métodos de gestão que ele escreve sobre. Executar um projeto com a Lunar Logis é, portanto, sempre uma experiência interessante. Pawel é um líder, um formador de equipes e um agente de mudança, mas acima de tudo ele é um profissional que sempre experimenta, tentando fazer suas equipes trabalharem melhor (e aprender no processo). Ele é um orador público bem reconhecido e blogueiro que compartilha seus pensamentos sobre os métodos de gestão.