Na gestão de projetos tradicional existe o famoso Gantt Chart que permite saber com precisão quanto tempo um projeto vai levar, quanto tempo demorará cada tarefa do projeto, que tarefa depende de qual tarefa e se alguma atrasar, o que acontece com o projeto.

Gantt chart

O Gantt Chart não se aplica a contento para projetos de software que usam metodologias ágeis pois ele pressupõe o conhecimento completo de todas as tarefas e fases do projeto antes de seu início, enquanto que nas metodologias ágeis “responder às mudanças tem mais valor que seguir um plano”, ou seja, as metodologias ágeis entendem que mudanças sempre vão acontecer e que o melhor a fazer é estar preparado para as aceitá-las.

O cone da incerteza

Já que mudanças sempre vão acontecer, como podemos acompanhar um projeto ágil, saber qual é o prazo de entrega desse projeto e, ao longo do projeto, saber se ele está dentro do prazo? Mesmo antes das metodologias ágeis já existia o conceito do cone da incerteza que diz que a precisão das estimativas de prazo de um projeto é muito pequena no início do projeto e aumenta ao longo do tempo. Aliás, não só a precisão das estimativas de prazo, como também de custos e de escopo que, juntos com o prazo, são os três limitadores de todo projeto.

Cone da incerteza

O cone da incerteza se aplica a qualquer projeto, quer ele use metologias ágeis ou metodologias de gestão de projetos mais tradicionais. Ou seja, mesmo tendo um Gantt Chart, no início do projeto não teremos precisão sobre seu prazo. O Gantt Chart passa uma falsa impressão de que está tudo sob controle, mesmo com todas as incertezas que existem no início de qualquer projeto.

Mas eu tenho que ter um prazo…

Contudo, mesmo levando em conta o cone da incerteza, é possível ter uma estimativa de prazos, nem que seja algo como “esse projeto vai ficar pronto em setembro” o que significa que ele pode ficar pronto em qualquer um dos 30 dias de setembro, ou “esse projeto será entregue no terceiro trimestre de 2011” o que dá 45 dias para mais ou para menos de margem de erro! 🙂

Prazos têm que existir e te que ser respeitados.

E não raro há casos em que prazo é fixado por quem pediu o projeto (“o site dessa promoção tem que ser publicada até 15 de julho pois nesse dia teremos uma campanha direcionando para esse site”). Nesses casos nos sobram escopo e recursos para mexer sendo que às vezes adicionar mais recursos não faz o projeto andar mais rápido.

De qualquer forma, tanto tendo um prazo fixo (“15 de julho”) quanto podendo dar estimativas um pouco mais abertas (“em setembro”, “terceiro trimestre de 2011”), é preciso saber se estamos dentro do prazo para podermos tomar decisões (trazer mais gente? reduzir escopo? negociar mais prazo?).

Como fazer acompanhamento de projetos ágeis?

Projetos ágeis podem fazer uso de gráficos burnup para podermos ter melhor visibilidade de seu andamento. Não estou falando dos gráficos burnup de cada iteração, que interessam apenas à equipe que está tocando o projeto, mas sim um burnup do projeto inteiro que trará informações úteis para todas as pessoas interessadas nesse projeto.

Veja o exemplo do gráfico abaixo:

Burnup

Nesse exemplo temos uma definição inicial do esforço necessário para terminar um determinado projeto que teria começado em 7/1/2008. O esforço necessário para concluir esse projeto é de quase 100 “xpto”, que está marcado na linha verde. Esse “xpto” pode ser pontos ou horas ou features ou o que quer que usemos para medir progresso de desenvolvimento.

Note no exemplo que nos dias 4/2, 18/2 e 31/3 houve aumentos do esforço necessário. Se não fossem esses aumentos o projeto estaria concluído até 24/3. Com os aumentos passou para 21/4, quase um mês de atraso.

A linha vermelha mostra a velocidade do time. A inclinação dessa linha é o indicativo da velocidade: quanto menor a inclinação, mais devagar o time e, consequentemente, o projeto está andando.

Por que um gráfico burnup como esse é importante?

Ele vai ajudar o time e todos os interessados no projeto a entender seu andamento. Esse gráfico deve andar junto com uma espécie de log para entendermos porque aumentou o esforço necessário, ou porque o projeto está andando mais devagar.

Não é necessário nenhum software especial para fazer esses gráficos. Uma planilha pode dar conta do recado, ou mesmo o bom e velho papel e lápis!

Normalmente o esforço necessário para entregar um projeto pode aumentar porque aumentou o número de funcionalidades a ser entregue (aumento de escopo) ou apareceram dificuldades técnicas não previstas. Esse esforço pode diminuir quando há diminuição do escopo do projeto.

Razões comuns para diminuição de velocidade do projeto são o surgimento de dificuldades técnicas não previstas ou a entrada de um projeto extra que está divergindo esforços da equipe ou ainda a saída de um ou mais membros da equipe antes do término do projeto.

Enfim, a idéia é conseguir ter maior visibilidade e, consequentemente, mais informações para que se possa intervir quando necessário para garantir a entrega dos projetos dentro do prazo estimado.