Rafa Nascimento

Fibonacci com Pimenta, Parte 1

Posted in ágil, estimativa by Rafa Nascimento on 16/03/2011

Planejamento de projetos de software buscam responder a 2 simples questões:

  • Quanto vai custar?
  • Quando estará pronto?

Não somente projetos de software, mas qualquer projeto de prestação de serviço, têm dificuldades para responder a estas questões. Isso por conta do grau de empirismo envolvido nestes projetos. Na construção de um prédio, de um carro ou na fabricação de um pacote de biscoitos, o grau de empirismo é muito baixo. Por estes projetos clássicos terem uma visão muito clara de seus objetivos finais, sua previsibilidade, incluindo margem de erro, é extremamente apurada. Em projetos de prestação de serviço, onde geralmente precisamos conhecer o ambiente, cotidiano, cultura ou negócio do nosso cliente, ou seja, fatores um tanto quanto fora de nosso controle, a previsibilidade decresce consideravelmente. Além da vertical “objetivo”, projetos de software trazem consigo outra vertical que acabam por criar o nível de insucesso mostrado no gráfico do StandishGroup abaixo, chamado Chaos Report: tecnologia. Sua evolução extremamente rápida neste mercado traz mais um dificultador para fazer previsões.

Sendo assim, podemos afirmar que projetos de software nada mais são do que gestão de conhecimento: conhecimento sobre o negócio de nossos clientes, ou do que vamos desenvolver, e conhecimento tecnológico, sobre como vamos desenvolver. Gerir estas 2 vertentes perante inúmeras possibilidades de aplicação de tecnologias que não cessam sua evolução e a constante evolução do próprio negócio de nossos clientes tornam o grau de previsibilidade de um projeto de software extremamente baixo.

Existem diversos métodos, científicos ou não, para estimar a duração e o custo de um projeto de software. Nenhum é exato. E a prática comum, e por si só equivocada, de transformar estimativas, que segundo o dicionário são cálculos aproximados, em compromissos se torna uma prática ainda mais equivocada no mundo do software, onde há empirismo por todos os lados. E as cobranças sobre este pseudo-compromisso acabam por minar, em muitos projetos, qualquer possibilidade de prever seu andamento futuro, ou até mesmo a possibilidade de conclusão. E o pior: desmotiva os times de desenvolvimento, que, normal e erroneamente, nada tem a ver com as estimativas.

Projetos ágeis de desenvolvimento de software costumam tratar estimativas simplesmente como estimativas, e criam mecanismos que permitem monitorar seu custo e duração durante todo o seu andamento, tornando estas informações visíveis e frequentemente atualizadas, desde o início do projeto, para os clientes. Para que seja possível ser previsível sem ser exato, estimativas ágeis utilizam-se de 2 ferramentas: o conhecimento prévio de negócio e tecnologia de um time que já trabalhou junto em, pelo menos, 1 projeto, e um método de pontuação de requisitos famoso por não se preocupar com a exatidão, e sim com o consenso conseguido através da experiência de um grupo de profissionais: Story Points, baseados nos números de Fibonacci.

Por que Fibonacci?
Segundo Mike Cohn, em seu livro Agile Estimating and Planning, estudos mostram que somos melhores estimando coisas dentro de uma determinada ordem de magnitude (Miranda 2001; Saaty 1996). No seu bairro, provavelmente você é capaz de estimar razoavelmente bem a distância relativa de coisas como a padaria mais próxima, a banca de jornais mais próxima ou a escola mais próxima. A escola pode estar duas vezes mais longe do que a padaria, por exemplo. Suas estimativas serão muito menos assertivas se você tiver que estimar a distância relativa para a lua ou para a capital de outro país. Porque somos melhores dentro de uma determinada ordem de magnitude, seria melhor se pudéssemos basear nossas estimativas sempre desta forma.

Os números de Fibonacci (0,1,1,2,3,5,8,13,21…) são muito úteis neste tipo de estimativa. Os intervalos entre os números se tornam apropriadamente longos à medida que os números crescem. Por conta desta interessante caracterísctica, inclusive, há quem veja relações dos números de Fibonacci com a Proporção Divina. O intervalo entre 1 e 2, bem como o intervalo entre 5 e 8, parecem respectivamente apropriados. Traduzindo para o mundo do software, quanto maior a pontuação de um requisito, maior o intervalo entre a pontuação do requisito e o número anterior. Este intervalo sugere o grau de imprevisibilidade do esforço envolvido no desenvolvimento do requisito. Ora, prever o quão custoso e arriscado deve ser desenvolver um requisito é tudo o que um gestor precisa saber para que possa tomar as medidas cabíveis contra os riscos envolvidos e garantir que o time tenha condições de desenvolver aquele requisito com sucesso.

Respondendo às perguntas
Em suma, mais importante do que acertar, no início de um projeto de software, o quanto ele deve custar ou quando terminará, é prover nossos clientes de transparência e informações suficientes sobre o projeto para que eles possam reagir adequadamente às novidades que costumam surgir durante este tipo de projeto. Na próxima parte deste artigo, veremos como estimar com Story Points e o que é necessário para transformar estas estimativas em um horizonte para nossos clientes.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: