Estimando esforço de forma ágil

ESTIMATIVAS ÁGEIS

Estimar um projeto é um processo um tanto complexo. No entanto, é uma exigência sempre presente, afinal, nenhuma empresa inicia um projeto sem ter nenhuma dimensão, ainda que vaga, de quanto tempo, esforço ou recursos serão necessários para sua execução. Já que não podemos fugir desse cenário, vamos compreender um pouco melhor as razões que levam estimativas usuais a falharem, bem como formas de estimar projetos, do ponto de vista ágil.

Por que estimativas falham

Antes de chegarmos ao objetivo, porém, é preciso compreender as razões pelas quais as estimativas falham. Pode parecer óbvio, mas o fato é que estimativas falham por definição. Pois elas não são nada mais do que aproximações. Procuramos uma aproximação do tempo, ou custo, para se construir algo que ainda não foi produzido, que possui incertezas, e portanto criamos algumas suposições e hipóteses.

O problema é como se faz uso das estimativas dentro do planejamento de projetos.

Primeiro, as pessoas buscam previsibilidade. Mas ingenuamente acreditam que quanto mais tempo investirem estimando, mais próximas dos valores reais de duração ou custo das atividades elas estarão. Só que chega um momento em que investir mais tempo estimando não produz melhores resultados, virando desperdício (Lei dos rendimentos decrescentes). Abordagens ágeis aceitam que estimativas são imperfeitas por natureza, e buscam abordagens leves e rápidas para atingir bons resultados de forma eficiente.

O segundo problema é que, ao acreditar que suas estimativas estão ótimas (afinal muito esforço foi investido), as pessoas convertem as estimativas em metas e acreditam que ao final do projeto irão conseguir atingir a meta em cheio! Ignoram que as estimativas possuem incertezas. Ignoram que imprevistos ocorrem durante o projeto. E que as necessidades do cliente mudam. Não é a toa que projetos executados nessa abordagem quase nunca atingem satisfatoriamente a meta estabelecida. As metodologias ágeis aceitam a imperfeição das estimativas e as mudanças que ocorrem ao longo dos projetos, e por isso inspecionam e adaptam as estimativas durante o projeto.

Abordagem ágil para estimativa de esforço

“Em um projeto ágil, estimar é uma atividade contínua. É preciso monitorar o progresso e adaptar as estimativas com o aprendizado do time.”

Um ponto fundamental quando falamos de planejamento e estimativa ágil é que nós estimamos o esforço, ou tamanho, das atividades. A duração do projeto é uma derivação da estimativa e do progresso do time.

Existem duas abordagens muito utilizadas para a estimativa de esforço, Ideal Days e Story Points. Vamos analisar cada uma delas para então entendermos o conceito de velocidade, e a sua função na correção das estimativas.

Dias ideais (Ideal Days)

Estimar o esforço para desenvolvimento de alguma funcionalidade em dias ideais significa tirar todo o overhead da equipe, como participação em reuniões, envio de e-mails, atender telefonemas, entre outras atividades, considerando a sua dedicação total à atividade.

Exemplo: “São necessários 4 dias de trabalho para concluir aquela rotina de importação de pedidos do sistema.”

Quando medimos o tamanho de uma atividade em dias ideais, ainda estamos atrelados à noção de tempo. Essa é uma boa estratégia, mas apresenta alguns pontos negativos. Por ser associada ao tempo, diversos fatores podem influenciar as estimativas ao longo do projeto. Com a evolução da experiência do time, competências adquiridas, mudanças de frameworks, por exemplo, o mesmo time agora entende que uma nova importação similar àquela anterior pode ser concluída em 3 dias. A base de estimativa mudou, e com isso o histórico fica prejudicado.

Pontos (Story Points)

Uma outra forma de se estimar esforço é através da atribuição de pontos para as funcionalidades de um sistema. Essa técnica é muito utilizada com Histórias de Usuário, mas pode ser utilizada com outras práticas de especificação de requisitos também.

Nessa estratégia se atribui uma pontuação para o tamanho de cada funcionalidade. O valor que se atribui é pouco relevante. O que importa é que as pontuações das funcionalidades sejam coerentes entre si, quando comparamos cada funcionalidade às demais.

Exemplo: “Se a importação dos pedidos é um 3, então o processamento dos pedidos é um 5.”

Essa estratégia é interessante pois permite desacoplar a estimativa de esforço da noção de tempo, o que traz uma série de benefícios. Confira alguns:

  • A evolução do time, as mudanças de processo e tecnologias, ou outros fatores, não vão impactar o valor da estimativa, pois este não é um valor absoluto, mas relativo aos demais itens. O histórico fica preservado.
  • Para o ser humano, é muito mais fácil comparar coisas (ex.: importar os pedidos é mais fácil do que processar os pedidos) do que estimar duração das coisas (ex.: dizer que a importação leva 4 ou 5 dias para ser concluída). Com isso o processo de estimativa é mais rápido, mais fácil, e mais preciso.

Velocidade (Velocity)

Um dos principais objetivos de se construir estimativas é dimensionar o tempo para execução de um determinado projeto. Essa informação é vital por diversas razões, como identificação de custos, planejamento da comunicação e promoção do produto desenvolvido, entre outros.

A Velocity é a métrica ágil que vai ajudar a responder esta questão. Ela é a medida do progresso de um time. A velocidade é a soma de todos os pontos das histórias completadas em uma iteração.

Se nós somamos todos os pontos do backlog de um produto, e comparamos com a velocidade de uma iteração, então nós temos uma estimativa de quantas iterações serão necessárias para completar o projeto.

Sabemos que estimativas não são precisas e que mudanças de escopo ocorrem durante projetos, e neste sentido a Velocity é uma métrica extremamente útil, pois corrige erros de planejamento de forma muito simples e eficiente. Tipicamente ela já começa a ficar evidente nas primeiras iterações de desenvolvimento de um time, permitindo rápida visibilidade e capacidade de ajuste. Na medida em que avançamos no projeto, adaptamos o plano de acordo com os aprendizados que tiramos. Planejar não é uma etapa inicial do projeto, mas uma atividade contínua durante todo o ciclo de desenvolvimento.

Com estes poucos conceitos podemos chegar a estimativas de esforço de atividades e projetos de forma muito mais eficiente, além de saber melhor aproveitar as estimativas durante o ciclo de vida de um projeto.

Em uma postagem futura vamos explorar processos e dinâmicas para construir estimativas em equipe, de forma colaborativa. Aguarde!

Anúncios

2 comentários sobre “Estimando esforço de forma ágil

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