Quem nunca foi obrigado a responder àquela ingrata pergunta “Quanto tempo você leva pra desenvolver isso?”

Essa pergunta é mais comum do que se imagina. Eu mesmo já tive que respondê-la inúmeras vezes. A resposta na maioria das vezes é um chute, claro.

O que acontece é que, infelizmente, a realidade é um pouco diferente daquela que costumamos ver equivocadamente em alguns livros, blogs
e até cursos.

No mundo real as empresas cobram prazos. Fato! Mas se você pensar bem, isso é totalmente compreensível, não acha? Você como uma empresa, aceitaria desenvolver um projeto sem ter uma idéia estimada de quanto tempo ele vai durar, por quanto tempo irá precisar alocar as pessoas e quanto isso irá custar?

É claro que você pode trabalhar com contratos de escopo aberto (variável) e certamente você não terá alguns desses problemas, mas isso é assunto para outro post. 🙂

“Prazos impelem à ação. Sem um prazo, não há objetivo, apenas uma solicitação nebulosa que se acrescenta à confusão geral em andamento.” – Steve Chandler/Scott Richardson

Antes de mais nada, vamos supor que eu tenha pedido emprestado um livro a um amigo.

Ele é uma pessoa que não gosta muito de emprestar as coisas, mas como sou muito amigo dele, ele acaba me emprestando, mas com uma condição: que eu diga mais ou menos quando eu poderei devolvê-lo.

Eu poderia simplesmente chutar uma data qualquer, mas não quero fazer isso. Como ele é muito chato, prefiro dar uma informação um pouco mais embasada.

Então eu pego o livro nas mãos, analiso, dou uma olhada em algumas páginas e vejo que ele tem umas 100 páginas. Esse é o tamanho do livro.

Pela minha experiência, sei que normalmente consigo ler 10 páginas de um livro por dia, cinco páginas no caminho indo para o trabalho e outras cinco no caminho de volta. Essa é a minha velocidade estimada.

Agora eu divido o número de páginas (100) pela minha velocidade (10) e descubro que levarei aproximadamente 10 dias para ler o livro todo. Essa é minha primeira estimativa de duração.

“Estimar a duração de um projeto começa com a estimativa do seu tamanho” – Mike Cohn

Equipes ágeis normalmente estimam dessa forma como vimos acima, ou seja, primeiro estimamos o tamanho das histórias, depois estimamos a velocidade da equipe e por último estimamos (derivamos) a duração do projeto.

A partir de hoje, guarde essas 3 palavras: tamanho, velocidade e duração. Elas são a chave para uma estimativa e planejamento ágil.

Vamos supor que a empresa que eu trabalho foi escolhida para desenvolver um projeto e o cliente pediu que enviássemos uma estimativa de prazo.

Nós poderíamos chutar uma data qualquer, mas não queremos fazer isso, certo? Mas também não podemos perder muito tempo nisso porque o cliente quer uma resposta logo e não queremos perdê-lo.

Como a Product Owner já tem uma lista inicial de histórias, já podemos começar a estimar o tamanho de cada uma.

A equipe então espalha os cartões na mesa e seleciona a história que aparenta ser a mais fácil e atribui uma estimativa de 2 pontos a ela. A partir daí, começamos a estimar cada história restante comparando-a com as estimativas anteriores, sempre fazendo perguntas como: "Essa história é duas vezes maior que a história que estimamos em 1 ponto? Então podemos estimá-la em 2 pontos?", "Essa história é mais fácil que a história estimada em 5 pontos? Concordam em estimá-la em 3 pontos?".

Após estimar todas as histórias, somamos os pontos de cada uma e chegamos num total de 100 pontos. Esse é o tamanho do projeto.

Pela nossa experiência em projetos parecidos e com a mesma formação de equipe, sabemos que normalmente conseguimos fazer 10 pontos por Sprint de 2 semanas. Essa é a nossa velocidade estimada.

Agora dividimos o tamanho do projeto (100) pela nossa velocidade (10) e descobrimos que vamos levar aproximadamente 10 Sprints para desenvolver todo o projeto, o que dá um total de 20 semanas. Essa é nossa primeira estimativa de duração.

Pode, claro, tanto pra mais quanto pra menos. Tudo vai depender da velocidade; se ela vai aumentar ou diminuir durante esse tempo.

No exemplo do livro emprestado, a minha velocidade poderia aumentar caso eu começasse a passar mais tempo no trânsito e assim tivesse mais tempo de ler mais páginas por dia. Ou ainda poderia diminuir caso eu fosse acometido por uma dor de cabeça incoveniente durante uma semana e não conseguisse ler sequer uma página por dia.

A velocidade é o grande equalizador!

Chamamos de plano ágil porque estamos falando de um plano criado a partir de um planejamento contínuo, um plano que está preparado para mudar e responder às mudanças.

A velocidade da equipe pode mudar, o escopo pode aumentar ou diminuir, mas o plano será sempre atualizado e comunicado ao cliente a cada Sprint; tudo de forma bastante transparente.

• A reunião de estimativa do tamanho do projeto pode demorar mais do que o esperado dependendo da quantidade de histórias a serem estimadas. Sendo assim, é uma boa prática dividir essa reunião em sessões de no máximo 3 horas diárias cada.

• Na hora de selecionar a história mais fácil, não se preocupe se está realmente selecionando a história mais fácil de todas. O Product Owner também não precisa ler e detalhar todas as histórias pra você chegar a essa decisão. Use o sentimento aqui e siga em frente. Essa estimativa serve apenas de base para as outras. Lembre-se também que se você identificar outra história mais fácil, você ainda tem o 1 para usar.

• Não se atenha a todos os detalhes na reunião de estimativa de tamanho. Provavelmente o Product Owner não terá todas as respostas para todos os cenários possíveis. Isso é normal e aceitável em um projeto ágil. Sei que você deve imaginar que é impossível estimar uma história sem ter todos os detalhes, sem um wireframe, sem um documento com todos os cenários, mas acredite que isso é possível sim. Por exemplo, quando estimei que lia 10 páginas de um livro por dia, não considerei o tamanho da fonte. Se a fonte for muito pequena, provavelmente só vou conseguir ler 6 páginas por dia. Ou seja, se você perceber que estimou mal uma história, deixe que a velocidade conserte isso. A sua velocidade vai diminuir e você vai reestimar o projeto com base na nova velocidade.

• Quase nunca somos capazes de usar a experiência para estimar a velocidade da equipe, como fizemos no exemplo acima. Normalmente os projetos nunca são tão parecidos e a formação da equipe nunca é igual. Sendo assim, uma boa prática é fazer o primeiro Sprint Planning e somar os pontos das histórias que a equipe selecionou. O total dessa soma será a velocidade estimada.

Bem, espero ter contribuído de alguma forma com o seu aprendizado e qualquer dúvida, é só entrar em contato. Até a próxima! 🙂

Thiago Costa é coordenador de equipe de novos projetos na Acotel do Brasil, Certified Scrum Master (CSM) e desenvolvedor.

The post Dando prazos em projetos ágeis appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.