Impacto da aplicação da metodologia XP nas ... - Artigo Científico

artigocientifico.uol.com.br

Impacto da aplicação da metodologia XP nas ... - Artigo Científico

THIAGO BORBOREMA

IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS

ORGANIZAÇÕES DE DESENVOLVIMENTO DE

SOFTWARE

UNIVERSIDADE DO VALE DO SAPUCAÍ

POUSO ALEGRE

2007


THIAGO BORBOREMA

IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS

ORGANIZAÇÕES DE DESENVOLVIMENTO DE

SOFTWARE

1

Trabalho apresentado ao

Departamento de Sistemas de

Informação da Faculdade de

Filosofia Ciências e Letras Eugênio

Pacelli da Universidade do Vale do

Sapucaí, como requisito parcial

para obtenção do título de bacharel

em Sistemas de Informação.

Orientador: Professor Márcio

Emílio Cruz Vono de Azevedo.

Co-orientador: Professor Artur Luis

Ribas Barbosa.

UNIVERSIDADE DO VALE DO SAPUCAÍ

POUSO ALEGRE

2007


THIAGO BORBOREMA

IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS

ORGANIZAÇÕES DE DESENVOLVIMENTO DE

SOFTWARE

Monografia defendida e aprovada em 26/10/2007 pela banca examinadora

constituída pelos professores:

____________________________________

Prof. Márcio Emílio Cruz Vono de Azevedo

Orientador

_____________________________

Prof. Evandro Luís Brandão Gomes

Examinador

_____________________________

Prof. Ms. Paulo César do Nascimento

Examinador

2


3

Dedico,

à minha família, à Crishna

sinônimo de amor e carinho e

ao Thom meu pequeno grande

amigão.


AGRADECIMENTOS

Primeiramente a Crishna, que nos momentos mais difíceis ainda teve forças

para me apoiar nessa etapa de minha vida.

A minha família, onde tenho apoio e onde consigo forças para poder continuar

na empreitada que é a vida.

Aos amigos, pelo qual estimo muito. Ao orientador e amigo Márcio, ao co-

orientador Artur e a DEUS que me colocou pessoas importantes.

Muito Obrigado!

4


“A mente que se abre a uma nova idéia

jamais voltará ao seu tamanho original.”

5

(Albert Einstein)


BORBOREMA, Thiago. Impacto da aplicação da metodologia XP nas organizações

de desenvolvimento de software. Monografia – Curso de Sistemas de Informação,

Faculdade de Filosofia Ciência e Letras Eugênio Pacelli, Universidade do vale do

Sapucaí, Pouso Alegre, 2007.

RESUMO

Trata-se de um estudo, que apresenta o impacto do uso da metodologia ágil

Extreme Programming (XP) com objetivo de obtenção de sucesso em desenvolvimento

de sistemas. Baseado em estudos que demonstram falhas em projetos de software,

envolvendo orçamento, cronograma, funcionalidades, causando insatisfação do cliente.

Foram estudadas e desenvolvidas as metodologias ágeis, as quais propõem uma

diminuição na burocracia do desenvolvimento de software, sendo a extreme

programming um exemplo que proporciona softwares de maior qualidade e aceitação.

Sendo assim, apresenta-se neste os seus conceitos e aplicações, mostrando um estudo

de caso com várias empresas que aplicaram essa metodologia e demonstraram seu

impacto.

Palavras-Chaves: cliente, Extreme Programming, metodologia ágil, projetos.

6


BORBOREMA, Thiago. Impacto da aplicação da metodologia XP nas organizações

de desenvolvimento de software. Monografia – Curso de Sistemas de Informação,

Faculdade de Filosofia Ciência e Letras Eugênio Pacelli, Universidade do vale do

Sapucaí, Pouso Alegre, 2007.

ABSTRACT

This paper is intended to present the impact of using the agile methodology

Extreme Programming (XP) as a goal to obtain success on system development. The

agile methodologies was developed based on researches demonstrating failures on

software projects, involving budget, schedule and functionalities, demonstrating the

client discontentment. These methodologies have the approach of reducing paperwork

on software development. Extreme Programming is one of the approaches to increase

software quality and client satisfaction. This paper introduces the Extreme

Programming concepts and applications, presenting a case study with many companies

that adopted this methodology and showing its impact.

Keywords: client, Extreme Programming, agile methodology, impact.

7


Figura 1 Práticas da XP.

Figura 2 Motivos da adoção da XP.

LISTA DE FIGURAS

Figura 3 Utilização das práticas da XP.

Figura 4 Combinação da XP com outras metodologias.

Figura 5 Principais metodologias usadas com a XP.

Figura 6 Dificuldades na implantação da metodologia XP.

Figura 7 Práticas mais fáceis de implantar nas organizações pesquisadas.

Figura 8 Práticas mais difíceis de implantar, segundo pesquisa.

Figura 9 Tipos de documentações.

Figura 10 Sucesso do uso da XP na organização.

8


LISTA DE ABREVIATURAS E SIGLAS

ASD Adaptive Programming.

DSDM Dynamic Systems Development Method.

FDD Feature-Driven Development.

XP Extreme Programming.

XP2 Extreme Programming segunda versão.

9


SUMÁRIO

1 INTRODUÇÃO...................................................................................................... 12

2 DESENVOLVIMENTO ÁGIL.............................................................................. 14

2.1 Movimento ágil................................................................................................. 14

2.2 Metodologia ágil ............................................................................................... 15

3 EXTREME PROGRAMMING ............................................................................... 17

3.1 Valores do XP...................................................................................................... 17

3.1.1 Retorno(Feedback)......................................................................................... 18

3.1.2 Comunicação.................................................................................................. 18

3.1.3 Simplicidade .................................................................................................. 19

3.1.4 Coragem......................................................................................................... 19

3.2 Princípios do XP.................................................................................................. 20

3.2.1 Feedback rápido ............................................................................................. 20

3.2.2 Simplicidade presumida ................................................................................. 21

3.2.3 Mudanças incrementais .................................................................................. 21

3.2.4 Aceitação das mudanças................................................................................. 21

3.2.5 Alta qualidade ................................................................................................ 22

3.2.6 Ensinar aprendendo ........................................................................................ 22

3.2.7 Investimento inicial pequeno .......................................................................... 22

3.2.8 Jogar para ganhar ........................................................................................... 22

3.2.9 Experimentação concreta................................................................................ 23

3.2.10 Comunicação honesta e franca...................................................................... 23

3.2.11 Trabalhar a favor dos instintos do pessoal e não contra eles.......................... 23

3.2.12 Aceitação de responsabilidades..................................................................... 24

3.2.13 Adaptação local............................................................................................ 24

3.2.14 Viajar com pouca bagagem........................................................................... 24

3.2.15 Métricas genuínas......................................................................................... 25

3.3 Práticas do XP..................................................................................................... 25

3.3.1 A equipe (whole team).................................................................................... 26

3.3.2 Jogo do planejamento(planning game) ........................................................... 26

3.3.3 Teste de aceitação(customer tests) .................................................................. 27

3.3.4 Pequenos lançamentos(small releases) ........................................................... 27

3.3.5 Design simples(simple design)........................................................................ 27

3.3.6 Programação em par(pair programming)........................................................ 28

3.3.7 Desenvolvimento orientado a testes(test-driven development)......................... 29

3.3.8 Refinamento do design(refactoring) ............................................................... 29

3.3.9 Integração contínua(continuous integration)................................................... 29

3.3.10 Posse coletiva(collective ownership)............................................................. 30

3.3.11 Padrões de codificação(coding standards) .................................................... 30

3.3.12 Metáfora(metaphor) ..................................................................................... 31

3.3.13 Ritmo saudável(sustainable pace) ................................................................ 31

3.4 Mudanças no XP ................................................................................................. 31

3.4.1 Valores........................................................................................................... 32

3.4.2 Princípios ....................................................................................................... 32

3.4.3 Práticas........................................................................................................... 32

4 ESTUDO DE CASO............................................................................................... 33

5 CONSIDERAÇÕES FINAIS................................................................................. 41


REFERÊNCIAS BIBLIOGRÁFICAS..................................................................... 42

ANEXOS ................................................................................................................... 44

Anexo I................................................................................................................... 44

11


1 INTRODUÇÃO

Com o mercado cada vez mais competitivo, técnicas de programação surgem

para suprir as necessidades e agilizar o processo de desenvolvimento de sistemas. Por

isso as organizações estão cada vez mais preocupadas em ter qualidade em seus

processos, visando o produto final e um dos problemas que afetam o desenvolvimento

de software é a enorme quantidade de detalhes que precisam ser considerados.

Normalmente, ao especificar um sistema, o cliente tem o conhecimento de

alguns aspectos do software que deseja, mas muitos outros só ficam claros quando ele

tem a oportunidade de utilizar o sistema. Portanto, o cliente não especifica estes

detalhes no início do projeto por uma razão muito simples: ele não os conhece (BECK,

2000). Além do mais, mesmo que tais detalhes fossem conhecidos previamente, seria

muito difícil especificá-los através de documentos devido à grande quantidade de

elementos que precisariam ser descritos.

O movimento ágil conseguiu abertura para muitas novas idéias de

desenvolvimento de softwares, mas ganhou força em 2001 com a publicação do

manifesto ágil de desenvolvimento de software, que define os seguintes princípios:

Indivíduos e interações são mais importantes que processos e ferramentas.

Software funcionando é mais importante do que documentação completa e

detalhada.

Colaboração com o cliente é mais importante do que negociação de

contratos.

Adaptação a mudanças é mais importante do que seguir o plano inicial.

Esses princípios buscam tornar o desenvolvimento de software um pouco mais

simples, com qualidade e rapidez do que os modelos tradicionais, onde o qual tem tido

um aumento de adeptos da nova maneira de desenvolver sistemas.

O desenvolvimento ágil se baseia na premissa de que o cliente aprende ao

longo do desenvolvimento, à medida que é capaz de manipular o sistema. O

aprendizado decorre do feedback que o software oferece ao cliente quando este o

manipula, pois está presente ao longo de todo o desenvolvimento do software e exerce

um papel fundamental (MANHÃES, 2004).

12


A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas

perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os

requisitos estão emergindo e mudando rapidamente, embora não exista um consenso

completo neste ponto (COHEN et al, 2004).

Hoje em dia com as rápidas mudanças, seja em tecnologia, requisitos e perfil

do consumidor as empresas têm que se adaptar a essa nova realidade.

Com a metodologia ágil, que consiste em um conjunto de práticas, definiu um

novo conceito e a mais conhecida é Extreme Programming (XP), que é uma técnica de

desenvolvimento de software que vai contra uma série de premissas adotadas por

métodos mais tradicionais de desenvolvimento, XP consiste numa série de práticas e

regras que permitem aos programadores desenvolver software de uma forma dinâmica e

muito ágil considerando aspectos que se aplicam no conceito de agilidade, custo, escopo

e qualidade no desenvolvimento de sistemas (BECK, 2000). O objetivo deste projeto é

apresentar as práticas da XP e sua aplicabilidade dentro das organizações de

desenvolvimento de software, buscando novos adeptos e levando a metodologia ao

conhecimento amplo a todos.

Este trabalho busca contribuir com empresas e pesquisadores que tenham

interesse em conhecer a metodologia XP em seus princípios e práticas aplicados em

organização e algumas de suas características quanto a sua aplicação.

Este trabalho está organizado em cinco capítulos, ao qual, no capítulo dois trata

do desenvolvimento ágil, já no capítulo três aborda Extreme Programming, no capítulo

quatro trata do estudo de caso com empresas que utilizam XP como metodologia de

desenvolvimento, no capítulo cinco será analisado o estudo de caso.

13


2 DESENVOLVIMENTO ÁGIL

O manifesto de desenvolvimento ágil, no qual, questionam práticas de

engenharia de software, foi proposto por um grupo de especialistas em desenvolvimento

de software por causa de diversos fracassos, estouros de prazos e orçamento dos

métodos tradicionais de desenvolvimento de software.

O manifesto defende o que necessita ser valorizado ao se desenvolver software,

a comunicação entre os indivíduos, o código fonte funcional, a colaboração com o

cliente (AGILCOOP, 2007).

2.1 Movimento ágil

Segundo Manhães (2007), o movimento ágil foi iniciado por programadores e

consultores experientes, originando uma nova forma de desenvolvimento de software

em curto tempo com qualidade. Porém, só ganhou forças com a publicação do

manifesto ágil em fevereiro de 2001.

O movimento define alguns princípios:

Indivíduos e interações são mais importantes que processos e ferramentas.

Software funcionando é mais importante do que documentação completa e

detalhada.

Colaboração com o cliente é mais importante do que negociação de

contratos.

Adaptação a mudanças é mais importante do que seguir o plano inicial.

O desenvolvimento de software ganhou uma nova forma de criação com maior

rapidez e aceitação do cliente, ou seja, o manifesto ágil não rejeita os processos, a

documentação, a negociação de contratos ou o planejamento, mas, simplesmente mostra

que eles possuem importância secundária quando comparado com os indivíduos e

14


interações, com o software executável, com a colaboração do cliente e as respostas

rápidas a mudanças e alterações.

2.2 Metodologia ágil

Como reação às metodologias tradicionais, consideradas muito pesadas para

equipes pequenas, um novo grupo de metodologias surgiu, chamado de metodologias

ágeis, entre as quais a XP se enquadra e, propõem uma diminuição na burocracia do

desenvolvimento de software (NAPHTA, 2007).

Além da XP existem outras metodologias ágeis, entre elas:

1. Crystal Clear.

2. Scrum.

3. DSDM.

4. FDD.

5. ASD.

A XP foi criada nos Estados Unidos ao final da década de 90 e vem fazendo

sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, em menor

tempo e de forma mais econômica que o habitual.

Indicada para equipes pequenas e médias de desenvolvimento, às quais tem que

lidar com requisitos vagos ou em constante mudança surgiu com a proposta de aumentar

o foco nas pessoas e não nos processos de desenvolvimento. Além disso, existe a

preocupação de se gastar menos tempo com a documentação e mais com a resolução do

problema, gerando produtos com melhor aceitação e qualidade (IMPROVEIT, 2007).

Tais objetivos são alcançados devido a um conjunto de valores, práticas e

princípios, que diferem da forma tradicional de se desenvolver software.

Segundo Fowler (2007), as duas principais diferenças entre as metodologias

ágeis e as tradicionais:

Elas são adaptativas, ao invés de previsivas – as metodologias tradicionais

tentam planejar uma grande parte do software em muitos detalhes com

bastante antecedência. Por isto elas são resistentes à mudança. Já nas

metodologias ágeis, as mudanças de requisitos durante o desenvolvimento

15


são bem-vindas. Elas tendem a ajustar o desenvolvimento do software às

mudanças de requisitos, tornando-se mais flexíveis.

Elas são orientadas às pessoas, não aos processos – a meta das metodologias

de desenvolvimento é desenvolver um processo que vai funcionar da mesma

maneira, independente de quem o esteja utilizando. Metodologias ágeis

levam mais em conta a habilidade da equipe de desenvolvimento e, tendem

por isto, a se ajustar à equipe.

Pesquisas feitas pelo Standish Group International em 1994, apontam que

apenas 16,2% dos projetos de software atingiam sucesso, já em 2002 esta taxa havia

subido para 34%, ou seja, aumento de 100% em 8 anos. Mas estas taxas ainda se

encontram muito aquém do esperado pelo mercado.

As metodologias utilizadas nos projetos pesquisados eram as mais variadas,

entre elas o modelo em cascata, modelo interativo e alguns modelos de prototipação

(JAVAFREE, 2007).

16


3 EXTREME PROGRAMMING

XP é uma abreviação de Extreme Programming (programação extrema) que é

uma metodologia ágil com foco em qualidades de projetos e agilidade de equipes .

Segundo Beck (2000) a XP é uma maneira leve, eficiente, de baixo risco,

flexível, previsível, científica e divertida de se desenvolver software. Distingue-se de

outras metodologias por:

Feedback rápido, concreto e contínuo.

Abordagem incremental de planejamento, obtendo um plano geral do

projeto.

Confiança nos testes automatizados escritos por programadores e clientes

para monitorar o desenvolvimento, evolução e detecção de erros nos

projetos, dentre outras.

É voltada para projetos cujos requisitos são vagos e mudam com freqüência,

equipes pequenas (em geral, 12 desenvolvedores), desenvolvimento de sistemas

orientados a objeto e incremental.

XP é um processo de desenvolvimento que busca assegurar que o cliente

receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento e é

organizado em torno de um conjunto de valores e práticas que atuam de forma

harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do

investimento em software (MANHÃES, 2004).

3.1 Valores da XP

XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do

cliente, além de favorecer o cumprimento das estimativas, proporcionando um

agradável ambiente de desenvolvimento de software para os seus seguidores, que são

conduzidos por quatro valores: Retorno(feedback), Comunicação, Simplicidade e

Coragem (SOARES, 2007).

17


3.1.1 Retorno (Feedback)

do cliente.

O retorno constante significa que o programador terá informações do código e

A informação do código é dada pelos testes, que indicam os erros tanto

individuais quanto do software integrado (SOARES, 2007).

O cliente recebe o sistema o quanto antes, afim de dar um retorno rápido,

guiando assim o desenvolvimento do software (NAPHTA, 2007).

Pode-se, com isso, reavaliar necessidades com relação às funcionalidades

apresentadas, e também com relação às futuras.

3.1.2 Comunicação

A forma de comunicação é um fator chave na XP: procura-se o máximo

possível comunicar-se pessoalmente, evitando o uso de telefone e o envio de mensagens

por correio eletrônico (SOARES, 2007). É através dela que o cliente e o time irão tratar

dos detalhes do projeto, devendo ser feito com atenção e agilidade, buscando o melhor

relacionamento possível entre clientes e desenvolvedores e entre os desenvolvedores e o

gerente do projeto.

Segundo Beck (2000), analisando os problemas que ocorreram nos projetos,

muitos foram provocados por alguém que não conversou com outro sobre algo

importante. Algumas vezes o programador não fala para os outros uma mudança

fundamental no projeto, outras vezes, o programador não faz a pergunta correta para

cliente, fazendo com que uma importante decisão de domínio seja prejudicada.

A comunicação é o principal valor da XP, a maioria das práticas está baseada

nela, e se esta não for eficiente, pode causar problemas e atrasos no desenvolvimento do

sistema (NAPHTA, 2007).

18


3.1.3 Simplicidade

Conseguindo que o time entenda essa importância, é possível simplificar o

sistema podendo até diminuir o número de programadores ou o tempo de

implementação, ou seja, reduzir o valor do projeto.

XP aposta que é melhor fazer algo simples e de desenvolvimento rápido hoje, e

ter de gastar um pouco mais no futuro se for necessário para fazer modificações

necessárias do que implementar algo complicado hoje que talvez não venha a ser usado

(NAPHTA, 2007).

Ao codificar uma funcionalidade devem se preocupar apenas com os

problemas de hoje e deixar os problemas do futuro para o futuro, sem tentar prevê-lo,

pois raramente irá acertar.

Evitando especular sobre o futuro, o time ganhará tempo e permite que o

cliente tenha acesso à funcionalidade rapidamente, podendo utilizá-lo no seu negócio,

gerando valor e tornando viável que ele dê feedback para a equipe o quanto antes

(MANHÃES, 2004).

Segundo Beck (2000), simplicidade e comunicação têm uma relação de suporte

mútuo. Quanto maior a comunicação, mais claramente se observa o que precisa ser feito

e tem-se mais certeza do que não precisa.

3.1.4 Coragem

Como o sistema é desenvolvido de forma incremental, o time estará sempre

fazendo manutenção do software ou adicionando novas funcionalidades. Algumas vezes

será necessário alterar algo que estava funcionando corretamente, o que poderá gerar

falha. Daí a necessidade do time ter coragem e acreditar que com as práticas e valores

da XP o software será desenvolvido de forma segura e ágil.

Segundo MANHÃES (2004), XP não tem uma solução mágica para eliminar

esse risco, ele existe como em qualquer outro projeto, o que muda é a forma de lidar.

19


Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando pode

acontecer eventualmente. É necessário ter coragem para lidar com esse risco, o que em

XP se traduz em confiança nos seus mecanismos de proteção.

A comunicação dá suporte à coragem porque abre a possibilidade para mais

experiências de alto risco e alta recompensa. A simplicidade também dá suporte a

coragem, pois podemos ser muito mais corajosos com um sistema simples e é menos

provável que estrague o sistema. O feedback concreto dá suporte à coragem, porque

temos a confiança de experimentar algo extremo no código e obter os resultados

positivos nos testes, ou não (BECK, 2000).

3.2 Princípios da XP

Alguns princípios da XP vão contra as técnicas de engenharia de software

tradicionais, uma vez que nela o foco principal é nas pessoas e não nos processos

formais.

XP coloca seus princípios em níveis extremos, por isso extreme no nome e

incorpora os valores neles.

3.2.1 Feedback Rápido

É importante o cliente fornecer esse feedback em relação ao sistema o mais

rápido possível, pois o tempo decorrido entre uma ação e seu feedback é fundamental

para o progresso do projeto e aprendizado da equipe.Tendo este feedback rápido pode-

se interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível.

Os programadores aprendem qual a melhor forma de se projetar, implementar e

testar o sistema, e realimentam o que foi aprendido em segundos ou minutos, em vez de

dias, semanas ou meses (BECK, 2000).

20


3.2.2 Simplicidade presumida

Tratar cada problema da maneira mais simples possível, XP recomenda que os

trabalhos de hoje sejam resolvidos hoje e que os desenvolvedores confiem em suas

habilidades.

Segundo Beck(2000), esse princípio os programadores têm mais dificuldades

de aceitar. Tradicionalmente, somos orientados a planejar para o futuro, para se poder

reutilizar.

3.2.3 Mudanças incrementais

Grandes mudanças de uma só vez em qualquer projeto é muito difícil que dê

certo, no XP o projeto é alterado gradualmente em seu tempo de desenvolvimento. Essa

mudança deve ser planejada e estudada para que não atrapalhe o funcionamento normal

do sistema, a própria metodologia XP precisa ser feita em pequenos passos (BECK,

2000).

3.2.4 Aceitação das mudanças

Como em todo XP, a aceitação de mudanças é bem vinda, e não questionada.

Segundo Beck (2000), a melhor estratégia é aquela que preserva o maior números de

opções enquanto resolve o seu problema mais urgente.

As mudanças servem também como aprendizado, amadurecimento da equipe

de desenvolvimento de software.

21


3.2.5 Alta qualidade

Esse ponto não se tem negociação, qualidade é prioridade em projetos XP,

sempre em busca da excelência, caso contrário o projeto foi um fracasso.

3.2.6 Ensinar aprendendo

É proposto que ao contrário de criar “manuais doutrinários” mostrando passo-

a-passo o que? E como fazer? O foco é ensinar estratégias para aprender quantos testes,

refatoração e quanto de todas as outras coisas deve ser feito (BECK, 2000).

3.2.7 Investimento inicial pequeno

Em projetos em que os recursos são supérfluos, é um caminho para o desastre,

por isso temos que ter em mente apenas requisitos necessários.

Orçamento apertado força o programador e o cliente a cortar requisitos e

reduzir propostas, pois a concentração gerada leva a fazer um bom trabalho.

Segundo Beck (2000), na maioria das vezes, todos podem viver com menos

recursos do que gostariam, mas atenta também que recursos apertados demais pode

gerar um sistema nada interessante.

3.2.8 Jogar para ganhar

Muitas equipes de desenvolvimento de software seguem procedimentos

estabelecidos em reuniões, para se guardarem de futuras falhas no projeto, isto é jogar

22


para não perder, caso no final o projeto não seja bem sucedido, a equipe se resguarda

que seguiu os procedimentos.

Extreme programming acredita que o desenvolvimento de software jogado para

ganhar faz tudo que ajuda o time a chegar na excelência do projeto e nada daquilo que

não alcançar o objetivo (BECK, 2000).

3.2.9 Experimentação concreta

Segundo Beck (2000), toda decisão abstrata deve ser testada, quanto mais se

testa, mais os riscos se diminuem, pois a cada decisão tomada e não testada existe uma

probabilidade de que a decisão esteja errada, e gera insatisfação do cliente e até mesmo

da equipe.

3.2.10 Comunicação honesta e franca

A comunicação é um fator importante, e esse princípio permite o programador

a ter liberdade em falar um ao outro onde o código encontra-se com problema,

comunicar má noticias a gerência e à clientes.

Beck (2007) afirma, que os desenvolvedores precisam ter liberdade de

expressar seus receios e precisam receber apoio.

3.2.11 Trabalhar a favor dos instintos do pessoal e não contra eles

Pessoas gostam de aprende, de ganhar, de interagir com outras pessoas, de

estar no controle e que confiem nelas. Em particular desenvolvedores gostam de fazer

um bom trabalho e que seus softwares funcione.

23


Se a XP não trabalhar com os interesses de curto prazo do pessoal, ela estará

destinada ao fracasso das metodologias.

2000).

XP é como a observação de programadores no seu habitat natural (BECK,

3.2.12 Aceitação de responsabilidades

A cooperação do time depende da responsabilidade perante suas tarefas. Para

que seja aplicada de melhor maneira possível a responsabilidade deve ser aceita e não

imposta, sendo que as necessidades do time, em qualquer âmbito, devem ser atendidas

por um elemento voluntário do time, por pior que ela seja (BECK, 2000).

3.2.13 Adaptação local

Na adoção da metodologia ágil extreme programming, deve-se adaptar o seu

ambiente de trabalho às condições em que se propõe desenvolver sistemas.

Adotar XP não significa seguir suas práticas metodicamente, e sim, saber

adaptá-las à sua realidade (BECK, 2000).

3.2.14 Viajar com pouca bagagem

Times XP estão sempre preparados para eventuais mudanças, mas mantendo

sempre o padrão de valor para o cliente, testes e código (BECK, 2000).

Essas mudanças podem ser o design, o cliente que resolve mudar de idéia,

membro da equipe que vai embora ou mesmo uma tecnologia que não supre as

necessidades do projeto.

24


3.2.15 Métricas genuínas

Para obter o controle do desenvolvimento de software adota-se certas métricas,

às quais forçam um nível de detalhamento excessivo que não é suportado pelos

desenvolvedores, por isso, devem-se adequar as métricas que estejam correlacionadas

ao perfil de trabalho do time (BECK, 2000). Por isso equipes XP estimam as estórias

dos cliente, e sempre

3.3 Práticas da XP

Conjunto de atividades, conforme figura 1, que as equipes de XP tem como

base para seu desempenho, tem-se uma confiança muito grande nas práticas onde, os

pontos fracos de uma se compensa nos pontos fortes de outra.

Aplicadas em conjunto o desenvolvimento de software funciona melhor

tornando mais eficaz.

Figura 1: Práticas XP

Fonte: XPROGRAMMING, 2007

25


3.3.1 A equipe (whole team)

seguintes papéis:

Todos em um projeto XP são parte de uma equipe, no qual é composta pelos

Desenvolvedor: É a pessoa que constrói o software, análise, projeta e

codifica o sistema.

Redator Técnico: Auxilia a equipe na parte de documentação do projeto.

Analista de Teste: Ajuda o cliente a definir requerimentos e procura fazer

26

com que eventuais defeitos do sistema sejam identificados o quanto antes.

Gerente: Responsável pela parte administrativa e relacionamento com o

cliente, garante os recursos necessários para o projeto.

Coach: Pessoa com responsabilidade técnica do projeto, orienta a equipe e

controla a aplicação da XP.

3.3.2 Jogo do planejamento (planning game)

Esta prática define estimativas e prioridades. Em XP todo projeto é dividido

em release e iterações, com isso, equipe e cliente podem se reunir para rever o

planejamento.

O cliente em cada reunião recebe um cartão no qual descreve as

funcionalidades que deseja do sistema, que se chama de estórias, e no jogo do

planejamento se estima cada estória para o cliente saber o custo da implementação

(JAVAFREE, 2007).

Como uma estória não descreve os detalhes da funcionalidade, quando um par

de desenvolvedores for implementá-la, devem buscar estes detalhes com o cliente. As

estórias também são usadas como uma forma de documentação do projeto.

Segundo Beck (2000), o desenvolvimento de software é sempre um diálogo

evolutivo entre o possível e o desejável, as pessoas da área do negócio precisam decidir

sobre: o escopo, prioridade, composição das versões e datas de entrega.


A área de negócio não consegue tomar essas decisões no vácuo, a partir de

nada, a área de desenvolvimento precisa tomar decisões técnicas para auxiliar nas

decisões de negócio.

3.3.3 Teste de aceitação (customer tests)

Verifica se a interação entre as classes que implementam uma funcionalidade

atende a necessidade descrita na estória do cliente, facilitando ainda mais a interação

entre as partes.

3.3.4 Pequenos lançamentos (small releases)

comprando.

Liberação de pequena versão ao qual o cliente testa parte do sistema que está

Como o objetivo da XP é gerar um fluxo contínuo de valor para o cliente, as

releases devem ser curtas. Assim, coloca-se rapidamente em produção um conjunto

reduzido de funcionalidades, para que o cliente possa beneficiar-se o quanto antes. Cada

vez que o sistema for colocado em produção, novas funcionalidades deverão ser

adicionadas gerando maior valor agregado ao produto final (MANHÃES, 2004).

3.3.5 Design simples (simple design)

A equipe em cada interação(estória) pensa em uma arquitetura simples em

questão, mesmo conhecendo interações futuras, isto ajuda no caso de haver alterações

nos requisitos.

Ao desenvolver um código, deve-se focar em atender às necessidades da

funcionalidade que está sendo implementada, sem preocupar-se em prepará-lo para

27


necessidades futuras. Isso leva a um desenvolvimento muito mais ágil (MANHÃES,

2004).

O projeto correto é aquele que:

1. Executa todos os testes.

2. Não possui lógica duplicada.

3. Expressa todas as intenções importantes para os programadores.

4. Tem o menor número possível de classes e métodos.

Cada parte do projeto do sistema precisa justificar sua existência nesses termos (BECK,

2000).

3.3.6 Programação em par (pair programming)

Estilo de programação ao qual se tem uma segurança na redução de risco do

projeto. Um desenvolver programa (condutor) e o outro fazem uma inspeção no código

gerado (navegador). Normalmente o navegador é o programador com maior experiência

e o condutor novato ou com experiência menor, e este, que fica na condição de gerar os

comando, enquanto o outro, o navegador, trabalha como um instrutor, gerando assim

uma redução de bugs, aprendizado rápido, solução mais simples e eficaz para o

problema.

Está prática consegue-se uniformizar o nível dos desenvolvedores da equipe,

logo, todos terão conhecimento do projeto como um todo (MANHÃES, 2004).

A programação em par é dinâmica, se duas pessoas formam um par pela

manhã, à tarde elas podem facilmente formar duplas com outros colegas (BECK, 2000).

28


3.3.7 Desenvolvimento orientado a testes (test-driven development)

Segundo Manhães (2004), uma equipe XP está acostumada com os teste, pois

assim garante o funcionamento pleno do sistema, primeiro cria-se o teste unitário de

cada funcionalidade antes da codificação. O uso de ferramentas de automação de testes

poderá reduzir o esforço desta prática. Dessa maneira, pode-se melhorar o entendimento

das necessidades, o design e mantendo a simplicidade do código. Sua principal

importância é a alta qualidade do sistema

Os programadores escrevem testes de unidade para que sua confiança na

operação do programa possa se tornar parte do programa. O resultado é um programa

que se torna cada vez mais confiável com o tempo, tornando-se capaz de aceitar

modificações, e não menos (BECK, 2000).

3.3.8 Refinamento do design (refactoring)

A equipe altera pequenas partes do sistema, freqüentemente, sempre que

encontram uma oportunidade para melhorar o código, dando maior clareza (leitura) do

código, tendo um reaproveitamento, evitando a duplicação de código-fonte e fácil de ser

compreendido.

Segundo Beck (2000), a refatoração é feita quando o programa necessita,

quando o sistema requer código duplicado, e ainda mantendo todos os testes

funcionando.

3.3.9 Integração contínua (continuous integration)

A cada nova funcionalidade produzida e testada integrar à versão final do

sistema, sempre tendo a versão atualizada.

29


Como se trata de uma equipe, pode ocorrer de dois ou mais desenvolvedores

terem que alterar determinados arquivos, com isso, o objetivo é ter o código fonte

sempre atualizado, utiliza-se um sistema de controle de versão ou repositório.

Com isto, pequenos problemas de integração podem ser descobertos e

corrigidos logo no início (MANHÃES, 2004).

3.3.10 Posse coletiva (collective ownership)

Todos em um projeto tem acesso a todo o código e liberdade para alterar, por

isso os pares de programadores se revezam ou seja, o código é coletivo, todos são

responsáveis por ele.

Na XP, todos são responsáveis pelo sistema inteiro. Nem todos conhecem

todas as partes igualmente bem, mas todos sabem um pouco sobre cada parte. Se um par

está trabalhando e vê uma oportunidade de melhorar o código, eles vão em frente e o

melhoram (BECK, 2000).

Segundo Manhães (2004), como outros irão ler o código no futuro próximo, é

importante que ele seja sempre escrito da maneira mais legível possível. Por isto é o que

garantirá que a equipe conseguirá continuar a implementar o sistema e leva a equipe a

ser mais ágil no desenvolvimento.

Esta prática depende fortemente de duas outras: refatoração e o

desenvolvimento guiado por testes.

3.3.11 Padrões de codificação (coding standards)

devem seguir.

A equipe XP tem que criar regras para programação, um padrão que todos

A equipe deve se comunicar de forma clara através do código, assim como faz

verbalmente ou através de modelos. Para ajudar neste sentido, a XP sugere a utilização

de padrões de codificação (MANHÃES, 2004).

30


O Padrão adotado deve exigir a menor quantidade de trabalho possível,

consistente com a regra do “uma e somente uma vez” (sem código duplicado). O padrão

deve enfatizar a comunicação. Finalmente, o padrão deve ser adotado voluntariamente

por todo o time (BECK, 2000).

3.3.12 Metáfora (metaphor)

Procura facilitar a comunicação entre desenvolvedor e o cliente, estabelecendo

um vocabulário com o qual o cliente esteja habituado em seu dia-a-dia, de modo a

elevar a compreensão mútua, ajuda todos os envolvidos no projeto a entenderem os

elementos básicos e seus relacionamentos (BECK, 2000).

3.3.13 Ritmo saudável (sustainable pace)

Consiste em trabalhar com qualidade, respeitando a individualidade e o físico

de cada desenvolvedor, sem horas extras. XP sugere um ritmo de 40 horas/semana, o

horas/dias, nunca exceder estas horas duas semanas seguidas (JAVAFREE, 2007).

Trabalhar por longos períodos é contraproducente.

3.4 Mudanças no XP

As mudanças propostas por Kent Beck e Cynthia Andrés são referenciadas

como a XP2, devido ao fato de terem reescrito a metodologia, mantendo a proposta

inicial de Beck, mas buscando o lado mais humano nos princípios, valores e práticas.

31


3.4.1 Valores

Aos já conhecidos valores da XP Comunicação, simplicidade, feedback e

coragem, no XP2 acrescenta um novo valor o de respeito. Tornando a necessidade de se

criar bons relacionamentos entre as pessoas envolvidas no projeto.

3.4.2 Princípios

Os princípios com maior importância, pois são os guias específicos ao contexto

do desenvolvimento de software.

Segundo Beck e Andrés(2004), os princípios ajudam na adaptação da XP para

a realidade de cada um, por isso, á necessidade de identificar princípios particulares em

cada ambiente de trabalho.

3.4.3 Práticas

Embora as 13 práticas ainda representam a essência da XP, muitas delas foram

renomeadas, novas práticas foram acrescentadas na metodologia e outras foram

subdivididas.

A grande mudança da XP para o XP2, encontra-se na separação entre as

práticas primárias e práticas corolárias ou resultante.(JAVAMAGAZINE).

Segundo Beck e Andres(2004), as práticas primárias podem ser aplicadas

individualmente e o resultado implicará em melhoria imediata no processo de

desenvolvimento da equipe. Já as corolárias precisam que as práticas primárias já

estejam em funcionamento para que possam contribuir efetivamente para a melhoria do

trabalho.

32


4 ESTUDO DE CASO

O estudo de caso representa uma pesquisa de campo realizado com empresas

que de uma forma ou de outra tiveram contato com a XP.

Para a pesquisa, foi desenvolvido um questionário com 10 (dez) perguntas,

conforme anexo I, no qual lideres de projetos de empresas responderam e auxiliou no

resultado final.

As empresas sujeitas à pesquisa foram selecionadas pelos seguintes critérios:

Conhecimento da XP.

Empresa ligada a tecnologia.

Possuir equipe de desenvolvimento.

Experiência em desenvolvimento de sistemas.

O objetivo da pesquisa foi levantar dados para comprovação do uso da

metodologia pelas empresas e seus efeitos.

A região pesquisada foi a Sudeste, com empresas em São Paulo, Rio de Janeiro

e Santa Rita do Sapucaí, de porte pequena, média e grande.

Como resultado, chega-se as seguintes demonstrações abaixo:

O Motivo pela qual as organizações optaram pela metodologia ágil extreme

programming como forma de desenvolvimento de software apura-se na figura 2, ao

qual, conseguimos observar a importância que as organizações estão tendo para a

qualidade de seus produtos.

33


33,40%

16,65% 16,65% 16,65% 16,65%

Qualidade Agilidade Produtividade Confiabilidade Adaptação da equipe

Figura 2: Motivos da adoção da XP

Mesmo com todas as afirmações sobre a XP, ainda as organizações estão

cautelosas quanto à forma de desenvolvimento de sistemas propostos pela XP,

conforme ilustra a figura 3.

34


37,50%

25%

12,50% 12,50% 12,50%

Todas Pequenos Lançamentos Integração contínua Jogo do Planejamento Metáfora

Figura 3: Utilização das práticas da XP

Nas figuras 4 e 5, nota-se que as organizações utilizam a XP com outras

metodologias, ou seja, adaptam a XP com o perfil da equipe de desenvolvimento,

buscando sempre a qualidade final, e utilizam também como maneira de integrar XP

sem muitas resistências.

35


80%

20%

Sim Não

Figura 4: Combinação da XP com outras metodologias

50%

25% 25%

Scrum Lean CMM

Figura 5: Principais metodologias usadas integradas a XP

36


Na implantação da XP, como a metodologia tem foco diferenciado das

metodologias tradicionais, encontra-se algumas facilidades e muitas resistências quanto

ao uso das práticas proposta por Kent Beck, no estudo de caso temos nas figuras 6, 7 e 8

o demonstrativo dessas facilidades e resistências.

33,40%

16,60% 16,60%

33,40%

Vender a idéia utilização da metodologia pura falta de presença do cliente Resistência de gerentes

Figura 6: Dificuldades na implantação da XP

37


22,20% 22,20% 22,20%

11,13% 11,13% 11,13%

Programação em par Código coletivo Pequenos lançamentos Jogo do planejamento Testes de aceitação Integração contínua

Figura 7: Práticas mais fáceis de implantar nas organizações pesquisada

16,65% 16,65%

Desenvolvimento orientado

a teste

.

33,40%

16,65% 16,65%

38

Jogo do Planejamento Programação em par Metáfora Pequenos lançamentos

Figura 8: práticas mais difíceis de implantar, segundo pesquisa


11,11% 11,11% 11,11%

cronograma de projeto documento de

acompanhamento de

bugs

22,22% 22,22% 22,22%

39

documento de testes javadoc quadros brancos diagramas UML

Figura 9: Tipos de documentações

Foi analisado, pela figura 9, os tipos de documentações utilizados nos projetos

nas empresas entrevistadas. Já na figura 10, ilustra o uso da metodologia nas

organizações foi bem sucedido, ou não.


80%

20%

sim sim, mas adaptado

Figura 10: Sucesso do uso da XP na organização

40


5 CONSIDERAÇÕES FINAIS

Analisando os fatos da pesquisa realizada, nota-se que muitas organizações

adotam a metodologia XP como alternativa para auxiliar no processo de

desenvolvimento de softwares, para atender a clientes visando cumprir o cronograma e

obter a satisfação do cliente juntamente com a qualidade.

Em um projeto de software, arrumar bugs, ou seja, reparar erros do sistema é a

parte mais cara para o cliente, pois esses bugs traumáticos são encontrados tardios nos

processos tradicionais e com as metodologias ágeis são encontrados mais cedo, durante

o desenvolvimento, tornando-se menos traumáticos. Este é apenas um dos ganhos que a

metodologia proporciona.

Muitas organizações deixam de usar XP por falta de conhecimento da

metodologia e por resistências de toda a equipe, sem a aprovação e colaboração de

todos os membros da empresa, não se obtém o sucesso que a XP gera, pois a

metodologia é voltada para o lado humano. Os problemas no desenvolvimento de

sistemas estão mais relacionados com pessoas, fator humano, do que com a tecnologia.

Muitas empresas e colaboradores amam XP e já outros odeiam não se encontra

meio termo para essa questão, o próprio nome da metodologia gera certo pânico em

algumas pessoas. Programação extrema, para quem adora programar se considera que

está em casa, mas para aquele que não gosta de programação certamente fará com que

não se adotem a metodologia, e na verdade não é isso que a XP propõem. Ao contrário

do que pensam XP não é somente programação, XP se planeja, estima, documenta, mas

de um modo bem diferenciado.

Apesar da resistência inicial de algumas equipes, quem utiliza XP não volta a

utilizar metodologias tradicionais, procura sempre adaptar XP para cada projeto, pois a

metodologia permite essa adaptação para o perfil da equipe ou projeto. Isto se deve ao

fato da XP impactar muito mais positivamente do que negativamente no processo de

desenvolvimento de software da organização.

41


REFERÊNCIAS BIBLIOGRÁFICAS

AGILCOOP, disponível em

http://agilcoop.incubadora.fapesp.br/portal/eventos/seminarioUNICAMP/ acessado em

02 de Setembro de 2007.

AGILCOOP 2, disponível em http://agilcoop.incubadora.fapesp.br/portal/agilvideo

acessado em 14 de Setembro de 2007.

BECK, Kent. Extreme Programming Explained.,New York: 2000, Addison Wesley.

BECK, Ken; ANDRÉS Cynthia.. Extreme Programming Explained Embrace

Chance .,New York: 2004, Addison Wesley.

COHEN, D.; LINDVALL, M.; COSTA, P. An introduction to agile methods. In

Advances in Computers. New York: 2004, Elsevier Science.

FOWLER, Martin,

http://www.naphta.com.br/xpmanager/xpmanager_metodologiasageis.html acessado em

21 de Agosto de 2007.

IMPROVEIT, disponível em www.improveit.com.br/xp, acessado em 16 de Agosto de

2007.

42


JAVAFREE, -Apresentando XP, encante seus clientes com Extreme Programming,

disponível em www.javafree.org, acessado em 29 de Janeiro de 2007 as 14:58.

JAVAMAGAZINE, o novo XP Explicado, edição 25 ano III .

MANHÃES, Vinícius Teles. Extreme Programming - Aprenda como encantar seus

usuários desenvolvendo software com agilidade e alta qualidade, Rio de Janeiro:

2004, Novatec Editora.

NAPHTA, disponível em

http://www.naphta.com.br/xpmanager/xpmanager_metodologiasageis.html acessado em

21 de Agosto de 2007.

SIMPLUS, disponível em http://simplus.com.br/artigos/a-nova-metodologia/ acessado

em 02 de Setembro de 2007.

SOARES, Michel dos S. disponível em

http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf acessado em 21 de Agosto 2007

XPROGRAMMING, disponível em www.xprogramming.com acessado em 12 de

Setembro de 2007.

43


ANEXOS

Anexo I

Pesquisa para o Trabalho de Conclusão de Curso(TCC)

Instituição: Universidade do vale do Sapucaí – UNIVÀS

Curso: Sistemas de Informação

Aluno: Thiago Borborema (thiago_borborema@ yahoo.com.br).

IMPACTO DA UTILIZAÇÃO DA XP NAS ORGANIZAÇÕES DE

DESENVOLVIMENTO DE SOFTWARE.

1. Qual motivo o levou a utilizar a XP?

2. Utiliza todas as práticas da XP? Caso contrário, quais?

3. Possui experiência em outros métodos ágeis ou não? Quais?

4. Utiliza XP combinado com outros métodos?

5. Quais as dificuldades na implantação da XP?

6. A XP é a abordagem mais adequada para sua organização? Justifique.

7. Quais práticas foram mais fáceis de se incorporar em uma organização e

quais as mais difíceis? Por quê?

8. Sua organização você julga madura ou imatura em processo de

desenvolvimento?

9. Utiliza documentação? Quais?

10. Durante a implantação da XP, houve resistência? Como a organização

lidou com isso?

44

More magazines by this user
Similar magazines