Os métodos ágeis e as estimativas de projeto

Métodos ágeis dentro da gestão de projeto é algo recente, no entanto todos já ouviram pelo menos uma vez na vida a palavra daily ou daily scrum. Mas você sabe por que ela existe? 

Nessa série de dois artigos vamos viajar um pouco através do tempo e conhecer um pouco sobre os rituais e artefatos do Scrum. 

Vamos lá? 

Em 1975 Frederick Brooks (que vou chamar só de Fred, OK?) lançou a sua icônica obra “O mítico homem-mês” onde apresenta vários ensaios narrando suas facetas no desenvolvimento do sistema operacional System/360 da IBM. Esse livro é muito famoso por causa da famigerada Lei de Brooks, tão citada nos livros atuais de engenharia de software. 

Pois bem, o Fred trás nesse livro que quando se trata de desenvolvimento de software não podemos [ou não deveríamos] usar a unidade de medida “homem-mês” para criar estimativas, simplesmente por que não temos como dividir uma mesma tarefa de desenvolvimento para várias pessoas. 

Concordam que fica estranho ter uma tarefa X onde os desenvolvedores A e B estão desenvolvendo simultaneamente, certo? É diferente de uma colheita onde várias pessoas podem estar fazendo uma mesma atividade simultaneamente. 

Então, se uma feature X leva 20 dias, nós podemos quebrar ela em 20 outras tarefas de forma que várias pessoas possam trabalhar nessas ao mesmo tempo, para fins de exemplo: Para quebrar essa única tarefa de 20 dias em 20 tarefas de 1 dia, nesse caso conseguimos vários desenvolvedores trabalhando ao mesmo tempo e terminamos a feature X em 1 dia, cada um codificando uma tarefa. 

Problema resolvido! Só que não. 

Quando dividimos a feature X em 20 subtarefas, também amarramos essas pequenas tarefas tornando cada uma dependente da outra e quando adicionamos mais pessoas a um projeto com esse cenário o esforço de comunicação entre as partes tende a aumentar. Caso ignoremos a comunicação teremos uma torre de babel e, se você conhece essa história, não vai querer que seu software tenha o mesmo destino dela né? 

Então cada desenvolvedor não levará 1 dia para ver a sua tarefa, ele levará 1 dia + o tempo dedicado para comunicação com os outros 19 desenvolvedores. E isso atrapalha muito! Principalmente se o prazo já estiver estourado. O Fred até apresenta a fórmula de n(n-1)/2 para definir o esforço investido somente na comunicação entre os desenvolvedores.

Seguindo nosso exemplo, se 2 desenvolvedores precisam de 15 minutos para fazerem alinhamentos sobre o que está sendo desenvolvido, 20 desenvolvedores precisariam de 47 horas, inviável não é mesmo? 

Agora peguem esses 5 dias a mais e coloquem para cada tarefa (1 dia da tarefa + 5 de reuniões de alinhamentos) * 20 tarefas. Se mantivermos os 20 desenvolvedores, a feature X será entregue em 6 dias e não mais em 1 dia, isso é um aumento de 600% ou 6x na estimativa real. 

Agora temos uma estimativa mais coerente com a realidade. Certo? 

Não, temos ainda outro problema que só existe no desenvolvimento de software que pode colocar qualquer estimativa no lixo, esse problema se chama bugs! 

É impossível prever a quantidade de bugs que um sistema vai apresentar e normalmente somos otimistas, estimamos o sistema redondinho, mas quando chega na hora de testar começa a aparecer retrabalhos, que acaba consumindo tempo de desenvolvimento não previsto no cronograma original. É necessário deixar um tempo considerável para testes e para a correção dos erros encontrados nessa etapa. 

Fred relata que um dos problemas quanto aos testes de software é exatamente o curto tempo deixado para esta fase. Normalmente eles extrapolam para 50% do cronograma real. 

Então agora temos 1 dia da estimativa real + 0,5 dia para testes = 1,5 dias + 5 de comunicação = 6,5 dias 

Uma feature que com 20 pessoas deveria levar 1 dia, passou a ter uma estimativa de 6,5 dias. 

Seria bom se esse fosse o único problema… 

Vimos em nosso exemplo que se considerarmos o esforço de comunicação e ainda o tempo necessário para os testes, os prazos vão ultrapassar em 600% o tempo estimado inicialmente, e tempo, meu caro leitor… é dinheiro. 

Nem sempre o prazo que damos é o prazo que temos, muitas vezes o cliente quer que o produto seja entregue antes deste prazo, o cliente realmente quer que seja entregue em 1 dia e não nos 6,5 que calculamos nos itens anteriores. E quase sempre prometemos entregar antes do prazo estimado por pressão do cliente e/ou falta de dados que comprovem o prazo inicial. Fred chama isso de Estimativa desembasada.

Para evitar esse tipo de problema é necessário dados que embasem essas estimativas, sair do achismo e começar a mostrar o por quê a feature X tem que ser entregue em 6,5 dias e não em 1. 

Fred coloca como sugestão de dados que precisam ser desenvolvidos e publicados para embasar uma estimativa: os números de produtividade, números de incidência de erros, as regras utilizadas para estimativa, etc.. 

E devemos considerar esses números ao estimar, claro! 

Agora sim, temos uma estimativa precisa! 

Ainda não, o Fred escreveu isso em 1975 e deixou bem claro que não existe bala de prata para acertar um cronograma, todo e qualquer projeto vai atrasar por que é a realidade, não temos como prever a internet que cai, o temporal que destruiu a cidade ou simplesmente aquele dia que o desenvolvedor, assim como qualquer outro artista, acordou indisposto para criar ou até mesmo por motivo de doença. 

Então acredite, um projeto sempre vai atrasar! 

A questão não é SE vai atrasar e sim QUANDO vai atrasar. 

Para você refletir eu deixo uma pergunta, que responderei no próximo artigo:

O que fazer quando um cronograma atrasa?