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.

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: