Projetos ágeis no setor público

Tweet Metodologias de gestão de projetos não se tratam exatamente de uma novidade. Entretanto, na minha experiência aqui no Reino Unido, mesmo as metodologias mais tradicionais (por exemplo inspiradas em PRINCE2, que é a resposta britânica para o PMI) ainda não estão completamente difundidas. Mesmo em projetos de TI, onde […]

Metodologias de gestão de projetos não se tratam exatamente de uma novidade. Entretanto, na minha experiência aqui no Reino Unido, mesmo as metodologias mais tradicionais (por exemplo inspiradas em PRINCE2, que é a resposta britânica para o PMI) ainda não estão completamente difundidas. Mesmo em projetos de TI, onde eu imaginava que o uso de metodologias de projeto já seria lugar comum, ainda há espaço para mais estruturação.

Já aconteceu de me deparar com surpresa, e até desconfiança, ao pedir que a equipe de TI estimasse o esforço de desenvolvimento de um projeto. Business cases, apesar de incentivados, não são sempre apresentados antes do início de um projeto. E não me parece que eu tenha testemunhado casos isolados…

De modo que falar do uso de Agile como metodologia de projeto, pode até parecer um luxo desnecessário. Porém ao usar métodos Agile em um projeto relativamente pequeno que gerenciei, (implementação da intranet em SharePoint para um time de 60 pessoas), me dei conta de que mesmo indivíduos sem experiência prévia em metodologias de projetos podem aprender rapidamente os conceitos básicos de Agile. Com isso o trabalho em equipe se torna mais transparente e mais produtivo.

Algumas das ideias que nossa experiência nos trouxe:

– A grande beleza do método, é o fato de ter entregas concretas a cada fim de ciclo. Isso traz um foco e uma motivação ímpares. Além disso fazem o projeto bem mais transparente para quem está fora do time.

– A outra beleza é quebrar cada entrega em tarefas. Isso facilita a vida do gerente de projetos imensamente, pois fica muito claro quem está fazendo o que, quando.

– Finalmente, a fila de requerimentos (product backlog), deixa o cliente (seja ele interno ou externo) bem mais sossegado, porque ele sabe o que pode esperar, e como pode interferir no processo ao final de cada ciclo.

– A metodologia Agile é também conhecida como Scrum por causa das reuniões diárias, em pé, com duração de não mais que 15 minutos. Aliás o nome scrum vem de uma formação típica do jogo de rugby, vide imagem abaixo. No nosso caso o time era pequeno, e ninguém estava dedicado ao projeto em tempo integral. Então os Scrums diários seriam um pouco excessivos. A gente fazia um semanal e era suficiente.

Crédito: zeddyord @ Flickr

– Métodos ágeis também prevêem o uso de gráficos de burndow e outros indicadores do desempenho do time. No nosso caso não adotamos essas ferramentas e não sentimos falta. Mas talvez seja porque nossa lista de tarefas era pequena, então dando uma olhada no quadro com os post-its dava pra se ter uma ideia se iríamos conseguir ou não fechar o ciclo em tempo. Ah, sim, os post-its ajudaram muito, deixando o processo mais visual, facilitando o compartilhamento de tarefas e incentivando a proatividade. Por exemplo, se alguém termina a tarefa alocada para si pode ir ver o que mais está pendente – as tarefas são do time todo, não de um indivíduo.

Sem dúvida há barreiras para o uso de Agile, em especial no setor público, como postado aqui por Michele Ide-Smith. Mas creio que pode ser uma boa opção usar algumas técnicas Agile dentro do contexto de um projeto mais tradicional, e até mesmo usando em paralelo as ferramentas de projeto mais ‘consagradas’. De certa forma, introduzir os métodos Agile de uma maneira um pouco subterrânea (subversiva?). Acredito que é possível extrair benefícios dos métodos (como por exemplo, o quadro branco com post-its), sem precisar rotular o projeto como sendo Agile.

Para quem quiser ir além e testar algumas das ferramentas, este link tem um bom guia passo-a-passo.