Projeto ágil sem plano = falhar

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.

Deixe uma resposta

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