Como monitorar um projeto Agile?

Com a adoção do Agile e as ferramentas SDLC disponíveis, a forma como gerenciamos os projetos se tornou mais moderna em organização e monitoramento. Porém, não reinventamos nada: continuamos usando como base as dez áreas de conhecimento do PMBOK.

Antigamente, era muito comum termos reuniões diárias de status do projeto com o cliente. Com a adoção das Sprints, isso diminuiu um pouco já que estaria acordado o que seria entregue em um período pequeno. Como está o progresso da Sprint? E como anda o progresso do meu projeto em geral? Isso é que o cliente quer saber frequentemente.

Com o uso de ferramentas de gerenciamento agile – como o Jira, TFS, Agile Central, Virgin One Agile – é possível eliminar (ou reduzir muito) essas reuniões de status, disponibilizando ao cliente as informações necessárias online, acessível a qualquer momento. Porém, mesmo com essas ferramentas poderosas (mas não mágicas), para que isso ocorra são necessários insumos precisos providos pelo time. Essa é a parte mais importante para termos boas métricas.

Abaixo, duas duas informações relevantes disponibilizadas para o cliente acompanhar o progresso do projeto:

Monitorando Sprints

Uma Sprint nada mais é que um projeto pequeno, normalmente (e no nosso atual caso), com a duração de duas semanas.

Nosso melhor relatório de progresso se dá através do Burndown Chart. Caso ache que esse gráfico não apresenta a real visão do andamento do projeto, talvez (como nós no passado) não o esteja usando da maneira mais efetiva.

Usamos em nosso burndown informações baseadas em dias com o objetivo de nos mostrar o progresso da construção do produto prometido. Para isso, cada funcionalidade é quebrada e estimada em tarefas que se referem a diferentes etapas, como por exemplo: “Desenvolvimento, Criação de Test Cases, Testes em Ambiente de homologação e Teste do PO.

Definimos como regra em nosso projeto que todas as informações na ferramenta devem estar atualizadas no fim do dia. Sendo assim, ao término do trabalho, o time adiciona o tempo estimado restante para a finalização da tarefa que está sendo realizada.

Desta maneira, as informações no burndown são acuradas, fazendo com que a leitura do gráfico seja muito simples: se no final do dia a linha dinâmica do gráfico estiver acima da linha média, o projeto teve algum atraso. Caso contrário, está adiantado ou progredindo como planejado. Isso se não ocorrer alteração de escopo, que é mostrado com a subida da linha dinâmica.

Burndown por Story Points

Burndown por Tempo Restante (usado atualmente)

Lembrando que não existe processo certo ou errado, e sim o processo que mais se encaixa na necessidade do seu projeto.

Monitorando releases

Releases usam períodos definidos com data de início e fim fixados que podem conter inúmeras Sprints. Com isso, temos a oportunidade de sabermos como está o andamento da demanda, tendo como base a velocidade atual do time (dias percorridos vs tarefas completas).

Usamos o relatório de Versão, que tem como objetivo nos mostrar a data otimista, pessimista e a mais provável para a entrega do produto. Com isso, podemos tomar decisões como priorizar certas demandas, prorrogar a data de release, adicionar mais pessoas em determinadas tarefas etc.

Relatório de versão

Temos que sempre lembrar que os artefatos agile são feitos para nos auxiliar, dar um direcionamento, o que de maneira alguma substitui a comunicação efetiva que você tem que ter com o seu time. O agile não deixa o gerenciamento de projetos mais fácil – como muitos pensam e executam. Por exemplo, “o que não deu para fazer nessa sprint, faz na próxima”. Não é bem assim: tudo tem um impacto e qualquer mudança ou atraso deve ser bem avaliado.

Gerenciar em agile nos força a redobrar a atenção nas diversas áreas de conhecimento do gerenciamento de projetos, logo que temos como principal valor a transparência.

Fidelis Stolf é gerente de projetos e agile coach da GFT. Este artigo foi publicado originalmente em CIO online.