PUCPR - Pontifícia Universida de Católica do Paraná

MBA em Gestão de Projetos de Software

Disciplina: Metodologias Ágeis
Professor: Binhara
Alunos: Luiz Gustavo Rissmann
Marcelo Jundy Kimura
Data: 05/05/2008

METODOLOGIA ÁGIL

RESUMO
Este artigo tem como objetivo fazer um estudo comparativo entre a
metodologia tradicional em cascata e a metologia ágil XP. Demonstrando que
fatores devem ser analisados no momento de se avaliar a implantação da
metodologia ágil XP.

INTRODUÇÃO
Todo projeto precisa seguir algumas regras básicas de desenvolvimento, seja
ele pequeno ou grande. Essas regras básicas sevem de alicerce para a condução,
comunicação e documentação do projeto. O problema é saber se o seu processo
não está burocratizado demais, ou, por outro lado, insuficiente. O segredo para
definir um processo perfeito é saber qual é o meio termo.(HEMRAJANI, 2007, p.
4-11)

Se um documento é escrito e não lido por ninguém, provavelmente foi apenas

perda de tempo fazê-lo. De outro lado, se uma informação é necessária e não está
documentada de nenhuma forma acessível a quem precisa dela, o processo é
insuficiente.

As metodologias ágeis de desenvolvimento pregam justamente isso. Elas se

baseiam fortemente na idéia de que o conhecimento deve trafegar da forma mais
clara e transparente possível, sendo assim usando a forma mais simples, a fala. O
conhecimento é transmitido de forma verbal, com o mínimo de documentação
escrita. Na verdade, a única forma realmente confiável de documentação em um
projeto é o código fonte do software. Esta é a única forma de documentação que
nunca está desatualizada. Através de conceitos como programação em pares, o
conhecimento é transmitido entre todos os componentes do time de uma forma mais
natural e através de práticas de programação baseadas em primeiro implementar os
teste, os requisitos e as regras do sistema (inclusive as regras de negócio) são
documentadas a medida que o software é desenvolvido. Uma documentação clara,
simples e sempre atualizada, pois reflete exatamente o que está em produção, em
forma de testes unitários ou integrados.

Com a adoção de métodos ágeis, o impacto das mudanças são reduzidos ao

mínimo pois os milestones ou sprints são curtos e com pouco overhead de
documentação prévia. Os requisitos podem ser mudados constantemente sem que
isso ponha em risco os prazos ou acarrete em retrabalho excessivo. Desta forma a
comunicação com o cliente é mais freqüente pois em curtos períodos de tempo
existem entregas de “pedaços” do sistema plenamente funcionais, enquanto os
“pedaços” posteriores ainda são definidos.

MOTIVAÇÃO

Qualquer que seja a metodologia empregada para o desenvolvimento de um

software, todas tem como objetivo entregar sistemas que atendam às
funcionalidades especificadas pelo cliente, dentro do prazo e custos acordados e
com qualidade.

O grande desafio para as empresas de desenvolvimento de software é

encontrar a metodologia que melhor se adapta às suas características culturais e de
negócio.

Some-se a isso a dinâmica das empresas, que normalmente não

disponibilizam de tempo e principalmente recursos para se arriscar a implementar
novas metodologias de trabalho.

A metodologia ágil está no meio do caminho entre não ter processos e

documentação e toda a burocracia envolvida nas metodologias tradicionais.

A dinâmica do mundo dos negócios tem se intensificado nas últimas décadas

e com isso a necessidade dos sistemas responderem a estas mudanças. A
metodologia ágil se apresenta como uma alternativa à esta nova realidade,
contrapondo alguns paradigmas até então praticados.

METODOLOGIAS TRADICIONAIS

As metodologias tradicionais foram desenvolvidas com o intuito de tornar os

processos de desenvolvimento de software mais previsíveis e eficientes. Com a
previsibilidade é possível planejar e conseqüentemente mitigar riscos de insucesso
de um projeto.

Elas tem uma ligação forte com as metodologias de engenharia(civil,

mecânica) onde engenheiros criam e especificam todos os detalhes do projeto para
em seguida passar aos executores, que não necessitam de conhecimento
especializado para por em prática as especificações apresentadas. (FOWLER,
2005)

MODELO EM CASCATA

É recomendado para projetos onde os requisitos de um sistema são

conhecidos e razoavelmente estáveis.

O modelo em cascata é estruturado em etapas seqüenciais, sendo que uma

etapa somente se inicia após a finalização da etapa anterior, que é marcada pela
confecção de documentos e aprovação por parte dos stakeholders.

Nesta abordagem, a equipe não é tão importante e a atenção recai sobre as

funções que cada pessoa desempenha nas etapas do projeto.
Fases do modelo em cascata (PRESSMAN, 2006, p.39)

Comunicação
- iniciação do projeto
- levantamento de requisitos

Planejamento
- estimativas
- cronogramação
- monitoração

Modelagem
- análise
- projeto

Construção
- codificação
- teste

Implantação
- entrega
- manutenção
- feedback

Dependendo da complexidade e tamanho do projeto, o tempo requerido para

a finalização das etapas que antecedem o processo de construção em relação ao
tempo de construção é bastante considerável. E neste caso, as chances de haver
mudanças nos requisitos é bastante alta.

As principais críticas ao modelo em cascata são:

1. Projetos reais raramente seguem o fluxo seqüencial que o

modelo propões. Apesar de o modelo linear poder acomodar a
iteração, ele o faz indiretamente. Como resultado, as
modificações podem causar confusão à medida que a equipe de
projeto

2. Em geral, é difícil para o cliente estabelecer todos os requisitos

explicitamente. O modelo em cascata exige isso e tem
dificuldade de acomodar a incerteza natural que existe no
começo de muitos projetos.
 3. O cliente precisa ter paciência. Uma versão executável do(s)
programa(s) não vai ficar disponível até o preríodo final do
intervalo de tempo do projeto. Um erro grosseiro pode ser
desastroso se não for detectado até que o programa executável
seja revisto.” (PRESSMAN, 2006, p.39)

METODOLOGIAS ÁGEIS

Para lidar com as constantes mudanças de requisitos e a necessidade de

respostas rápidas por parte do cliente, é que nestes últimos anos surgiram diversas
metodologias ágeis, para citar algumas: XP - Extreme Programming, Scrum, FDD –
Feature Driven Development, DSDM – Dynamic System Development Method. .

Em fevereiro de 2001, em um workshop realizado em Snowbird, Utah, se

reuniram os representantes das principais metodologias ágeis e o resultado foi o
Manifesto para Desenvolvimento Ágil:

“Estamos descobrindo maneiras melhores de desenvolver software

fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:
• Indivíduos e interação entre eles mais que processos e
ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano
Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens
à esquerda." (BECK, 2001)

Por ser a metodologia ágil mais difundida, será descrito a metodologia XP.

XP (EXTREME PROGRAMMING)

O XP teve origem no final da década de 80, através da comunidade smalltalk,

e especialmente na colaboração entre Kent Beck e Ward Cunningham.

O marco para a metodologia XP foi um projeto de controle de folha de

pagamento da Chrysler. Kent Beck liderou o projeto C3 utilizando a metologia XP
obtendo êxito na primeira fase do projeto, que começou na primavera de 1996 e
entrou em produção no início de 1997. (FOWLER, 2005)
 Com as experiências adquiridas neste projeto, Kent Beck publicou o livro
Extreme Programming Explained e deu início à popularização do XP. (PRESSMAN,
2006, p.63)

O XP é um processo de desenvolvimento de software para pequenas equipes

(até 12 desenvolvedores), para projetos em que os requisitos são vagos e que
mudam constantemente, para desenvolvimento de sistemas orientados a objeto e
que tenha desenvolvimento incremental.

O XP está baseado em quatro valores fundamentais:(TELES, 2004, p.22-27)

– Feedback

A medida que o cliente vai utilizando o sistema, ele vai descobrindo novas
necessidades e vai dando feedback para a equipe de desenvolvimento,
permitindo que o cliente priorize as funcionalidades que vão agregar mais valor
ao seu negócio;

– Comunicação

A comunicação entre a equipe e o cliente deve ser ágil e é fundamental para que
todos os detalhes do projeto estejam bem compreendidos;

– Simplicidade

Não deve ser implementado nada além do essencial. Não ficar especulando
sobre funcionalidades futuras;

– Coragem

Não ter medo de alterar módulos que já estão funcionando;

O XP se baseia nas seguintes práticas :

 – Cliente presente

O cliente deve conduzir o desenvolvimento, por este motivo deve estar acessível
sempre que surgirem dúvidas;

– Jogo do planejamento

O projeto todo é divido em releases e iterações. As releases são módulos e as

iterações são o períodos de tempo de algumas semanas em que a equipe de
desenvolvimento implementa um conjunto de funcionalidades acordadas com o
cliente. No início de cada release e de cada iteração é que acontece o jogo do
planejamento, onde o cliente prioriza as funcionalidades da próxima release ou
iteração;

– Stand up meeting

No início de cada manhã, a equipe se reúne para uma reunião rápida (15
minutos) para avaliar o trabalho que foi executado no dia anterior e priorizar o
que será implementado no dia;

– Programação em par

Na programação em par, muito embora pareça que há perda de produtividade,

permite que o código seja revisado permanentemente e que haja uma troca
constante de conhecimento entre os pares;

– Desenvolvimento guiado pelos testes

Para garantir a qualidade do código que está sendo escrito, antes de codificar o
desenvolvedor deve codificar os testes.

– Refactoring

Quando se altera um código sem modificar as funcionalidades se está fazendo

refactoring. Por se tratar de um desenvolvimento incremental e com o intuito de
melhorar e clarificar o código, o refactoring frequentemente se faz necessário.

– Código coletivo

O sistema não é dividido em partes e portanto não há um desenvolvedor

responsável por determinada parte. No XP o código é coletivo, todos os
desenvolvedores tem acesso a todo código do sistema e tem permissão para
alterá-lo. Isso fornece uma maior agilidade, permitindo que o código seja sempre
revisado e refeito, caso necessário. A responsabilidade sobre o código é de
todos.

– Código padronizado

Para que seja possível o trabalho em conjunto, é necessário que a equipe

estabeleça padrões de codificação de modo a agilizar e facilitar a manipulação
por todos.

Uma outra vantagem da padronização é que a homogenização do código

facilitará a sua manutenção futura.

– Design simples

A essência do XP é desenvolver apenas o que é essencial, sem se preocupar

com funcionalidades futuras. Por este motivo, a simplicidade do design se faz
necessário. Parte-se da premissa de que os desenvolvedores serão capazes de
acrescentar qualquer funcionalidade futura sem comprometer o sistema como um
todo.

– Metáfora

Para facilitar a comunicação, o entendimento e a criação de um design simples, a

equipe de desenvolvimento pode utilizar de metáforas. As metáforas possibilitam
que idéias complexas sejam transmitidas de forma simples.
 – Ritmo sustentável

No XP a qualidade de tudo o que é desenvolvido é diretamente dependente da

equipe de desenvolvimento. É difícil imaginar que uma equipe trabalhando por
horas a fio não tenha queda na produtividade e que isso não seja traduzido em
erros e problemas na qualidade do software.

Para que seja possível manter um ritmo sustentável é recomendado que não
sejam excedidas as horas normais de trabalho, evitando-se ao máximo o
trabalho após o expediente.

– Integração contínua

A incorporação de uma nova funcionalidade normalmente afeta outras

funcionalidades já implementadas do sistema. Para garantir que todo o sistema
esteja sempre funcionando, deve-se utilizar a integração contínua, o que significa
que os pares devem integrar seus códigos ao restante do sistema diversas vezes
ao dia.

Antes de efetuar a integração, o código deve ser devidamente testado, de modo

a reduzir ao máximo os possíveis erros.

– Releases curtos

O XP tem como objetivo a geração de fluxo contínuo de valor para o cliente. Isso
é feito através da entrega de releases curtos, definidas conjuntamente com o
cliente. A entrega das funcionalidades prioritárias permitem que o cliente já possa
utilizar o sistema e se beneficiar.

Em que casos não se deve utilizar o XP

– Sistema de premiação

O XP valoriza o trabalho da equipe e não do indivíduo. Empresas que possuem

sistemas de premiação que valorizam o desempenho individual terão problemas
em implantar o XP.
 – Contratos de escopo fechado

Os contratos de escopo fechado dificultam o gerenciamento de mudanças, sendo

prejudicial para a empresa e para o cliente.

– Clientes que fazem questão de um grande número de artefatos

A elaboração de muitos documentos ao longo do desenvolvimento pode

comprometer o desempenho do projeto. O processo necessita de agilidade,
leveza e flexibilidade.

– Escritório

A disposição dos móveis do escritório deve permitir o trabalho em pares e a fácil

comunicação entre os pares. Um escritório com nichos ou paredes pode
inviabilizar a implantação do XP.

– Mudanças

O ser humano por sua natureza é resistente à mudança. É preciso avaliar como
a equipe irá receber as mudanças advindas da implantação do XP.

– Apoio

Sem o apoio da equipe não é possível implantar o XP.

– Avaliação da cultura organizacional

Para minimizar os riscos de implantação do XP, é necessário avaliar se a cultura

organizacional está preparada.

A figura abaixo ilustra o processo Extreme Programming. (PRESSMAN, 2006,

p.64)
Vantagens do XP: (EMERY,2002)

1. Ênfase no envolvimento do cliente

2. Ênfase no trabalho em equipe e comunicação

3. O desenvolvedor faz estimativas de cronograma antes de se

comprometer: Isso ajuda a estabelecer planos e cronogramas racionais, o
que faz com que a equipe se comprometa com os cronogramas.

4. Ênfase na responsabilidade com a qualidade

5. Medição contínua: Como o desenvolvimento de software é um

processo que envolve mão-de-obra intensiva, a principal medida diz respeito
à produtividade das pessoas. Portanto, é muito importante envolver os
desenvolvedores na medição do próprio trabalho.

6. Desenvolvimento incremental: Consistente com os mais modernos

métodos de desenvolvimento.
 7. Design simples

8. Redesign e refactoring freqüentes: Uma boa idéia, mas pode ser um

problema para projetos maiores.

9. Ter engenheiros envolvidos no gerenciando o conteúdo funcional.

10. Testes extensivos e freqüentes.

11. Revisão constante: Uma prática bastante importante que pode

melhorar bastante a performance do time de desenvolvimento.

Desvantagens do XP:(EMERY,2002)

1. Desenvolvimento centrado no código ao invés de de centrado no

design: Muito embora a falta de design para projetos pequenos não seja um
problema, para projetos que tenham algumas milhares de linhas ou que
envolvam muitas pessoas, pode ser desastroso.

2. Falta de documentação de design: Limita o XP a pequenos programas

e torna difícil obter vantagens das oportunidades de reuso.

3. Usar o código fonte como documentação pode ser impraticável para

sistemas grandes porque podem conter milhares de páginas.

4. Falta de processos de revisão da estrutura.

5. Qualidade através de testes: Um processo de desenvolvimento que

está baseado fortemente em testes é improvável que produza produtos de
qualidade. A falta de um processo de design ordenado e o uso de revisões
sem estrutura significa que ainda será necessário investir um tempo
considerável para testes, a não ser para os programas pequenos.

6. Falta de um plano de qualidade

7. Limitado a um pequeno segmento de software: Dado que muitos

projetos começam pequenos e se tornam grandes, indo além do escopo
original da aplicabilidade do XP, isso pode se tornar um sério problema.

8. Os métodos são brevemente descritos: Quando os métodos não estão

bem descritos, as pessoas tendem a utilizar somente o que elas gostam mais,
ignorando o resto.
 9. Obter o apoio da gerência: O XP introduz uma série de novos métodos
gerenciais mas não provê treinamento e instruções necessárias para a sua
implantação.

CONCLUSÃO
A decisão de adotar o XP como metodologia de desenvolvimento exige um
estudo aprofundado. Por se tratar de uma processo que afetará diretamente a
estrutura da empresa, deve-se levar em conta a sua cultura organizacional e os
impactos no dia a dia das pessoas envolvidas.

Se por um lado o XP trabalha bem com as mudanças de requisitos, por outro

lado, não é muito adequado para o desenvolvimento de sistemas de grande porte
que envolvam mais do que 12 pessoas no desenvolvimento.

Outro fator que deve ser considerado é a relação com o cliente que deve
estar plenamente comprometido com o projeto em que é exigida extrema
transparência e confiança dado que não existe formalismo documental.

Por outro lado, as vantagens do XP, como a agilidade no tratamento das

mudanças de requisitos, a disseminação de conhecimento, a melhoria na qualidade
do código, trabalho em equipe e o estreitamento da relação com o cliente, são
fatores que pesam na adoção desta metodologia.

Conclui-se então que dependendo da cultura organizacional, do tipo de

projeto, da equipe e do cliente, pode-se optar por utilizar uma ou outra metodologia.
REFERÊNCIAS
HEMRAJANI, A. Desenvolvimento ágil em Java com Spring, Hibernate e
Eclipse. São Paulo: Pearson Prentice Hall, 2007.

PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.

FOWLER, M. A Nova Metodologia. Disponível em:<http://simplus.com.br/artigos/a-

nova-metodologia/>. Acesso em: 05 de maio de 2008.

BECK, K. Manifesto for Agile Software Development. Disponível

em:<http://www.agilemanifesto.org>. Acesso em 05 de maio de 2008.

EMERY, P. THE DANGERS OF EXTREME PROGRAMMING . Disponível em:

<http://members.cox.net/cobbler/XPDangers.htm#_Toc530042781>. Acesso em 05
de maio de 2008.