Este texto discute sobre a adoção simultânea das técnicas de gerenciamento de projetos do PMI descritas no PMBOK e uma metodologia ágil de desenvolvimento de software, o Extreme Programming – XP. Estas duas técnicas possuem algumas características antagônicas, mas que podem ser combinadas para que a empresa consiga obter bons resultados nos projetos de software.

Introdução

Muitas empresas pretendem adotar o Gerenciamento de Projetos para otimizar o processo de desenvolvimento de sistemas. Mas será que elas devem abandonar suas MDS – Metodologias de Desenvolvimento de Sistemas? Processos como XP – Extreme Programming podem conviver com o Gerenciamento de Projetos?

Este texto tem a finalidade de discutir como integrar o processo ágil de desenvolvimento de sistemas chamado XP – Extreme Programming com o Gerenciamento de Projetos. Será que a adoção da metodologia do PMI fere as regras do XP?

Contexto

O desenvolvimento de software é um processo até certo ponto intangível (se comparado com a construção civil, por exemplo). As mudanças de escopo são ainda mais freqüentes no decorrer do projeto. Combinando o Gerenciamento de Projetos com uma MDS, podemos conciliar as peculiaridades de ambas as disciplinas para otimizar todo o processo.

O que ocorre é que várias empresas estão tendo dificuldades para acomodar estas constantes mudanças no escopo e, concomitantemente, manter uma documentação decente que possibilite a manutenção do sistema por pessoas que não sejam aquelas que desenvolveram o software.

As metodologias de desenvolvimento de sistemas – MDS – tradicionais são elefantes brancos que não possuem agilidade suficiente para acompanhar a dinâmica da tecnologia da informação. Some-se a isso o fato de os usuários geralmente não terem uma noção exata do que querem e a todo instante têm idéias novas.

Talvez você ache que estou sendo um pouco radical ao afirmar que as MDS tradicionais são elefantes brancos. Tomemos a metodologia seqüencial linear como exemplo. Apesar de antiga, ainda é utilizada em muitas empresas. Esta metodologia prega que só se avance para a fase seguinte quando a anterior tiver sido concluída. Basicamente, esta MDS possui as fases de análise, projeto, codificação e testes. Estas fases exigem que o projeto siga um fluxo temporal seqüencial; o cliente deve ter paciência, pois uma versão “testável” do sistema só será liberada numa fase bem avançada do processo; os desenvolvedores podem até ficar ociosos esperando a definição das regras de negócios e conseqüentemente da especificação técnica; por último, o cliente deve ter uma idéia clara do que ele necessita logo no início do projeto. Como dito anteriormente, os clientes não sabem exatamente o que querem no começo e frequentemente nem mesmo ao final do projeto. O resultado disso é um sistema que sofre manutenção constante e nunca fica pronto. Ele sempre está recebendo aquelas intervenções “prioritárias”. O custo das mudanças neste processo já é conhecido pelos profissionais que trabalham no desenvolvimento de software. O gráfico a seguir é clássico e irá relembrá-lo:

Figura 1 – Custo das alterações no escopo em uma metodologia tradicional

É claro que diversas empresas desenvolvem sistemas orientados a objetos. OK, mas o problema persiste. E para o mesmo público que trabalha com desenvolvimento de software (programação, especificamente), eu faço a pergunta: você acha agradável documentar e entender a documentação do seu sistema? Claro, algumas pessoas responderão que gostam de documentar e que também entendem a documentação, mas elas são a minoria. A maior parte dos desenvolvedores adora codificar, mas detesta documentar o que faz. Para estas pessoas, a documentação está em suas cabeças.

Se alguém já comparou o planejamento inicial de um sistema com o realmente executado. Por favor, responda que já fez isso! Você gerencia seu processo! Descobre-se que a variação é muito grande! Muitas vezes, o próprio objetivo do sistema foi mudado. Será que a documentação acompanhou estas mudanças?

Quem já assistiu a um filme chamado Máquina de Guerra lembrará uma cena na qual um oficial do exército americano solicita aos responsáveis a documentação de um projeto de tanque de transporte de tropas. Este oficial tem sua sala inundada por pilhas e pilhas de documentos. Será que esta documentação está sendo útil? Qual o objetivo de uma documentação?

A documentação deve nortear as ações da equipe e deixar claro o que foi acertado entre equipe técnica e o cliente. A documentação é inútil se é tão extensa que é impossível de ser consultada. O mesmo acontece quando a documentação está desatualizada. Neste caso é ainda pior. Quem a consulta, pode tirar conclusões totalmente desvirtuadas!

Para tentar reduzir estes problemas de alterações constantes no escopo e falta/desatualização de documentação, surgiram as chamadas metodologias ágeis de desenvolvimento de sistemas. O Extreme Programming – XP – é uma destas metodologias que tentam reduzir o impacto das alterações no projeto como um todo.

O XP possui alguns valores fundamentais: feedback, comunicação, simplicidade e coragem. “… Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento…” (TELES, 2004). O mesmo autor continua: “… A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem… Também é necessário que a equipe compreenda e utilize o valor da simplicidade, que nos ensina a implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente… a equipe precisa ser corajosa e acreditar que, utilizando as práticas e valores do XP; será capaz de fazer o software evoluir com segurança e agilidade”.

Eu gostaria de chamar atenção para o valor da simplicidade. Quantas vezes nós, profissionais de TI, complicamos tanto uma demanda que não conseguimos sequer explicar o que pretendíamos ter feito? Muitas vezes, temos a melhor das intenções, mas complicamos tanto que embolamos prazo, escopo, risco e até mesmo qualidade.

O XP possui ainda algumas práticas. São elas: cliente presente, jogo do planejamento, stand up meeting, programação em par, desenvolvimento guiado pelos testes, refactoring, código coletivo e padronizado, design simples, etc. Não vou me ater aqui em detalhes do XP, pois não é o objetivo deste artigo, mas gostaria de frisar alguns pontos.

A prática de cliente presente ajuda bastante o desenvolvimento do sistema. Entretanto, há um ponto ótimo nesta questão. Nenhum programador gostaria ter que mudar um campo de lugar toda vez que o cliente sentar ao seu lado.

O stand up meeting é uma ótima prática, não? Alguém já ficou numa reunião que durou 4 horas e não resolveu coisa alguma? Ou também em uma reunião tão longa que o assunto poderia ser resolvido em 20 minutos! Isso impacta na produtividade da equipe!

A programação em par é interessante, pois um programador dá opinião no código do outro. Assim, o resultado é um código mais discutido e mais otimizado. O problema aqui é o custo. Remunerar dois programadores para fazer o trabalho de um é oneroso! Mesmo que o código saia com uma qualidade muito superior, teoricamente, uma pessoa já deveria construir um código otimizado.

O objetivo do XP, como dito, é acomodar as mudanças de escopo de forma que o impacto sofrido seja o menor possível, conforme o gráfico abaixo:

Figura 2 – Custo das alterações no escopo em uma metodologia ágil

Figura 1 – Custo das alterações no escopo em uma metodologia ágil

Integrando o XP com gerenciamento de projetos

Um dos motes do XP é uma documentação sucinta. O que não acontece em uma metodologia clássica de gerenciamento de projetos (vamos focar o PMBOK). O controle que o gerenciamento de projetos impõe é muito importante. Entretanto, muitas pessoas reclamam do excesso de documentos a serem preenchidos. Por outro lado, o XP pode pecar pela documentação escassa, que nem sempre permite um rastreamento completo de requisitos.

Há aquelas pessoas que pensam que a documentação pode resguardar a equipe. Em algumas situações, como contratos e fechamento de escopo, a documentação pode servir de segurança para ambas as partes envolvidas. Todavia, há situações nas quais os documentos servem apenas para inserir no processo uma burocracia inócua.

No início do projeto de software que use a metodologia XP é importante seguir as premissas do gerenciamento de escopo. Sendo assim, deve-se elaborar o Termo de Abertura e a Declaração de Escopo. O objetivo aqui é definir o escopo inicial do projeto. A conseqüência desta ação é ter de atualizar estes documentos a cada alteração no escopo.

Um item importante que deve ser considerado no XP é a produtividade da equipe. Suas ações e práticas visam aumentar a produtividade. Mas como medir e acompanhar? Como saber se a equipe pode produzir mais? Este controle e direcionamento só podem ser obtidos com um planejamento e a documentação pertinentes. Portanto, é indicado fazer a WBS e o cronograma. Aqui estou supondo que você saiba os passos para construção do cronograma (lista de atividades, seqüenciamento, etc).

Mais uma vez reforço que, mesmo sendo o XP uma metodologia rápida, é necessário algum controle e documentação. O XP prega que o código é o principal produto de um projeto de software. Concordo que há muitos projetos que geram uma enormidade de documentos. Entretanto, é necessário um pouco mais que a documentação básica. Conforme TELES (2004), os documentos que compõem o XP são:

• Estória
• Testes de aceitação
• Testes de unidade
• Javadoc
• Modelo de classes
• Modelo de dados
• Processos de negócio
• Manual do usuário
• Acompanhamento diário
• Acompanhamento do projeto
• Fotos

Não há o que discutir nem discordar sobre a importância da documentação acima. O ponto que precisa ser melhorado e integrado à metodologia de gerenciamento de projetos é o acompanhamento. Todos os documentos que citamos anteriormente a respeito de gerenciamento de projetos podem ser usados para incrementar o acompanhamento que falta ao XP. O cronograma, por exemplo, dará um acompanhamento da equipe satisfatório para o gerente do projeto.

Um outro fato precisa ser mostrado: o cliente deve sempre estar presente, conforme uma das práticas do XP. Contudo, algumas decisões do cliente podem afetar o projeto como um todo. Como saber se a decisão tomada pode efetivamente ser implementada no software? É necessário se fazer um plano de comunicação, conforme prática do PMBOK. Neste plano, deve-se especificar quem deve ser comunicado, quando e como a comunicação será feita, além do conteúdo da mensagem. Assim, todas as decisões e fatos importantes serão comunicados a quem de direito, reduzindo os problemas de falhas na divulgação das informações, erro muito comum nos projetos.

Há um método de gerenciamento de desenvolvimento de software chamado SCRUM. Este método é adaptado para o processo ágil de desenvolvimento de software. Entretanto, este método tem como característica o fato de ser reativo. Isso contraria o que estamos discutindo. Mesmo com certa dose de imprecisão, é necessário fazer um planejamento das atividades.

O PMBOK prioriza o escopo, logo após os recursos e por último o tempo necessário. Aqui, estamos focando apenas na essência dos projetos sem negar a importância das outras áreas de conhecimento do PMBOK, como riscos, comunicações, etc. O objetivo no momento é comparar os focos do PMBOK e do SCRUM, que prioriza o tempo, depois os recursos e finalmente o escopo.

Pensemos juntos: o PMBOK procura entender primeiro o que o cliente necessita e saber qual é o “tamanho do buraco”. As metodologias ágeis, como o próprio nome diz, focam o prazo de atendimento da demanda. O importante é fornecer rapidamente o que o cliente deseja, acatando suavemente as alterações do escopo. Ora, como me preparar para uma guerra sem antes conhecer meu inimigo? Concordo que é extremamente difícil ter uma idéia clara dos requisitos do software, mas um planejamento se faz necessário. Usando novamente uma analogia: o que você levaria para uma viagem na qual não se conhece o destino? Você não sabe se é frio ou quente, se é no litoral ou no interior… Você seria obrigado a preparar as malas para enfrentar qualquer tipo de situação. Conseqüentemente, os recursos empregados seriam maiores que o necessário. O mesmo acontece com esta visão prioritária do tempo. Portanto, o ideal é fazer uma junção destas duas visões.

Há aqueles defensores das metodologias ágeis que afirmam que esta visão do PMBOK de relegar o tempo para último lugar não é indicada. O que acontece, neste caso, é que o tempo é conseqüência e dependência do escopo e dos recursos empregados.

A proposta é que se faça um estudo prévio do escopo (elaborando os documentos citados anteriormente) e logo após fazer o cronograma. Os riscos estão presentes em qualquer projeto, portanto, deve-se analisá-los. As seguintes perguntas, dentre outras, devem ser respondidas:

• Alguém da equipe estará de férias no período do projeto? Em caso positivo, a probabilidade de ocorrência do risco é de 100% e o impacto será inversamente proporcional à disponibilidade de recursos para serem empregados.
• A tecnologia empregada é de conhecimento da equipe? Se a tecnologia é nova para a equipe, o risco será altíssimo. Portanto, não deve ser ignorado.
• Qual a criticidade do sistema para o negócio do usuário? Neste caso, a probabilidade de problemas no projeto como um todo pode variar, mas o impacto será estrondoso se o projeto for crítico para o cliente.

Estas perguntas foram apenas para ilustrar que o XP deve considerar mais fatores que aqueles que comumente se considera. Prosseguindo com aquilo que considero o ideal, peguemos as áreas de conhecimento restantes. A qualidade é uma preocupação das metodologias ágeis, portanto, pode-se seguir os preceitos do XP. A contratação poderia ser mais bem tratada no XP. Eu já tive alguns problemas em um projeto que envolveu terceirização de recursos. O escopo só fez aumentar e o contrato não comportava reajuste. Neste caso e dependendo do tipo de contrato, o XP deve agir como o PMBOK, fechar o escopo antes de todos os outros passos do projeto. A integração deve ser como uma liga que une todos os pontos discutidos, cuidando para que o executado seja de acordo com o planejado, a comunicação seja coerente com o acertado. O XP já trata a integração a partir do momento em que a equipe discute juntamente com o cliente os do projeto, além de manter o código coletivo e divulgado entre a equipe. Sendo assim, cobrimos todas as áreas de conhecimento, considerando que anteriormente já tratamos do escopo, tempo, custos, recursos humanos e comunicações.

Conclusões

O XP e o PMBOK possuem focos diferentes. Cada qual possui suas vantagens e desvantagens. A empresa que desejar usufruir dos benefícios destas duas metodologias deve efetuar algumas adaptações.

As mudanças que o software sofre no decorrer do seu ciclo de vida devem ser planejadas e contabilizadas. Os prejuízos decorrentes destas alterações podem ser enormes. Como discutimos, o propósito das metodologias ágeis é acolher da forma mais branda possível estas alterações, todavia, é importante também que se oriente o usuário sobre o escopo do software. O problema principal na construção de software são escopos indefinidos.

As metodologias ágeis, por tentar encampar as mudanças, e até mesmo considerá-las normais, são muito adequadas para o desenvolvimento de software, entretanto, um controle maior deve ser adicionado. Este controle pode ser incrementado com o uso das metodologias do PMBOK, que também se preocupa com questões mais amplas, como contratação, etc.

Referências

1. Guia PMBOK® – Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos Terceira Edição – 2004.

2. TELES, Vinícius Manhães; Extreme Programming. 1 ed. São Paulo: Novatec Editora, 2004.

3. CÂMARA, Fábio. Um cardápio de metodologias ágeis. Visão Ágil. Available: http://www.visaoagil.com/downloads/edicoes/VA_02.pdf. [04 jan. 2008].

4. D’ÁVILA, Márcio. PMBOK e Gerenciamento de Projetos. MHVILA. Available: http://www.mhavila.com.br/topicos/gestao/pmbok.html [04 jan. 2008].

5. JEFFRIES, Ron. Planning the Project. XProgramming. Available: http://www.xprogramming.com/xpmag/rorPlanning.htm [20 dez. 2007].