Projeto ágil sem plano = falhar

Publicado: 04/05/2011 em Artigos

Por Fábio Camara

As crises nos projetos são tratadas como goteiras no telhado, sem se dar conta que a tempestade é muito maior. Também em projetos, seguindo práticas ágeis, pois comunicação e interação constante com o cliente não mudam contratos de prazos.

Fonte: iMasters

Conforme o filósofo francês Jacques Derrida “A verdade é contextual, local e não universal. A tradicional combinação de escopo/prazo/recursos questionada por diversos formadores de pensamentos ditos ágeis possui seu contexto ideal, afinal a matemática é umas das primeiras ciências exatas a servir ao homem.”

Um plano de projeto é em essência uma matemática: fria e fixa, inflexível às relações humanas predominantes em um projeto de software. Porém, é determinante como uma meta, um rumo, um curso. Fria porque não considera intenções, sentimentos ou qualquer percepção humana. Fixa porque é constante “teimosa” diante de uma realidade repleta de incertezas como tipicamente é um projeto de desenvolvimento de produtos. Determinante porque facilita a direção, estabelece um objetivo a ser seguido.

Para elaborar um plano sem o mapeamento das expectativas de escopo, prazo e recursos, devemos ser dotados de alguma espécie de divindade. Se não pela previsão de futuro, pela projeção dogmática – ou seja, proibida de ser questionada. É como pedir uma direção quando não se sabe aonde se quer chegar.

O problema do plano no projeto

Estimativas e planos são matrizes fundamentais de qualquer iniciativa “projetizada”, que nos permitem a redução do suspense do “cone das incertezas”, também conhecido mais popularmente como projeto de desenvolvimento de software.

A proposta de um plano é encontrar a melhor resposta para as diversas questões acerca da construção de um produto. Esta resposta deve conter funcionalidades, recursos e um compromisso de tempo. A condução do plano certamente é o “x” da problemática, mas a ausência do plano é a afirmação do fracasso.

Diante do cenário de incertezas comumente encontrado em projetos de implementação de software, um plano deve ser suficientemente confiável para direcionar os participantes ao mesmo objetivo – o produto. Ser suficiente confiável não é ser inflexível, não é estar fechado a mudanças. Suficientemente confiável é servir de base para a tomada de decisões.

Agora, diante deste cenário explanado não ter um plano é …

Nota do Autor: Falta-me criatividade para definir a melhor palavra ou frase que seja completamente honesta a descrição do desastre!

Existe um equivocado entendimento de gestores de projetos que comunicação e interação frequente com o cliente substituem um plano de projeto. Estes gestores não se dedicaram suficientemente para compreender as sérias propostas de métodos e processo ágeis. Confundem-se na utilização das práticas ágeis e possivelmente enfrentarão desafios gigantescamente superiores aos típicos proporcionados pelos cenários de incerteza.

Entretanto, tão grave quanto não ter um plano, é seguir um plano como se fosse a sagrada tábua de Moisés para os cristãos (dos dez mandamentos). Tradicionalmente planos de projetos baseados em gráficos de Gantt e / ou WBS – Work Breakdown Structure identificam atividades ao invés de funcionalidades. Estes planos controlam e medem o progresso destas atividades e não o sucesso das funcionalidades. Atividades são ações que requerem esforço. Funcionalidades são unidades de valor para o cliente. O que parece ser mais importante: atividade ou funcionalidade?

É factível determinarmos muitos outros fatores para os problemas dos planos tradicionais, como por exemplo, estes planos não considerarem as regras de “dia ideal de engenharia” no cronograma. Não tenho o objetivo de dissertar sobre estes outros fatores neste artigo. Meu prepotente ideal neste texto é demonstrar que planos tradicionais são diferentes de planos ágeis e é um infinito erro pensar que:

  • Projetos ágeis não precisam de plano;
  • Plano de projeto tradicional não serve para projeto ágil;
  • Metodologias definidas ágeis determinam que um plano de projeto é dispensável.

São estes infundados pensamentos que motivaram este artigo.

O plano de projeto ágil

Na prática, o maior problema não está exatamente no plano, mas na forma como se conduz o plano. Conforme muito bem definido pelo autor Mike Cohn no livro “Agile Estimating and Planning”, o gestor de projetos ágeis deve:

  • Dedicar seu foco na manutenção evolutiva corretiva do plano ao invés de seguir o plano como algo imutável, como se fosse um dogma religioso;
  • Encorajar mudanças e sensibilizar o plano com estas mudanças ao invés de manter-se fiel ao primeiro plano – nenhum plano é perfeito;
  • Entender que os resultados nos planos podem ser facilmente modificados desde que de acordo com os valores dos clientes;
  • Compreender que o plano seja elaborado durante toda a execução do projeto.

O plano pode estar representado na ferramenta Microsoft Project ou em qualquer outra, o plano pode conter atividades, o plano pode impor controles e etc, tudo isso é relativo. Tudo é como a “verdade” citada no início do artigo. A diferença está em como se segue o plano.

Obviamente, existe um estilo ágil de construir um plano. No meu caso, servindo como exemplo, eu construo uma lista que é uma adaptação de FBS – Feature Breakdown Structure com uma espécie de títulos de “user stories” – histórias de usuários – hierarquizadas. Gosto de usar a ferramenta Microsoft Excel para criar e manter esta lista, simplesmente porque considero muito mais fácil e flexível alterar informações numa planilha do que na estrutura disponibilizada pelo MS Project.

Contudo o cerne da questão não é o plano, como faço questão de afirmar em determinados trechos deste artigo, é a condução do plano. Eu acredito que um plano ruim, com um bom gestor de projetos consciente e praticante de técnicas ágeis, uma boa comunicação entre todos os participantes e a ativa interação com o cliente resultam em sucesso no projeto. Eu acredito que um bom e confiável plano conduzido por um gestor inflexível, sem uma adequada comunicação entre os participantes e com pouca interação com o cliente resultam em fracasso no projeto.

Conclusão: leia o parágrafo anterior quantas vezes necessário até entender a mensagem!

Fábio Camara é MVP VSTS, MCT, MCP, MCSD, MCTS, MCPITP, MCPD, MSF Practitioner, Certified SCRUM Master, e Certified ITIL Foundations. Escreveu mais de 15 livros nesta última década. Atua como consultor de produtividade em desenvolvimento de projetos e professor de disciplinas ágeis de engenharia de software. Pode ser localizado no site www.fcamara.com.br.

Anúncios

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