Embed Size (px)
Citation preview
UNIFEOB – CENTRO UNIVERSITÁRIO DAFUNDAÇÃO DE ENSINO OCTÁVIO BASTOS
Curso de Sistemas de Informação
O USO DA METODOLOGIA XP
NO DESENVOLVIMENTO DE SOFTWARE
E OS IMPACTOS NA GESTÃO DE RISCOS
JOSÉ GONÇALVES PINTO JÚNIOR
Claudete Moscardini
SÃO JOÃO DA BOA VISTA – SP
2009
JOSÉ GONÇALVES PINTO JÚNIOR
O USO DA METODOLOGIA XP NO DESENVOLVIMENTO
DE SOFTWARE E OS IMPACTOS NA GESTÃO DE RISCOS
Trabalho de Conclusão de Curso realizado na área
de Engenharia de Software como requisito legal
para a obtenção do Grau de Bacharel em Sistemas
de Informação no Curso de Sistemas de Informação
da UniFEOB – Centro Universitário da Fundação de
Ensino Octávio Bastos de São João da Boa Vista -
SP, sob orientação da Profa. Claudete Moscardini.
SÃO JOÃO DA BOA VISTA
2009
DECLARAÇÃO DE APROVAÇÃO
Declaro para fins de avaliação de desempenho escolar, que o aluno José
Gonçalves Pinto Júnior, apresentou o Trabalho de Conclusão de Curso intitulado O uso da
Metodologia XP no desenvolvimento de Software e os Impactos na Gestão de Riscos para
atender às exigências da disciplina de Trabalhos de Conclusão de Curso perante banca
examinadora na UniFEOB – Centro Universitário da Fundação de Ensino Octávio Bastos,
composta pelos seguintes membros:
Profa. Claudete Moscardini – Orientadora
Profa. Adriana Nascimento Costa
Prof. João Sérgio Januzelli de Souza
Diante disto declaro que o referido aluno foi aprovado com a nota 10 (dez), tendo
apresentado este relatório e foi aprovado.
São João da Boa Vista, 24 de Novembro de 2009.
Professor(a) Orientador(a): Claudete Moscardini
DEDICATÓRIA
Dedico este trabalho a minha família e a minha
noiva, pessoas que amo imensamente e agradeço
a Deus todos os dias por tê-las em minha vida.
AGRADECIMENTOS
Primeiramente a Deus que a cada dia me presenteia com o dom da vida, com o ar
que respiro e que nunca me concede nada além do necessário para ser feliz.
Ao meu irmão Jânio e aos meus pais José e Izaulina pela compreensão e amor em
todos os momentos da minha vida. E principalmente, por acreditarem em meus sonhos e se
empenharem tanto quanto eu para que eles se realizassem.
A minha noiva Lizena Cescon pelo simples fato de existir e trazer mais sentido e
felicidade à minha vida. Como se isso já não fosse suficiente, pelo carinho, companheirismo
e amor incondicional durante os inesquecíveis anos de namoro e noivado.
A Isabela, por ser um anjo irradiante de ternura que ficará para sempre em nossos
corações.
A professora Claudete Moscardini pela competência como orientadora e dedicação
na parceria de elaboração desse trabalho.
Ao Camilo Lopes pela generosidade e disponibilidade de ajudar um desconhecido
com sua monografia, mesmo quando este ainda escrevia frases de índio.
A Profa. Laís Tarrasqui pelos esforços desmedidos de ensinar a arte da matemática
muito além da sala de aula.
Ao Roberto Rossi e Leandro Silveira pela oportunidade, confiança e disponibilidade
de compartilhar comigo os segredos “ocultos” da informática.
Aos companheiros do Universo Universitário (Robinson, Eder, Hércules e Bruno)
pela amizade, companheirismo e momentos de distração durante os quatros da faculdade.
Valeu galera!
Ao Jovem Nerd e Azaghâl por ressuscitar meu lado nerd e fazer um excepcional
nerdcast repleto de conhecimento e humor que salvou minhas intermináveis e entediantes
viagens diárias até a faculdade.
Ao Lucas Luis e Elton Mello pelo ano que mais me diverti em sala de aula, pela
amizade que não se acabou com o cursinho e principalmente por convencerem a minha
noiva a romper com o antigo namorado dela pra ficar comigo.
“Os que sonham acordados e trabalham
dormindo nunca realizam seus sonhos. Não
basta sonhar, é preciso estabelecer
prioridades para executar nossas metas. Os
sonhos só se tornam realidade quando são
irrigados pelo suor”
Augusto Cury
RESUMO
Esse trabalho é uma revisão literária, contemplando as palavras – chaves: Software, XP,
Extreme Programming e desenvolvimento ágil. Para produzir software de qualidade com
uma boa relação custo-benefício, a comunidade de software tem enfrentado um grande
desafio na busca de metodologias e ferramentas que auxiliem desenvolvedores e
programadores a fazerem seu trabalho da melhor maneira possível. Atualmente, o
desenvolvimento ágil é o que tem melhor proporcionado este ambiente que o mercado exige
e dentre as metodologias existentes a extreme programming, ou simplesmente XP, é a mais
utilizada. A metodologia XP possui quatro valores extremos: comunicação, feedback,
simplicidade e coragem que são as bases das boas práticas de desenvolvimento que são
descritas ao longo desse trabalho. Um dos fatores que tornaram a XP uma metodologia
eficaz é a integração constante entre cliente e desenvolvedores. Isso favorece para que as
necessidades do cliente sejam rapidamente compreendidas e em seguida implementadas.
Como em qualquer outra metodologia, a XP possui pontos fracos, mas se utilizada de forma
correta, a combinação dos valores e boas práticas criam as condições necessárias para que
uma equipe de desenvolvimento de software obtenha sucesso em seus projetos.
Palavras-Chave: Software, XP, Extreme Programming, desenvolvimento ágil.
ABSTRACT
This work is a literature review, looking at the keywords: Software, XP, Extreme
Programming and agile development. To produce quality software in a cost-benefit analysis,
the software community has faced a big challenge in the search for methodologies and tools
that help developers and programmers to do their job the best way possible. Currently, agile
development is the best that has provided this environment that the market demands and
among the existing methodologies to extreme programming, or just XP, is the most used.
The XP methodology has four extreme values: communication, feedback, simplicity and
courage that are the basis of good development practices that are described throughout this
work. One of the factors that made XP effective methodology is the ongoing integration
between client and developers. It helps to ensure that customer needs are quickly
understood and then implemented. As with any methodology, XP has weaknesses, but if
used correctly, the combination of values and practices create the conditions necessary for a
team of software development is successful in projects.
Keywords: Software, XP, Extreme Programming, agile development
SUMÁRIO
INTRODUÇÃO .................................................................................................................... 11
CAPÍTULO 1. ENGENHARIA DE SOFTWARE ................................................................... 13
1.1 A crise do Software .......................................................................................... 13
1.2 Qualidade de Software ..................................................................................... 16
1.3 Modelos tradicionais de desenvolvimento ......................................................... 19
1.3.1 Modelo em cascata .............................................................................. 19
1.3.2 Modelo incremental .............................................................................. 22
1.3.3 Prototipagem ....................................................................................... 23
CAPÍTULO 2. EXTREME PROGRAMMING ........................................................................ 24
2.1 Desenvolvimento ágil ........................................................................................ 24
2.2 Breve histórico da XP ....................................................................................... 27
2.3 Valores da XP................................................................................................... 28
2.3.1 Comunicação ....................................................................................... 28
2.3.2 Feedback ............................................................................................. 29
2.3.3 Simplicidade ........................................................................................ 31
2.3.4 Coragem .............................................................................................. 31
2.4 Boas Práticas da XP ......................................................................................... 33
2.4.1 Cliente presente ................................................................................... 33
2.4.2 Releases e iterações ............................................................................ 33
2.4.3 Jogo do Planejamento ......................................................................... 34
2.4.4 Metáfora ............................................................................................... 35
2.4.5 Programação em par ........................................................................... 35
2.4.6 Refactoring ........................................................................................... 36
2.4.7 Testes de unidade ............................................................................... 36
2.4.8 Código coletivo ..................................................................................... 38
2.4.9 Código padronizado ............................................................................. 38
2.4.10 Integração continua ........................................................................... 39
2.4.11 Reunião diária .................................................................................... 39
2.4.12 Ritmo sustentável ............................................................................... 39
CAPÍTULO 3. ESTUDO DE CASO ...................................................................................... 40
3.1 Comparativos entre a metodologia XP e o modelo em cascata ......................... 40
3.1.1 Comparativo sobre processos ............................................................. 40
3.1.2 Comparativo sobre a gestão de riscos ................................................. 41
CAPÍTULO 4. CONCLUSÕES ............................................................................................ 44
REFERÊNCIAS ................................................................................................................... 45
LISTA DE ABREVIATURAS
OTAN Organização do Tratado do Atlântico Norte
ISSO International Organization Standardization
IEC International Electrochnical Comission
CIO Chief Information Officer
LISTA DE ILUSTRAÇÕES E FIGURAS
Figura 1 – Resultado do relatório Chaos Research de 1994 ................................................ 15
Figura 2 – Resultado do relatório Chaos Research de 2004 ................................................ 15
Figura 3 – Modelo em cascata ............................................................................................. 20
Figura 4 – Modelo incremental ............................................................................................. 22
Figura 5 – Boas Práticas da XP ........................................................................................... 32
LISTA DE TABELAS
Tabela 1 – Razões para qualidade de um Software ............................................................. 16
Tabela 2 – Comparativo entre os processos da XP e do modelo em cascata ...................... 40
Tabela 3 – Riscos comuns em projetos de Software ............................................................ 41
Tabela 4 – Comparativo entre o grau de risco nas metodologias tradicionais e na XP ........ 42
11
INTRODUÇÃO
O Software representa uma grande proporção do valor total da maioria dos produtos
tecnológicos e sendo essencial para o funcionamento da economia nacional e internacional,
produzir tais softwares com uma boa relação custo-benefício se tornou prioridade e,
consequentemente, a indústria de software tornou-se peça fundamental para o mundo
globalizado (SOMMERVILLE, 2007). O mercado de software é exigente quando o assunto é
produtividade e atributos de qualidade como eficiência, confiabilidade e segurança são
requisitos indispensáveis. Entretanto, por mais que a Engenharia de Software tenha se
esforçado nesses últimos anos para desenvolver técnicas e métodos de desenvolvimento,
em 2004 apenas 29% dos grandes projetos de software foram concluídos dentro do prazo e
do orçamento (STANDISH, 2006).
A tecnologia e as ferramentas de desenvolvimento têm evoluído a um ritmo
exponencial, porém, a metodologia utilizada não tem seguido a mesma velocidade. De
acordo com Pressman (2006), durante os últimos trintas anos, a grande massa da
comunidade de engenharia de software tem utilizado os mesmos modelos de processos de
desenvolvimento. No entanto, uma nova tendência surgiu sutilmente durante a última
década e vem ganhando espaço a cada dia: a metodologia ágil. Dentre as metodologias de
desenvolvimento ágil, tem-se a Extreme Programming, que é abordada neste trabalho, e
segundo Beck (2000, apud BORBOREMA, 2007), esta é uma metodologia eficiente graças a
uma série de princípios e boas práticas que possibilitam aos desenvolvedores trabalharem
de forma ágil, sem deixar de lado aspectos como custo e qualidade de software.
Com a adoção dos valores e boas práticas da XP, espera-se reduzir o tempo de
fabricação e manutenção de software, agregando maior valor de custo versus benefício ao
produto. Nesse sentido, a motivação para a realização desse trabalho é apresentar de forma
simples e objetiva os valores e as práticas da metodologia XP e dessa forma contribuir com
empresas que trabalham com desenvolvimento de software. Além disso, a sociedade
acadêmica e demais pesquisadores da área podem se beneficiar com os estudos sobre as
12
boas práticas da metodologia XP no desenvolvimento de software.
Esta monografia tem como objetivo verificar as implicações dos antigos modelos de
desenvolvimento de software e analisar de forma qualitativa os problemas que levam muitos
projetos a falhar. E como objetivo específico busca-se realizar um estudo bibliográfico
visando descrever e analisar de forma qualitativa, as implicações de um conjunto de boas
práticas que possam ser mais eficientes e fornecer melhores resultados nos projetos de
desenvolvimento de software.
Visando atingir os objetivos propostos, escolheu-se um estudo descritivo através de
uma abordagem qualitativa do tema. Na elaboração do trabalho utilizou-se como referência
bibliográfica livros, artigos científicos, trabalhos acadêmicos e artigos da internet.
Esta monografia está dividida em quatros partes. O capítulo 1 apresenta conceitos
básicos sobre Engenharia de Software que serviram de base para o desenvolvimento do
tema. No capítulo 2 é abordado o conteúdo principal e nele será introduzido o conceito de
desenvolvimento ágil para depois apresentar a Extreme Programming com seus valores e
boas práticas no desenvolvimento de software. No capítulo 3 é apresentado um estudo
comparativo entre a metodologia tradicional e a metodologia XP sobre a gestão de riscos
em desenvolvimento de software. Por fim, no capítulo 4 são apresentadas as conclusões
obtidas na elaboração dessa monografia.
13
CAPÍTULO 1. ENGENHARIA DE SOFTWARE
1.1 A crise do Software
O software tornou-se um elemento imprescindível na nossa vida, estando presente
tanto nas tarefas corriqueiras do dia-a-dia, como programar a TV, até as transações
bancárias que movimentam bilhões de dólares e aquecem a economia global (ASTELS et al,
2002). As inúmeras aplicações foram aumentando gradativamente ao longo dos anos e
segundo Pressman (2006), o software passou por diversas transformações, a começar pelo
programador, que antigamente trabalhava solitário e depois foi substituído por uma equipe
de especialistas em software, cada um se concentrando em uma pequena parte da
aplicação.
De acordo com Brooks (1975, apud PRESSMAN, 2006), a necessidade de softwares
mais complexos era indispensável para acompanhar as transformações ocorridas no mundo
nas décadas de 60 e 70. Infelizmente, a comunidade de software ainda não estava
preparada para essas mudanças, tanto que muitos projetos de software fracassaram
durante esse período. Os softwares eram mal projetados e por isso estouravam o tempo
planejado e consequentemente custavam mais, Sommerville no seu livro vem reafirmar:
[...] O software era entregue com atraso, não era confiável, custava várias
vezes mais do que previam as estimativas originais e, muitas vezes, exibia
características precárias de desempenho [...] (BROOKS, 1975, p.60 apud
SOMMERVILLE, 2007).
A comunidade de software necessitava de algo que a ajudasse a melhorar seus
processos e técnicas de desenvolvimento, e em 1968 surgiu o termo “Engenharia de
Software”, uma disciplina criada exclusivamente para estudar e aprimorar o
14
desenvolvimento de software (SOMMERVILLE, 2007). Nesse mesmo ano, de acordo com
Teles (2005), ocorreu na Alemanha a Conferência da OTAN (Organização do Tratado do
Atlântico Norte) sobre Engenharia de Software, organizada para discutir sobre a chamada
“Crise de Software”, a qual Sommerville (2007) atribuía à evolução do hardware de terceira
geração que tornava possível muitas aplicações de softwares até então inimagináveis.
Para vencer a “crise do software” a Engenharia de Software tem proposto a cada dia
novos métodos para controlar a complexidade dos softwares, começando pelas
metodologias de desenvolvimento linear, conhecidas inicialmente por modelo em cascata,
até os atuais processos ágeis de desenvolvimento. Entretanto, ainda hoje muitos projetos de
software têm problemas e isso levou alguns críticos (PRESSMAN, 1997) a sugerirem que a
Engenharia de Software está em um estado de aflição crônica.
A “aflição crônica” sugerida por Pressman pode ser comprovada através de um
estudo intitulado de Chaos Research (STANDISH, 2006), que é realizado desde 1994 pela
Standish Group International. O resultado é um relatório abrangente sobre o sucesso e o
fracasso de milhares de projetos na área da tecnologia da informação. De acordo com
Castro (2007), este estudo engloba uma grande quantidade de projetos e a maior parte
deles são baseados no desenvolvimento tradicional.
No relatório Chaos Research, os projetos são enquadrados em três categorias
distintas:
• Mal sucedido – O projeto é cancelado em algum momento do
desenvolvimento por uma ou mais razões;
• Bem sucedido – O projeto é concluído dentro do prazo previsto e do
orçamento estimado;
• Comprometido – O Projeto é concluído. Porém, é entregue com atraso, com
orçamento além do estimado, e em alguns casos, o software não possui
todas as funcionalidades especificadas.
15
Figura 1 - Resultado do relatório Chaos Research de 1994
Fonte: modificado de The Standish Group International Inc (2006).
Figura 2 - Resultado do relatório Chaos Research de 2004
Fonte: modificado de The Standish Group International Inc (2006).
Observando as Figuras 1 e 2, nota-se que em 10 anos os projetos bem sucedidos
tiveram uma melhora de quase 100%. Entretanto, esses resultados ainda são muito ruins,
pois os projetos mal sucedidos e comprometidos correspondem a mais de 70% do total. Isto
leva a deduzir que as técnicas e métodos desenvolvidos pela Engenharia de Software ainda
não são adequados para atender a evolução que o desenvolvimento de software necessita
16
para vencer a “crise do software”.
1.2 Qualidade de Software
Para Sommerville (2007), atingir um alto nível de qualidade deve ser atualmente o
maior objetivo das organizações, pois o mercado não mais admite que se entregue um
produto de baixa qualidade e aos poucos reparar os defeitos. Em relação ao fator qualidade,
o software se tornou igual a qualquer outro produto comercializado como automóveis,
televisores e computadores.
Segundo Geek (2008, apud NETO, 2008) a qualidade de software não é mais um
diferencial de mercado, é um pré-requisito para toda empresa que queira lançar e manter
seu produto no mercado, e para tanto, ela necessita que seus clientes percebam essa
qualidade em seus softwares. Para este autor, a qualidade é um item essencial a se
considerar em um software e existem boas razões para isto. A Tabela 1 mostra algumas
dessas razões.
Tabela 1 - Razões para qualidade de um Software
Razão Justificativa
Qualidade é competitividade
A única maneira de diferenciar o produto do competidor é pela qualidade do Software e do suporte que é fornecido juntamente.
Qualidade é essencial para a sobrevivência
Clientes estão pedindo por qualidade. Se a empresa não tiver habilidade de sobreviver em um mercado altamente competitivo, ela está em débito com o mercado.
Qualidade é custo/benefício
Um sistema de qualidade direciona para o aumento da produtividade e permanentemente reduz custos, habilitando o gerenciamento para reduzir a correção de defeitos, danos ênfase à prevenção.
Qualidade retém consumidores e aumenta lucros
Pouca qualidade normalmente custa muito mais caro do que contratar mais desenvolvedores e ainda continuar sem qualidade. A maioria dos consumidores não tolerará falta de qualidade e irão procurar outros desenvolvedores.
Fonte: Geek (2008, apud NETO, 2008)
17
A ISO (International Organization Standardization) e a IEC (International
Electrochnical Comission) se uniram para editar normas internacionais de qualidade de
software, e assim definiram: “A totalidade de características de um produto de software que
lhe confere a capacidade de satisfazer necessidades explícitas e implícitas”. Necessidades
explícitas são os requisitos definidos para atender os objetivos, funções e desempenho
esperado pelo software, já as necessidades implícitas são os requisitos que mesmo não
sendo declarados na documentação, são fundamentais devido à gravidade das
conseqüências, como por exemplo, a integridade dos dados (RODRIGUES et al, 2009).
Segundo Pressman (2006, p.351), na tentativa de identificar os atributos de
qualidade de um software, a norma ISO 9126 de 1991 identifica seis atributos-chave de
qualidade:
a) Funcionalidade – Capacidade do software de funcionar adequadamente e atender as necessidades especificadas;
b) Confiabilidade – Capacidade do software de funcionar por determinado período de tempo livre erros e falhas;
c) Usabilidade – Capacidade do software de ser compreendido e utilizado facilmente pelo usuário;
d) Eficiência – Capacidade do software de atingir seu melhor desempenho utilizando seus recursos da melhor forma;
e) Manutenibilidade – Capacidade do software de realizar modificações e reparos sem grandes dificuldades;
f) Portabilidade – Capacidade do software de ser transferido facilmente de um ambiente (plataforma) para outro.
Para Sommerville (2007), além dos atributos citados por Pressman, existem ainda
outros atributos importantes a se considerar em um software de qualidade. Eles são:
a) Segurança – Capacidade do software de impedir o acesso de pessoas ou programas não autorizados;
b) Robustez – Capacidade do software de manter o processamento, mesmo com ações inesperadas;
18
c) Facilidade de compreensão – Capacidade do software de ser explicativo e memorizado facilmente;
d) Facilidade de adaptação – Capacidade do software de se adaptar a novas necessidades do usuário quando necessário.
Evidentemente que a importância de cada um desses atributos depende muito do
projeto e do custo de cada atributo. Eles são essenciais para se obter um software de
qualidade do ponto de vista da Engenharia de Software, mas do ponto de vista do usuário,
um software de qualidade é fácil de usar, de simples manutenção e o mais importante,
funciona corretamente (RODRIGUES et al, 2009).
De acordo com Leite (2001), de nada adianta concentrar as atenções somente no
produto de software a ser construído. Tão importante como a qualidade do produto é a
qualidade do processo utilizado na fabricação desse produto. Portanto, para lidar com
qualidade de software é necessário que qualidade de produto e processos caminhem lado a
lado.
Segundo Garcia (2009), processos de software são um conjunto de atividades,
métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter
softwares e produtos relacionados. E as motivações que levam as empresas a buscar
processos de qualidade são: aumento da qualidade, diminuição do retrabalho, maior
produtividade, redução do tempo para atender o mercado, maior competitividade e maior
precisão nas estimativas. Mesmo com todas essas motivações a respeito de processos,
Astels et al (2002) chegaram à conclusão de que cerca de 60% dos projetos de
desenvolvimento são executados sem um processo definido, pois as equipes de
desenvolvimento ignoram muitas regras de processo devido a estrutura rígida que a maioria
dos processos impõe.
Depois de analisar os requisitos para se ter um software de qualidade e concluir que
a qualidade se estende até os processos de desenvolvimento, é importante buscar entender
melhor esses processos, bem como avaliar os fatores que caracterizam um processo de
software de qualidade.
19
1.3 Modelos tradicionais de desenvolvimento
Conforme apresentado anteriormente, qualidade de software está diretamente
relacionada com qualidade de processo, que pode ser definido grosseiramente como os
métodos utilizados pela equipe de desenvolvimento de software.
A seguir, serão abordados alguns dos processos tradicionais de desenvolvimento
criados pela Engenharia de Software a partir da década de 70.
1.3.1 Modelo em cascata
Segundo Pressman (2006), o modelo em cascata foi o primeiro paradigma de
desenvolvimento criado pela Engenharia de Software, que teve sua essência retirada de
outras áreas da Engenharia. Mas, conforme é descrito ao longo desse trabalho, a
construção de software não pode ser comparada a produção de produtos manufaturados,
pois o software é o resultado de um processo de criação e não de fabricação. Para
Pressman (2006) o modelo em cascata sugere uma abordagem linear e seqüencial de todas
as atividades envolvidas no desenvolvimento de software, e por se tratar de uma seqüência
de eventos, esse modelo também ficou conhecido como “ciclo de vida” do software.
Os estágios do modelo em cascata e a seqüência com que esses eventos são
executados são ilustrados na Figura 3 abaixo:
20
Figura 3 - Modelo em cascata Adaptado de: Pressman (2006); Pfleeger (2004)
• Definição dos requisitos – Segundo Pfleeger (2004), os requisitos são
características de algo que o sistema será capaz de realizar para atingir determinado
objetivo. Para isso, a equipe de desenvolvimento deve questionar o cliente sobre a
forma que o sistema deve ser para satisfazer as suas necessidades. Em seguida a
equipe deve registrar esses requisitos em um documento de tal maneira que clientes
e desenvolvedores cheguem a um acordo sobre como o sistema deve ser.
• Projeto de Software – Os requisitos são um conjunto de problemas que o sistema
deve resolver para o cliente e com base nesses requisitos, a equipe de
desenvolvimento deve, antes de codificar, projetar uma solução que satisfaça as
necessidades do cliente (PFLEEGER, 2004).
• Desenvolvimento – De acordo com Pressman (2006), a atividade de
desenvolvimento consiste em transformar, através de técnicas de programação, o
projeto de software em um produto executável e operacional.
• Testes de sistema – Ainda citando este autor, os testes são um processo de
execução de um programa que têm como objetivo revisar a codificação
implementada e encontrar erros na estrutura do software.
• Implantação – Implantação compreende a entrega do software para o cliente e a
utilização do usuário final. Nesse momento, o cliente tem a oportunidade avaliar se o
software atende às suas necessidades e em caso de não conformidades, a equipe
deve registrar as modificações necessárias para dar início à manutenção do software
(PRESSMAN, 2006).
Segundo Pfleeger (2004), todo o processo começa com as especificações dos
objetivos com o cliente, e nenhum outro estágio é iniciado antes do término do seu
antecessor, pois cada estágio envolve um ou mais documentos que devem ser aprovados e
assinados para que seja autorizado o início do próximo.
Para Pressman (2006), esse método de desenvolvimento apresenta vários
21
problemas. O principal é que em uma equipe de desenvolvimento, alguns membros
necessitam esperar o término do estágio anterior pra começar a trabalhar, e por mais que o
gerente tente administrar sua equipe para que isso não aconteça, é inevitável que algum dia
membros da equipe fiquem ociosos por terem que esperar que outros completem suas
tarefas.
Além disso, há outros problemas que segundo Pressman (2006) a modelagem em
cascata pode acarretar:
• “... projetos reais raramente seguem o fluxo seqüencial que o modelo
propõe...” (PRESSMAN, 2006, p.39).
O modelo em cascata não possui a flexibilidade que uma equipe de desenvolvedores
necessita, muitas vezes, no meio do desenvolvimento o cliente percebe algum item que
ficou faltando nos requisitos. Essas mudanças não são tratadas no modelo em cascata e na
maioria das vezes causa confusão à medida que a equipe prossegue com o projeto.
• “... em geral, é difícil para o cliente estabelecer todos os requisitos
explicitamente...” (PRESSMAN, 2006, p.39).
Raramente um cliente que contrata uma equipe para desenvolver um software sabe
exatamente o que quer de um software. O cliente sabe que precisa, mas não faz ideia de
como explicar detalhadamente a forma como deve ser esse software para atender suas
necessidades.
Essa incerteza do cliente se torna uma barreira para o modelo em cascata, uma vez
que modelo necessita que todas as informações e requisitos sejam definidos logo no início
do projeto.
• “... cliente precisa ter paciência...” (PRESSMAN, 2006, p.39).
Como nenhum estágio pode ser iniciado antes do seu antecessor, a
“produção visível” do software é demorada e o cliente precisa ter muita paciente até que a
22
equipe projete, desenvolva, implante e teste o software completamente.
1.3.2 Modelo incremental
Nos primeiros anos de desenvolvimento de software, alguns projetos demoravam
vários anos para serem entregues. Evidentemente que, atualmente, isso não é mais aceito
devido ao mercado concorrido e a economia super aquecida do mundo globalizado.
Segundo Pfleeger (2004), uma solução para reduzir o tempo de entrega do software foi
passar a projetar o mesmo em pequenas partes e entregar para o cliente ao término de
cada fase do projeto. Dessa forma, o usuário pode experimentar, mesmo que aos poucos,
os recursos e funções que o software terá ao final do desenvolvimento.
Na verdade, o modelo incremental combina os elementos do modelo em cascata de
forma iterativa. Cada iteração é uma seqüência linear que produz um subproduto de um
sistema. O primeiro incremento é freqüentemente chamado de núcleo de produto, que
possui os requisitos básicos do sistema para que o cliente possa avaliar e elaborar os
próximos incrementos que melhor satisfaçam as suas necessidades (PRESSMAN, 2006).
A seqüência do modelo incremental pode ser ilustrada como a figura abaixo:
Figura 4 - Modelo incremental Adaptado de: Pressman (2006); Pfleeger (2004)
23
1.3.3 Prototipagem
Para Pressman (2006), a Prototipagem é comumente utilizada como uma técnica
aplicada em outras metodologias de desenvolvimento e tem seu fundamento na construção
rápida de vários protótipos que são descartados à medida que os novos protótipos são
melhores que seus antecessores. Os primeiros protótipos concentram-se unicamente na
representação dos aspectos que estarão visíveis para o cliente. Dessa forma, é possível
implantar rapidamente um protótipo que será avaliado, e então o feedback produzido é
usado para refinar os requisitos do software e construir um novo protótipo com mais
recursos que atendam a necessidade do cliente.
Segundo Pfleeger (2004) um protótipo é construído com a finalidade de ajudar a
entender melhor as necessidades do cliente e explorar a viabilidade das possíveis soluções.
Neste protótipo não há nenhuma pretensão de utilizá-lo como parte real do sistema a ser
entregue, por isso o protótipo é descartado e inicia-se a construção de um novo. No entanto,
Pressman (2006) afirma que o emprego de protótipos pode ser problemático, pois o cliente
vê uma versão de seu software em funcionamento, mas ignora o fato de que foi construído
na pressa de fazê-lo rodar e que, conseqüentemente, ninguém considerou a qualidade do
código fonte. Em alguns casos, o cliente não aceita o fato de descartarem o protótipo, que
aparentemente funciona, para construírem um novo com altos níveis de qualidade. Então, o
cliente exige “alguns consertos” para transformar o protótipo no produto final e na maioria
das vezes a gerência de desenvolvimento do software, mesmo discordando, acaba por fazer
a vontade do cliente.
24
CAPÍTULO 2. EXTREME PROGRAMMING
2.1 Desenvolvimento ágil
As metodologias tradicionais de desenvolvimento foram criadas em um cenário muito
diferente do atual. No cenário anterior, as limitações tecnológicas e a falta de ferramentas
para a criação de softwares, tornavam o custo muito alto para o desenvolvimento e
manutenção destes. Portanto, era essencial planejar e documentar todo o software para
então implementá-lo (VIANA & DESCHAMPS, 2007).
Segundo Pressman (2006), essa prática de projetar todo o sistema para só então
implementar é obsoleta para o cenário atual. É praticamente impossível prever com
antecedência todos os detalhes de um sistema, devido às condições mutáveis de mercado e
a freqüente evolução das necessidades do usuário final.
Um dos problemas no desenvolvimento de software é a enorme quantidade de
detalhes que precisam ser considerados. Segundo Beck (2000, apud CASTRO, 2007), o
cliente tem o conhecimento de apenas alguns aspectos do software que ele deseja e só
passará a ter o restante depois de utilizar o sistema. Portanto, é difícil ter uma versão
completa do documento de requisitos1 antes de começar a programar, pois o cliente não
especifica todos os detalhes no início do projeto pelo simples fato dele mesmo não os
conhecer. Além disso, mesmo que ele soubesse de todos os detalhes, especificá-los em
documento seria muito difícil, devido à grande quantidade de elementos que precisariam ser
descritos.
Para suprir essas e outras necessidades da Engenharia de Software, Kent Beck e
outros dezesseis notáveis consultores se reuniram em 2001 e criaram um novo conceito de
processo de software: o Desenvolvimento Ágil.
1 Documento de requisitos é um consenso entre cliente e o desenvolvedor sobre uma listagem completa de tudo o que o cliente espera que o sistema proposto faça (PFLEEGER, 2004).
25
O Desenvolvimento Ágil é uma nova metodologia criada por profissionais renomados
na engenharia de software, que só conseguiram maximizar os resultados pensando e
trabalhando de forma muito diferente das descritas nos livros. Embora cada um tivesse suas
próprias teorias sobre desenvolvimento de software, todos concordavam que as teorias
tinham algo em comum. Foi dessa forma, que eles definiram um pequeno conjunto de
princípios e criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente
chamado apenas de Manifesto Ágil (CASTRO, 2007).
Os princípios do Manifesto Ágil são:
• Indivíduos e interações em vez de processos e ferramentas;
• Software funcionando em vez de documentação abrangente;
• Colaboração do cliente em vez de negociação de contratos;
• Resposta a modificações em vez de seguir um plano.
De acordo com Viana & Deschamps (2007), o Manifesto Ágil não descarta os
processos, ferramentas, documentações, negociações e planejamentos, mas procura dar a
esses itens um valor secundário diante dos indivíduos e interações, do bom funcionamento
do software, da colaboração do cliente e das respostas velozes às modificações.
Pressman (2006) afirma que o Desenvolvimento Ágil requer a utilização de pequenos
e constantes incrementos de software, e para isso, necessita que o feedback do cliente seja
o mais rápido possível.
[...] Um catalisador efetivo para o feedback do cliente é um protótipo
operacional ou uma porção do sistema operacional. Assim, uma estratégia
de desenvolvimento incremental deve ser instituída. [...] Essa abordagem
iterativa habilita o cliente a avaliar o incremento de software regularmente,
fornecer o feedback necessário à equipe de software e influenciar as
adaptações do processo feitas para acomodar o feedback [...]
(PRESSMAN, 2006, p. 61).
26
Com efeito, é possível notar nas afirmações de Pressman que a metodologia ágil
mescla alguns processos das metodologias de Incremento e Prototipagem oriundos dos
modelos tradicionais.
Segundo Fowler (2007, apud BORBOREMA, 2007), as duas principais diferenças
entre as metodologias ágeis e as tradicionais são:
a) Adaptativas, ao invés de previsivas – as metodologias tradicionais são
resistentes a mudanças devido à excedente documentação feita com
antecedência. Em contrapartida, as metodologias ágeis conseguem ser
mais flexíveis, pois ajustam seus requisitos durante o desenvolvimento do
software.
b) Orientadas às pessoas, não aos processos – as metodologia ágeis não
possuem processos rígidos que impõem o que as equipes devem ou não
fazer. Muito pelo contrário, a equipe é estimulada a se envolver
diretamente com o cliente e toma as decisões necessárias para melhor
ajustar a equipe.
Segundo Teles (2006), algumas metodologias que seguem os princípios do
Manifesto Ágil são: Scrum, Dynamic Systems Development Method (DSDM), Crystal
Methods, Feature-Driven Development (FDD), Lean Development (LD), Extreme
Programming e Adaptative Software Development. Dentre essas metodologias, esta
monografia aborda como assunto principal a Extreme Programming, mais conhecida por XP,
por ser uma das metodologias mais conhecidas atualmente tanto no Brasil quanto no
exterior.
27
2.2 Breve histórico da XP
Extreme Programming, ou simplesmente XP é uma das mais conhecidas
metodologia de desenvolvimento de software que segue os princípios do Manifesto Ágil.
Embora seu marco de criação seja o ano de 1996, a junção de princípios e boas práticas de
programação são frutos de um processo de evolução de pelo menos uma década em que
Kent Beck e Ward Cunningham trabalharam na Tektronixs, Inc. como consultores de
problemas em SmallTalk (CASTRO, 2007).
Em 1996, Kent Beck foi chamado na empresa Chrysler para analisar o desempenho
de projeto do C3 (Chrysler Comprehensive Compensation System - Sistema de
Compensação Abrangente da Chrysler). O sistema era nada menos que o controle da folha
de pagamento de aproximadamente 86 mil funcionários e o objetivo do projeto era unificar
os quatro sistemas de software legado2 diferentes que estavam sendo usados há vinte anos.
Uma tarefa um tanto difícil, mas de total importância para a Chrysler que aos poucos viu o
projeto se tornar um verdadeiro caos. Havia problema em todos os processos, desde
contratos irregulares a profissionais estressados e desconfiados. Foram três dias até Beck
analisar todo o projeto para apresentar as seguintes opções para o CIO (Chief Information
Officer) da Chrysler: 1 – deixar da forma que estava; 2 – demitir todos os funcionários e
cancelar o projeto e; 3 – conceder uma semana de folga e começar o projeto do zero. A
Chrysler optou pela alternativa 3 e contratou Beck para ser responsável pelo projeto
(TELES, 2006).
Depois de entrevistar várias pessoas e orientá-las no que deveriam trabalhar, Beck
tinha esquematizado e nomeado as práticas básicas do XP. Os trabalhos começaram em
março de 1996 e terminaram em maio de 1997, e mesmo com atraso de 2 meses por causa
de mudanças de última hora nas funcionalidades do sistema, o lançamento foi um enorme
sucesso (TELES, 2006).
2 Sistemas desenvolvidos há décadas atrás e que tem sido continuamente modificado para satisfazer a mudanças do negócio e nas plataformas de computação (PRESSMAN, 2006).
28
A partir deste projeto na Chrysler liderado por Kent Beck, inúmeras equipes de
desenvolvimento ao redor do mundo vêm adotando XP com sucesso, especialmente nos
Estados Unidos e Europa. Aqui no Brasil, os valores e práticas veem sendo adotados desde
1998, mas ainda há poucas equipes que conduzem seus projetos utilizando a XP de forma
completa (CASTRO, 2007).
De acordo com Teles (2006), não é correto afirmar que este projeto foi o “berço” do
XP, afinal seus princípios e práticas foram sendo evoluídas pelo menos durante uma
década. Mas com certeza, essa foi a oportunidade que Beck teve para aplicar de forma
coesa todas as práticas do XP e, além disso, foi durante este projeto que as práticas foram
batizadas com os nomes atuais.
2.3 Valores da XP
O XP tem como base quatro valores fundamentais que sustentam as boas práticas
de desenvolvimento de software: comunicação, feedback, simplicidade e coragem. De
acordo com Beck (2005, apud CASTRO, 2007) esses valores são essenciais para guiar o
desenvolvimento de software, mas cada equipe XP pode definir outros valores que
acreditem ser relevantes dentro da sua realidade. O importante é que a equipe tenha
entendido muito bem esses quatro primeiros valores, pois eles são fundamentais para
compreender a razão e os motivos de cada boa prática de desenvolvimento.
2.3.1 Comunicação
Tradicionalmente na indústria do software, as equipes de desenvolvimento gastam
um valioso esforço na tentativa de trocar informações por meio de extensos documentos
escritos. Devido à ineficiência desse meio, nem sempre é possível reproduzir com exatidão
uma informação e dessa forma elas são freqüentemente interpretadas de forma incorreta ou
incompleta (TELES, 2006).
29
Geralmente, projetos de software são produzidos por uma equipe de
desenvolvedores, sendo assim, cada componente da equipe precisa trocar informações
entre si e com o cliente sobre cada detalhe do projeto. Segundo Beck (2000, apud
BORBOREMA, 2007), os problemas mais comuns ocorrem por erro de comunicação entre
as pessoas, algumas vezes o cliente não conversou sobre algo importante e, outras vezes,
o desenvolvedor não soube fazer as perguntas corretas para o cliente. Justamente por isso
que a comunicação é tida como um dos elementos mais importantes no desenvolvimento de
software.
Soares (2004) afirma que a melhor forma de comunicação em XP é a conversa face-
a-face, pois ela permite que o interlocutor leve em conta o conteúdo emocional da fala, dos
gestos e da expressão facial para interpretar a informação transmitida. Além disso, em caso
de dúvidas, o interlocutor pode saná-las instantaneamente.
A XP procura assegurar que a comunicação seja a mais eficiente possível, de modo
a diminuir as falhas na comunicação e evitar re-trabalhos desnecessários. Por isso, a
comunicação face-a-face é fortemente recomendada, por ser uma forma de interação direta
entre as pessoas, evitando-se ao máximo o uso de telefones, e-mail e outros meios de
comunicação (TELES, 2006).
2.3.2 Feedback
Segundo o dicionário Sensagent (2009), feedback é:
“A mechanism of communication within a system in that the input signal
generates an output response which returns to influence the continued
activity or productivity of that system.” 3
Trazendo este conceito para a realidade de desenvolvimento de software, feedback é
3 Tradução livre: “Um mecanismo de comunicação dentro de um sistema em que o sinal de entrada gera uma saída que retorna resposta continua a influenciar a atividade ou a produtividade do sistema”.
30
o processo de troca de informações que ocorre entre cliente e a equipe de desenvolvimento
durante a produção de um software.
Para Teles (2006) um feedback constante é a base de todos os processos ágeis de
desenvolvimento, e é a filosofia fundamental da XP, pois é ele que permite uma maior
produtividade, uma vez que os trabalhos da equipe de desenvolvimento são influenciados e
direcionados de acordo com a constante resposta do cliente sobre determinada atividade.
Ainda citando este autor, o feedback não é exclusividade do XP ou das metodologias ágeis,
ela também está presente nos processos tradicionais. O diferencial está nos tempos de
execução, pois nos processos tradicionais há uma defasagem muito grande no tempo da
troca de informação entre cliente e desenvolvedores, isto é ruim tanto para o cliente como
para a equipe que precisa encontrar rapidamente a solução que atenda as necessidades de
ambas as partes.
O contato incessante entre o cliente e a equipe de desenvolvimento é o que se pode
chamar de feedback constante. Dessa forma, o cliente pode freqüentemente ter uma parte
do software funcional para avaliar e com isso, pode sugerir novas características ao mesmo
tempo em que pode identificar eventuais não conformidades com os requisitos. E assim, os
desenvolvedores podem implementar rapidamente novas características e corrigir eventuais
erros já nas próximas versões a serem entregues ao cliente (SOARES, 2004).
Da mesma forma que os desenvolvedores se beneficiam com o constante feedback
do cliente, o contrário também acontece quando os desenvolvedores fornecem ao cliente o
seu feedback. Segundo Teles (2006) isto acontece quando eles apresentam estimativas,
riscos técnicos, alternativas de design, entre outros. A partir dessas informações e da
manipulação constante de um protótipo funcional, o cliente aprende mais sobre aquilo que
seria adequado para se produzir no software. Para este autor, perceber que o cliente
aprende na medida em que utiliza o software e se envolve em discussões sobre o mesmo, é
fundamental para compreender os desafios que existe no desenvolvimento de software.
31
2.3.3 Simplicidade
Simplicidade em XP refere-se a desenvolver apenas o suficiente para atender as
necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial. Mesmo
que tal funcionalidade esteja ligada com a evolução do produto, ela deve ser descartada até
que se tenha absoluta certeza da sua necessidade. Assume-se assim a seguinte estratégia:
desenvolver algo simples hoje e fazer modificações futuramente, ao invés de desenvolver
algo complexo hoje e correr o risco de não ser utilizado no futuro (SOARES, 2004).
Segundo Teles (2006), ao codificar uma funcionalidade pensando em problemas
futuros, o desenvolvedor recorre a um erro muito freqüente: o trabalho especulativo.
Trabalho este em que o desenvolvedor para “ganhar tempo” assume algumas premissas
das quais não tem absoluta certeza e implementa uma funcionalidade que possa ser
utilizada no futuro, mas na maioria das vezes ele erra ao assumir essas premissas e dessa
forma é preciso refazer todo o trabalho. Teles ainda afirma sobre os riscos de assumir o
trabalho especulativo, pois quando o desenvolvedor implementa uma funcionalidade além
do necessário, ele investe tempo e dinheiro em algo que pode nunca ser utilizado.
Conclui-se então que o principal objetivo da simplicidade na XP é evitar o retrabalho
resultante da precipitação em especular requisitos futuros.
2.3.4 Coragem
A XP é uma metodologia de software que se baseia em diversas premissas que
contrariam os processos tradicionais de desenvolvimento, justamente por isso, é preciso que
a equipe tenha convicção da sua eficiência e tenham determinação em adotar as boas
práticas. A coragem é acima de tudo uma forma de pensamento diferenciado que deve ser
adotado por todos os membros da equipe. Isto significa que as mudanças que ocorrem no
projeto não devem ser encaradas negativamente apenas como problemas a serem
resolvidos, mas sim como oportunidades a serem exploradas para a melhoria como um todo
32
da equipe e do projeto.
De acordo com Soares (2004) é preciso coragem para implantar comunicação entre
desenvolvedores e clientes, pois não são todas as pessoas que possuem facilidade de
comunicação e conseguem manter um bom relacionamento. É necessário também coragem
para aplicar refactoring em um código que está funcionando corretamente somente para
torná-lo mais simples.
Segundo Teles (2006), XP não tem uma fórmula mágica para eliminar todos os
riscos presentes no desenvolvimento de software, eles existem como em qualquer outra
forma de desenvolvimento, o que diferencia XP das outras metodologias é a forma de lidar
com estes riscos. Em XP, por exemplo, é natural quebrar o que estava funcionando
simplesmente para aplicar uma prática recomendada. Os riscos de aplicar tais técnicas são
conhecidos, mas a confiança de que elas serão benéficas para o projeto encorajam a equipe
a sempre aplicá-las quando forem necessárias.
Os valores apresentados até aqui são considerados os “alicerces” da XP, pois eles
que oferecem sustentação às boas práticas adotadas pelas equipes de desenvolvimento.
Segue abaixo a Figura 5 contendo as principais boas práticas da XP:
Figura 5 – Boas Práticas da XP Adaptado de: http://xprogramming.com
33
2.4 Boas Práticas da XP
As boas práticas da XP são um conjunto de atividades que as equipes XP utilizam
enquanto produzem softwares. Antes de qualquer coisa, é necessário ter confiança nestas
boas práticas e consciência de que elas devem ser aplicadas em conjunto. Quando
aplicadas isoladamente, elas não trazem os mesmos resultados por que os pontos fracos de
cada prática são protegidos pelos pontos fortes das outras práticas (BORBOREMA, 2007).
2.4.1 Cliente presente
Em projetos XP é essencial que o cliente participe ativamente do desenvolvimento.
Essa talvez seja uma prática muito extrema, mas a XP acredita que é somente a presença
constante do cliente que viabiliza a simplicidade dos processos e a clara comunicação com
os desenvolvedores. Tendo o cliente sempre presente, quaisquer dúvidas dos
desenvolvedores são sanadas rapidamente, mas para isso, o cliente deve possuir
capacidade para responder perguntas sobre o negócio e autoridade suficiente para tomar
decisões relativas a prioridades no projeto (ASTELS et al , 2002; TELES, 2006).
2.4.2 Releases e iterações
Release é um conjunto de funcionalidades que representa uma pequena versão do
sistema com recursos completos e relevantes para o cliente. Dessa forma, a versão é
colocada em produção o mais rápido possível, para que o cliente possa usufruir do
investimento no software ao mesmo tempo em que avalia e retorna um feedback para os
desenvolvedores sobre o release (TELES, 2006).
Além de fragmentar todo o projeto em releases, cada release é fragmentado em
pequenas partes chamadas iterações. Elas são utilizadas para refinar cada vez mais os
requisitos do release, para que ao término dela o cliente possa receber um produto que
atenda o máximo de suas necessidades e expectativas daquele momento. O tempo de cada
34
release e iteração depende da complexidade do projeto, mas em geral, releases costumam
durar em torno de oito semanas, enquanto as iterações duram em torno de duas semanas
(BORBOREMA, 2007).
Esta prática, segundo Astels et al (2002), deve ser utilizada para que alguns usuários
possam utilizar o software e avaliar, pois dessa forma vários tipos de defeitos podem ser
detectados rapidamente, possibilitando à equipe de desenvolvimento saber se está no
caminho certo ou não.
2.4.3 Jogo do Planejamento
Segundo Astels et al (2002), é fato que em desenvolvimento de softwares, seja ele
de que tamanho for, é preciso que haja um planejamento de projeto, mas isso não significa
elaborar um plano minucioso e detalhado que demore semanas ou até meses para ser
finalizado. Os planejamentos na maioria das vezes não são precisos e mudam
consideravelmente durante o andamento do projeto, quanto mais longo for o prazo de
planejamento, maior a probabilidade da imprecisão.
No início de cada iteração a equipe de desenvolvimento estimula o cliente a escrever
as funcionalidades que deseja no sistema em pequenos cartões chamados user stories.
Uma user story é a menor quantidade de informação que o cliente pode definir para uma
determinada funcionalidade do projeto e de acordo com a complexidade da user story, a
equipe de desenvolvimento estima o tempo e o custo que aquela funcionalidade irá custar
para o cliente. Ciente do tempo e custo, o cliente deve decidir a ordem que cada user story
deve ser desenvolvida, ou seja, ele tem a oportunidade de priorizar as funcionalidades
sabendo exatamente o tempo e quanto irá lhe custar. Esta prática realizada no início de
cada iteração é conhecida como Jogo de Planejamento e assegura que a equipe esteja
sempre trabalhando no que é mais importante e gere mais valor para o cliente (ASTELS et
al, 2002; TELES, 2006).
35
2.4.4 Metáfora
Segundo Teles (2006) as metáforas tem o poder de transmitir ideias complexas de
forma simples e clara. Por isso, a XP as utilizam para criar uma visão comum do projeto
entre cliente e desenvolvedores. Beck (2000, apud BORBOREMA, 2007) afirma também
que as metáforas devem ser estabelecidas de acordo com o vocabulário que o cliente está
habituado no dia a dia, pois assim a compreensão fica mais fácil e a comunicação é
beneficiada.
2.4.5 Programação em par
Para Borborema (2007), na programação em par dois desenvolvedores escolhem
uma user story e sentam-se em um único computador para codificar uma determinada
funcionalidade. O desenvolvedor com menor experiência tem como responsabilidade
assumir o controle do teclado e conduzir ativamente a programação do código fonte,
enquanto o outro desenvolvedor com maior experiência inspeciona o código a procura de
erros e defeitos, além de questionar decisões e pensar estrategicamente em soluções mais
simples para o código.
Semelhante a outras boas práticas, a programação em par é um investimento que a
equipe faz para sempre buscar as soluções mais eficientes e eficazes. Teles (2006) afirma
que na programação em par os desenvolvedores estão constantemente discutindo sobre as
melhores alternativas, dessa forma um ajuda o outro quando uma solução está muito
complexa. Além disso, a programação em par trás outros benefícios para o projeto, como
por exemplo, a revisão constante do código que ajuda na detecção de erros rapidamente, e
a disseminação do conhecimento entre os pares, que ajuda no nivelamento técnico de toda
a equipe.
Segundo Astels et al (2002), programar uma funcionalidade em par é tão produtivo
quanto programar a mesma funcionalidade sozinho, ou seja, a programação em par não
afeta a velocidade do desenvolvimento, mas afeta diretamente a qualidade do código, uma
36
vez que o código gerado por um par tende a ser mais eficiente e a quantidade de erros é
bem menor. Além das vantagens já citadas com a programação em par, essa prática
também proporciona a “pressão do parceiro”, que é uma forma saudável de manter um
senso de disciplina durante a jornada de trabalho.
2.4.6 Refactoring
Refactoring é o processo de reorganizar o código fonte de um software para
melhorar sua qualidade interna, facilitar a leitura e diminuir o tempo gasto com manutenção,
sem contudo prejudicar o desempenho e alterar seu comportamento externo. Aplicado em
sistemas orientados a objetos, a técnica é fundamental para tornar o código mais legível e
encontrar facilmente erros em algoritmos mal escritos (NETO, 2007).
Segundo Teles (2006), um projeto em XP não existe sem a prática de refactoring,
pois a agilidade necessária para alterar e incluir novas funcionalidades constantemente em
um sistema só é possível com um código de alta qualidade que seja organizado e de fácil
compreensão. Para que isso aconteça, a XP determina que qualquer um da equipe faça o
refactoring em qualquer parte do código que esteja pouco legível.
Ainda citando Teles, ele admite que a prática de refactoring traz um grande risco de
fazer com que um código que estava funcionando corretamente pare de funcionar. No
entanto, é possível reduzir esse risco conhecendo bem as técnicas de refactoring e testando
constantemente o código. Os testes garantem uma segurança para aplicação de refactoring,
pois após cada alteração, eles informam se o código continua produzindo os mesmos
resultados.
2.4.7 Testes de unidade
Uma das preocupações da XP é a qualidade do código produzido e nada garante tão
bem que um código esteja funcionando corretamente do que um teste. Por isso, os
programadores da XP escrevem testes automatizados antes mesmos de codificar uma
37
funcionalidade. Dessa forma eles aprofundam o conhecimento da funcionalidade em
questão, além de poder sempre contar com testes que validem o sistema em qualquer
momento do projeto (CASTRO, 2007; TELES, 2006).
Segundo Astels et al (2002), existem dois motivos para fazer testes:
a) Eles descrevem a tarefa que o código a ser testado deve executar e
com base nisso o desenvolvedor consegue se concentrar apenas no
essencial para passar no teste, evitando assim que ele perda de tempo em
algo que não será utilizado.
b) Eles são uma garantia de que o sistema está funcionando da forma
como deveria, dessa forma o desenvolver avança mais rapidamente no
projeto, pois tem a confiança de que o código não foi quebrado durante
uma alteração qualquer.
Ainda citando este autor, ele aponta três momentos durante o desenvolvimento que
se devem aplicar os testes:
a) Antes o refactoring – para ter certeza que o código está funcionado
corretamente antes de qualquer alteração.
b) Após o refactoring – para ter certeza que as modificações não
alteraram o comportamento externo do sistema.
c) Após a integração – para ter certeza que não houve conflitos entre os
códigos integrados.
As metodologias tradicionais encaram os testes como um gasto desnecessário no
projeto, mas em XP eles são vistos como uma forma de investimento que garante
produtividade no médio e longo prazo. Certamente que as equipe consomem um tempo
considerável na criação dos testes, entretanto eles ajudam a reduzir a ocorrência de erros e
defeitos no sistema e quando ocorre, o tempo gasto na busca por esses erros é
infinitamente menor, graças aos testes automatizados (TELES, 2006).
38
2.4.8 Código coletivo
Uma equipe de XP trabalha com a prática de propriedade coletiva do código, ou seja,
cada membro da equipe pode trabalhar em qualquer parte do sistema a qualquer momento.
Caso um desenvolvedor encontre alguma coisa que possa ser melhorada, ele não precisa
solicitar que outra pessoa o faça por não seu o “dono” daquele código. Essa prática permite
que o sistema evolua mantendo o código o mais simples possível, pois sempre que um
membro encontra algo confuso, ele tem a liberdade de aplicar o refactoring (Astels et al,
2002).
Equipes que trabalham com propriedade de código tendem a criar pessoas dentro da
equipe com conhecimento especializado, e isso se torna um transtorno quando ocorre um
imprevisto e tais pessoas são afastadas do projeto por uma razão, como por exemplo, em
casos de doenças ou demissões. Para evitar este tipo de problema a XP utiliza-se do código
coletivo, que além de evitar “ilhas de conhecimento”, cria mais um mecanismo de revisão
constante, uma vez que um código escrito hoje por uma dupla acaba sendo manipulado por
outra no dia seguinte (TELES, 2006).
2.4.9 Código padronizado
Como todos os desenvolvedores têm acesso a todo o código, é necessário que se
estabeleça um padrão de codificação e que todos concordem voluntariamente em segui-lo,
assim o sistema será homogêneo e permitirá que qualquer um compreenda facilmente e não
tenha dificuldades para manipulá-lo caso seja necessário (TELES, 2006).
Segundo Beck (2000, apud CASTRO, 2007) a equipe deve adotar um padrão que
exigia a menor quantidade possível de trabalho, ou seja, quanto menos código duplicado
tiver, melhor. Além disso, a padronização do código deve ser encarada como um meio de
comunicação entre a equipe. Por isso, ela deve ser clara, objetiva e entendida por todos da
equipe.
39
2.4.10 Integração continua
Segundo Soares (2006), integração continua é a prática de construir o software
várias vezes por dia, o que possibilita uma constante sincronia entre os desenvolvedores.
Esta prática é aconselhada para evitar surpresas e assegurar que o sistema esteja sempre
funcionando de forma harmoniosa a cada nova integração. Não é raro uma integração
causar erros no sistema. Por isso, a cada integração, os pares devem executar todos os
testes para verificar a integridade do sistema. Dessa forma é possível descobrir os defeitos
rapidamente e corrigi-los antes que se tornem problemas maiores no futuro.
2.4.11 Reunião diária
De acordo com Teles (2006), as equipes XP sempre começam um dia de trabalho
com uma reunião de no máximo 10 minutos. Nesse momento, cada desenvolvedor têm
oportunidade de comentar rapidamente sobre o que realizou no dia anterior, e assim todos
tem conhecimento sobre o andamento geral do projeto. Ainda nessa reunião, a equipe
aproveita para priorizar as atividades que serão realizadas ao longo do dia.
2.4.12 Ritmo sustentável
Segundo Borborema (2007), essa prática consiste em trabalhar respeitando os
limites físicos e demonstrando respeito pela individualidade de cada membro da equipe.
Dessa forma, para que uma equipe seja criativa e produza software com qualidade, ela
precisa estar saudável do ponto de vista físico e mental. Para isso, a XP recomenda que a
carga horária de trabalho não ultrapasse 8 horas diárias e 40 horas semanais.
Muitos gerentes de projetos utilizam a prática de estender a jornada de trabalho para
compensar atrasos no cronograma do projeto, mas estudos comprovam que essa solução
tem resultados apenas nos primeiros dias. Trabalhar vários dias além do horário, além de
causar um cansaço físico e mental, causa um sentimento desmotivador e
conseqüentemente o desempenho da equipe será bem menor (TELES, 2006).
40
CAPÍTULO 3. ESTUDO DE CASO
3.1 Comparativos entre a metodologia XP e o modelo em cascata
O estudo de caso a seguir tem como desafio demonstrar as principais diferenças
acerca da aplicação das metodologias no que tange às questões sobre eficiência e eficácia
no desenvolvimento. Sendo o enfoque desse estudo a flexibilidade da metodologia para com
os processos e o suporte que ela proporciona para as principais questões na gestão de
riscos em projetos de software.
3.1.1 Comparativo sobre processos
Para Pompilho (2002), a metodologia de desenvolvimento tradicional é composta de
uma regra rígida onde as fases do projeto devem ter uma seqüência, e uma fase dá início
ao término da outra, portanto, o teste que no desenvolvimento XP ocorre a todo momento,
no modelo em cascata só irá ocorrer no final. Percebe-se então, na tabela 2 como XP é
flexível deixando o engenheiro de software verificar quais etapas serão importantes e quais
artefatos serão utilizados.
Tabela 2 - Comparativo entre os processos da XP e do modelo em cascata
Ciclo de vida do um Software
Desenvolvimento ágil XP (Extreme Programming)
Desenvolvimento Tradicional Modelo em cascata
Definição dos requisitos
Obrigatório. Os requisitos são atualizados ao longo do desenvolvimento.
Obrigatório. É gerada uma versão que servirá de base para todos os itens a seguir.
Projeto de software Opcional. Surge informalmente durante o desenvolvimento do software.
Obrigatório. E só se dá início ao término da definição dos requisitos.
Desenvolvimento Implementa os incrementos (user stories) levantados junto ao cliente.
Implementa sequencialmente cada funcionalidade que o projetista especificou no projeto.
41
Teste de sistema É feito um plano de teste antes da implementação que vão sendo executados freqüentemente.
O teste é feito apenas pela equipe de desenvolvimento no final do projeto.
Implantação Parte do software vai sendo implantada até concluir todos os requisitos.
O software só é entregue ao usuário quando estiver totalmente pronto.
Adaptado de: Pompilho (2002)
3.1.2 Comparativo sobre a gestão de riscos
Segundo Sommerville (2007), desenvolver software é uma atividade arriscada e todo
gerente de projeto deve obrigatoriamente prever os riscos que podem afetar o
desenvolvimento e a qualidade do software. Os tipos de riscos dependem da complexidade
e do ambiente de desenvolvimento. No entanto, alguns riscos são considerados universais
pela comunidade de Engenharia de Software e alguns deles são descritos na Tabela 3.
Tabela 3 - Riscos comuns em projetos de Software
RISCO DESCRIÇÃO
Alteração nos requisitos Mudanças nos requisitos não previstas
Atrasos na especificação Especificações essenciais não disponíveis nos prazos
Documentação completa Clientes que exigem documentação abrangente
Escopo fechado Contrato que define todas as atividades do projeto
Doenças e demissões Perda de pessoas-chave em períodos cruciais
Treinamento Perda de mão-de-obra para treinar novas pessoas
Mudanças gerenciais Gerenciamento organizacional com prioridades diferentes
Sistemas de premiação Incentivo a desenvolvedores que apresentarem melhores resultados
Tamanho subestimado Tamanho do sistema bem maior que o estimado
Adaptado de: Sommerville (2007); Teles (2006)
42
Baseando-se no que foi estudado até o momento sobre Desenvolvimento Tradicional
e Desenvolvimento Ágil, foi possível empiricamente montar a tabela abaixo, dando níveis de
Alto e Baixo nas questões levantadas por Sommerville (2007) e Teles (2006).
Tabela 4 - Comparativo entre o grau de risco nas metodologias tradicionais e na XP
RISCO Desenvolvimento ágil (XP)
Desenvolvimento tradicional
Alteração nos requisitos Baixo Alto
Atrasos na especificação Baixo Alto
Documentação completa Alto Baixo
Escopo fechado Alto Baixo
Doenças e demissões Baixo Alto
Treinamento Baixo Alto
Mudanças gerenciais Baixo Alto
Sistemas de premiação Alto Baixo
Tamanho subestimado Baixo Alto
Adaptado de: Sommerville (2007); Teles (2006)
Na análise feita no comparativo sobre gestão de riscos, nota-se que:
a) As boas práticas de: Cliente presente, Releases e iterações e Jogo de
planejamento fazem com que a metodologia XP seja mais aconselhável para
projetos de espoco variável em que os requisitos ainda não estão bem
definidos e que podem sofrer alterações durante o projeto, seja por mudanças
gerenciais na equipe do cliente ou mesmo por ele não conhecer ao certo a
dimensão exata do sistema. Além disso, a XP consegue reduzir problemas de
treinamento e perda de mão-de-obra devido às boas práticas de Código
43
coletivo e Programação em par, que proporciona a todos da equipe (inclusive
aos novatos), treinamento constante e conhecimento satisfatório sobre todas
as partes do sistema.
b) Em contrapartida, a XP não é aconselhável em projetos que o cliente exija
uma documentação completa do sistema logo no início do projeto, uma vez
que equipes XP priorizam colocar o sistema em funcionamento ao invés da
documentação abrangente. Outro risco para projetos que utilizam a XP é a
premiação (muitas vezes financeira) para membros da equipe de
desenvolvimento que apresentarem melhor desempenho. Essa prática trás
um sentimento de competição dentro da equipe e os levam a
comportamentos individualistas e, sem duvida a XP é um ambiente de
cooperação, e não há espaço para esse tipo de competição (TELES, 2006).
44
CAPÍTULO 4. CONCLUSÕES
Extreme Programming é uma metodologia que busca reduzir ou mesmo sanar
problemas de atrasos no cronograma, retrabalhos no projeto e desperdícios de tempo e
dinheiro nos processos de desenvolvimento. Para isso, a XP utiliza-se de uma série de
práticas que auxiliam as equipes de desenvolvimento a trabalhar de maneira mais eficiente.
Um dos fatores que tornam a XP eficiente é a integração constante entre cliente e
desenvolvedores, isso favorece para que as necessidades do cliente sejam rapidamente
compreendidas e em seguida implementadas. A programação em par também é um
diferencial da metodologia XP no requisito treinamento, enquanto que no desenvolvimento
tradicional a falta de treinamento influencia diretamente no prazo de um projeto, na
metodologia XP um dos integrantes da dupla vai sendo treinado ao longo do
desenvolvimento de maneira transparente para o projeto.
Por se tratar de uma metodologia relativamente nova que contraria muitos
paradigmas do desenvolvimento tradicional, ainda há um preconceito com a metodologia e a
dúvida sobre a eficácia da sua utilização. Mas, percebe ao longo deste trabalho que existe
grande chance nos próximos anos da metodologia XP vir a ser bastante utilizada. E que,
como em qualquer outra metodologia, ela possui pontos fracos, mas se utilizada da forma
correta, a combinação dos valores e boas práticas criam as condições necessárias para que
uma equipe de desenvolvimento obtenha sucesso em seus projetos.
45
REFERÊNCIAS
ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming – Guia
prático. Rio de Janeiro, Ed. Campos, 2002.
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, Pouso Alegre, 2007.
CASTRO, Vinicius A. Desenvolvimento Ágil com Programação Extrema. Monografia –
Curso de Ciência da Computação, Universidade Federal de Sergipe, São Cristóvão,
Sergipe, 2007.
GARCIA, Luís F. Qualidade de Software – Aula 5. Disponível em:
<http://www.garcia.pro.br/Ulbra-Qualidade/Qualidade%20de%20Software%20-
20Aula%205%20-%20qualidade%20processo.pdf> Acessado em: 01/05/2009.
LEITE, Júlio C.S.P. Qualidade de Software: Teoria e Prática, Orgs. Rocha, Maldonado,
Weber, Prentice-Hall, São Paulo, 2001. Capítulo 17.
NETO, Camilo L. M. As implicações da técnica de refatoração em desenvolvimento e
manutenção de Software. Monografia (Bacharel Sistemas de Informação) Faculdade
Zacarias de Góes. Valença, 2008.
PFLEEGER, Shari L. Engenharia de Software: Teoria e Prática; tradução Dino Franklin;
Revisão técnica Ana Regina Cavalcanti da Rocha. 2ª ed. São Paulo: Prentice- Hall, 2004.
(Pearson)
PRESSMAN, Roger S. Software engineering: a practitioner's approach. 4ª ed. New York:
McGraw-Hill, 1997.
PRESSMAN, Roger S. Engenharia de software; tradução Rosângela Delloso Penteado. 6ª
ed. São Paulo: McGraw-Hill, 2006.
RODRIGUES, Ana N.; MOURA, Mirtes; RODRIGUES, Paula; SANTOS, Vanusa; DevMedia
Group – Qualidade de Software - parte 1 e 2. Disponível em:
46
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=9408> Acessado em:
01/05/2009.
SENSAGENT. Disponível em: <http://dicionario.sensagent.com/feedback/en-en/> Acessado
em: 26/07/2009.
SOARES, Michel dos S. Comparação entre Metodologias Ágeis e Tradicionais para o
Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos
Faculdade de Tec. e Ciências de Conselheiro Lafaiete. Conselheiro Lafaiete, 2004.
SOMMERVILLE, Ian Engenharia de software; tradução André Maurício de Andrade
Ribeiro. 8ª ed. São Paulo: PEARSON UNIVERSITARIOS, 2007.
STANDISH, The Chaos Report. The Standish Group International, Inc 2001. Disponível em:
<http://www.standishgroup.com/sample_research/chaos_1994_1.php> . Última visita em
abril de 2009.
TELES, Vinícius M. Extreme Programming - Aprenda como encantar seus usuários
desenvolvendo software com agilidade e alta qualidade. Rio de Janeiro: Novatec
Editora, 2006.
TELES, Vinícius M. Um estudo de caso da adoção das práticas e valores do extreme
programming - Dissertação (Mestrado em Informática) – Universidade Federal do Rio de
Janeiro - UFRJ, 2005.
VIANA, Leonardo. M.; DESCHAMPS, Alexandro. XP – Extreme Programming. Disponível
em: <http://www.apicesoft.com/common/articles/Apice> Acessado em: 21/03/2009.
XProgramming.com What is Extreme Programming? Disponível em:
<http://xprogramming.com> Acessado em: 25/ 10/ 2009.
