Rafa Nascimento

Fibonacci com Pimenta, Parte 2

Posted in ágil, estimativa by Rafa Nascimento on 22/04/2011

No post anterior sobre estimativa de projetos de desenvolvimento de software utilizando os números de Fibonacci, conhecemos a origem dos números, o motivo que cria a sequência como ela é e por que é mais fácil para nós, seres humanos, estimar por relativismo e não por absolutismo. Neste novo post, veremos como estimar projetos de desenvolvimento de software utilizando Story Points, como monitorar o andamento do projeto com eles (e motivar seu time) e, enfim, como responder as perguntas capitais: quando o software estará pronto e quanto irá custar.

Quando falamos em estimativa, buscamos informações de experiências prévias sobre o que queremos estimar que nos embase o suficiente para sermos satisfatoriamente assertivos. Porém, no mundo do software, é extremamente difícil haver experiências suficientemente parecidas que nos permitam ser assertivos ao ponto de não termos um prejuízo considerável ou perdermos um prazo. Sim, é possível acertar estimativas sob estas condições e ter, assim, projetos de sucesso. Mas as estatísticas mostram que o percentual destes projetos não passa de 50%. Um índice perigoso quando se trata, por exemplo, de um projeto de desenvolvimento de um software que objetiva melhorar um processo de densitometria óssea. Um projeto de construção civil; um prédio residencial, altamente previsível, por sua vez, beira os 100% de assertividade. Ou seja, para que sejamos capazes de ser assertivos em nossas estimativas de projetos de desenvolvimento de software, precisamos de projetos previsíveis. Projetos que se repetem, que têm muito em comum. Como isso é quase impossível na nossa área, precisamos monitorar o nosso caminho. Literalmente, andar pisando em ovos. As condições que precisam ser criadas em prol da previsibilidade de um projeto de desenvolvimento de software (um mesmo time que já passou por diversos projetos junto e adquiriu experiência suficiente como um time em sua existência) são poucos, insuficientes para tornar nossas estimativas assertivas, e nos obrigando a monitorar a saúde de nossos projetos e estarmos preparados para tormarmos decisões rápidas sobre o destino do mesmo. Em comparação ao futebol, há quanto tempo não se vê um time supercampeão no Brasil? A rotatividade, o “não conseguir manter a base do time” não permite mais que isso aconteça. Bem como nos times de software. Então? É ou não é ser previsível, por mais matemáticos que sejamos?

Usando Story Points para estimar trabalho

Já sabemos que somos melhores estimando por relação entre objetos do que usando números exatos. Então, como podemos usufruir de nossa natureza em prol de nossos objetivos na construção de software? Simples: Usando Story Points, que se baseiam nos números de Fibonacci. Para isso, basta atribuirmos “pesos” aos requisitos de nossos projetos baseando-nos nos Story Points (0,1,2,3,5,8,13,20,40,100). Esta sequência está presente em muitos decks comercializados de Planning Poker, um jogo para intermediar a estimativa de construção dos requisitos de um software que visa facilitar a colaboração em um time. Porém, em seu último post, Ken Schwaber defende que a estimativa use a real natureza dos números de Fibonacci. Ou seja, não teríamos 20 na sequência de Story Points, e sim 21. E o próximo número não seria 40, mas sim 34. E concordo com ele, pois a natureza dos números de Fibonacci já é suficiente para deixar claro o peso de cada requisito. Não há necessidade de adaptação.

Para testarmos a estimativa com Story Points, imaginemos o seguinte projeto: um time precisa ler 4 publicações, conforme abaixo:

Se as publicações são completamente desconhecidas pelo time, a probabilidade de haver falhas na estimativa deste projeto é bem alta. Se alguns membros do time conhecem algumas das publicações, as chances de o time acertar a estimativa aumenta. Se todos conhecem as publicações, as chances de sucesso do projeto são altíssimas, pois o método para atingir o objetivo já é bem conhecido por todos: ler. Se um membro do time não sabe ler, isso ficará evidente em uma rodada de Planning Poker. E como funciona uma rodada?

O Planning Poker é um jogo colaborativo que favorece a criação de consenso dentro de um time sobre a estimativa de tamanho de um determinado trabalho e ajudar a descobrir riscos no projeto. Todos os membros do time escolhem, individualmente, sua estimativa para cada requisito que lhe é apresentado em uma reunião de detalhamento e planejamento para a construção de requisitos. Suas escolhas são mantidas em segredo, para que um membro não influencie o outro. E, por fim, as estimativas são apresentadas, todas de uma só vez. Diferenças entre as estimativas fatalmente aparecerão, o que leva à necessidade de um melhor entendimento, pelo time, do requisito, e a rodada é repetida até que o entendimento pelo time sobre o requisito esteja homogêneo. Isso ajuda, no caso do nosso projeto, a descobrir quem já tem experiência em ler determinada publicação e pode ajudar o time e que membro do time não sabe ler, o que pode ser um risco para o projeto e precisa ser tratado.

Para mim, ler o livro sobre CMMI teria uma pontuação de 20. Já para um companheiro, seria 8, pois ele já leu algumas partes e eu nunca peguei no livro. Então, entramos em um consenso de que a estimativa para lermos o livro sobre CMMI pode ser 13, porque os membros do time que conhecem o livro terão a carga extra de ajudar os que desconhecem. E, os que desconhecem, terão a carga extra de chegar ao mesmo nivel dos demais.

Ora, se o livro sobre CMMI tem 13 pontos de peso, ler a revista Caras não pode ser um esforço do mesmo tamanho. Porém, dependendo da experiência prévia do time, o livro sobre Orientação a Objetos pode chegar ao mesmo nível de esforço do livro sobre CMMI. Como podemos concluir, estimar depende muito da experiência prévia do time que executará as tarefas. Este projeto pode ter uma pontuação total de 30 para o meu time. Mas, para o seu, pode ser 20. Quanto tempo um time leva para atingir 30 ou 20 pontos? Mais uma vez, depende da experiência prévia destes times. Meu time pode levar 1 semana para atingir 30 pontos. Seu time pode levar o mesmo tempo para atingir 20 pontos. Então, devemos aprender a montar supertimes? Não. Temos que aprender a promover o crescimento individual de cada membro dos nossos times e reter, assim, os talentos necessários para o sucesso de nossos projetos.

Navegando por mares bravios: Se vigiamos os marinheiros, o mar nos surpreende

O sextante é uma ferramenta de navegação que permite saber o quão próxima uma embarcação está de seu destino. Se o capitão desta embarcação se preocupasse em saber se todos os seus marinheiros estão trabalhando como deveriam e se o estão fazendo da forma “correta”, esta embarcação teria grandes probabilidades de nunca chegar ao seu destino. Afinal, quem estaria no encargo de manter a embarcação na sua devida rota e motivar seus marinheiros informando-os do resultado de seu trabalho em prol do cumprimento do objetivo, que é a sua chegada a um local pre-determinado? Ainda há a enorme possibilidade de uma tempestade surpreender o capitão controlador, pois não estaria engajado em cumprir com seu objetivo, que não é manter seus marinheiros ocupados, mas guiar a todos de forma segura e competente ao seu destino. Portanto, em nossos projetos de desenvolvimento de software, nossa única preocupação é medir o quanto de software produzido com qualidade tem em mãos, para que, dentro do prazo acordado com nosso cliente, lhe entreguemos seu produto.

Progresso = Software funcionando. Foco no valor do software para o negócio, não no cronograma
Responder às questões “quanto custará”

e “quando ficará pronto” em um projeto de desenvolvimento de software é análogo a navegar uma embarcação. É necessário progredir, ou seja, ter software funcionando com qualidade, para que consigamos saber em que data conseguirá entregar o software a cada momento do ciclo de vida de um projeto e quanto isso custará. Diante de uma data previamente definida por nossos clientes, precisamos ajustar o escopo do projeto para que os requisitos de maior valor de negócio para o nosso cliente sejam priorizados, e, assim, consigamos satisfazer suas expectativas. Por isso, é de suma importância a participação ativa do cliente no projeto. Concluimos que tentar responder a estas perguntas no início de um projeto (certas vezes, até antes do início) é impossível. É um chute, qualquer que seja o método utilizado, em se tratando de software. Fatalmente, esta estimativa será atualizada durante o andamento do projeto. E os métodos ágeis de desenvolvimento de software prevêem este fato. E focam todo o esforço dedicado a um projeto na entrega o mais breve possível de valor para o cliente em forma de software, e não nos ajustes do cronograma e do tamanho do time em um projeto focando um plano criado no início do mesmo.

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.

%d blogueiros gostam disto: