Metodologias Ágeis de Desenvolvimento de Software x Gerenciamento de Projetos

Primeiramente gostaria de me desculpar pela minha ausência, mas escrever por escrever não teria graça alguma, portanto aguardei que algum tema bacana caísse no meu colo, ou que tivesse um 'clic' na cabeça para escrever algo que eu realmente ache construtivo.

Bem, o que é esta coisa de manifesto Ágil? Em 2o01 um bando de programadores resolveu criar um manifesto que consistia no seguinte:
Indivíduos e interações sobre processos e ferramentas;
produto sobre documentação;
Resposta à mudança sobre seguir um plano;
Colaboração do cliente sobre negociação contratual.
O que significam estas frases? Elas dizem que o termo da esquerda tem mais peso que o termo da direita, ou seja, é melhor programar que documentar, é melhor seguir as mudanças do que seguir um plano estratégico, enfim, parece o fim dos controles e prelúdio do caos à primeira vista.

Do outro lado do ring, o Gerenciamento de Projetos, representado pelo PMBOK, onde em sua 4ª edição prega o seguinte:
"O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento: Iniciação, Planejamento, Execução, Controle e Encerramento"

A abordagem do PMBOK é de controle de projetos por fases sequenciais, onde para irmos a próxima fase temos que atingir certos objetivos previstos no início do projeto, basicamente relacionados a Prazo, Custo e Qualidade (Triple Constraint).
Claro que o PMBOK já prevê alguma coisa de gerenciamento e mitigação de riscos, tentando antever imprevistos e mudanças no curso do projeto, mas isso significa mais controles e não uma resposta exatamente "Ágil".

Na Revista Mundo PM, edição abril/maio-2009 vi estes dois temas tão antagônicos postos à prova, confesso que nunca vi ninguém fazer isso e nem ouvi falar de gerenciar contratos, projetos de uma maneira puramente "Ágil" conforme o manifesto acima.

Vejo alguns problemas para isto se materializar no mundo real:
No manifesto ágil, como a documentação está em segundo plano, a cabeça de um programador tem que ter tudo sobre o negócio, técnicas, ferramentas e anseios do cliente, todos os programadores são gerentes de projeto e podem agir e decidir alguma coisa, contra isso eu vejo uma contratação de pessoal mais consciente, preparada, generalista e mais ... cara! Fora que deixar o projeto na mão de um programador que pode morrer, querer viajar ou até pedir as contas é muito perigoso.

Contratos com os princípios "Ágeis" não são viáveis em novas parcerias ao meu ver, porque ele prega a colaboração do cliente e resposta a mudanças sem seguir plano, mas se um fornecedor toma prejuízo acaba largando o projeto e o cliente se prejudica do mesmo jeito, o que eu quero dizer é que se um projeto muda de tal forma que os custos do fornecedor se multiplicam, o mesmo não continuará, um contrato tem que ser um acordo bom para ambas as partes sem enaltecer cliente ou vendor!

Eu até estou vendo no mundo real alguma coisa parecida com Ágil, mas em parcerias mais antigas. Segundo a revista Mundo PM, compararíamos as formas tradicionais com as "Ágeis" da seguinte forma, imagine um contrato para construir uma parede de tijolos.

Ao invés de cobrarmos a parede pronta, cobraríamos por tijolos utilizados e para acompanhar a execução da obra teríamos então pontos de controle com "go-no-go" do andamento da obra.

É verdade que seria uma proposta mais transparente, mas teria que haver uma sinergia e confiança mútua entre cliente e fornecedor para isso ocorrer num contrato não 100% definido no início.

Tem sempre um lado positivo:
Seguindo o exemplo da parede dos tijolos acima, se eu cobrar uma empreitada fechada, terei que colocar ao menos 40% de margem para cobrir eventuais imprevistos que acaba onerando o cliente, se o cliente tiver consciência dos imprevistos e confiar em mim, ele vai me pagar por tijolos gastos e as possíveis variações da parede serão arcadas por ele e eu não precisarei embutir sobrepreço do meu risco.

Resposta à mudança em primeiro plano, isso é bom no manifesto, porque às vezes eu vejo no gerenciamento de projetos tradicional que fica tudo muito a cargo do gerente de projetos decidir, tudo formalmente controlado e no final, na prática, acaba-se criando os controles dos controles para controlar um controle (desculpe o trocadilho, rs). No final ninguém sabe para que aquela planilha ou apresentação que está sendo feita serve exatamente.

Ambas as formas têm falhas:
No Gerenciamento tradicional cada projeto, segundo o PMBOK 4ª edição, "... é um esforço temporário e definido para criar um único produto, serviço ou resultado", então se é um esforço único, nunca ninguém fez igual antes, talvez até parecido, mas nunca igual, então temos de admitir que fechar um escopo logo de cara nunca vamos ter a precisão do que exatamente estamos começando a fazer, resumindo, temos um montão de controles que não controlam nada.

No Manifesto Ágil não acho uma boa fecharmos contratos soltos e ficar na mão do cliente além de deixar a equipe de desenvolvimento pensando em algo que não seja desenvolver, não que eu goste de robôs mas me sentiria, como gerente de projetos, a mercê de N fatores externos, como turnover de mão de obra, negociações salariais absurdas no meio do projeto, disputas de egos entre outras coisas em que um ambiente semi-anarquista pode propiciar.

A minha idéia é equilibrarmos ambas as tendências, cabendo ao gerente de projetos deixar a coisas correrem mais livres ou mais controladas à medida que vão acontecendo (rolling wave plan).

Hoje eu quis manifestar a minha dúvida, não quis trazer nada pronto e bonito aos leitores do meu blog, hoje eu preferi a dúvida e a incerteza.

Links relacionados:
Manifesto Ágil: http://www.agilemanifesto.org/
PMI: http://www.pmi.org/Pages/default.aspx
Revista Mundo PM: http://www.mundopm.com.br/destaques2Ed26.shtml