ANHANGUERA EDUCACIONAL FACULDADE COMUNITRIA DE TAUBAT

TIAGO DOS SANTOS

UTILIZANDO METODOLOGIAS GEIS EM PROJETOS DE SOFTWARE

Taubat 2010

TIAGO DOS SANTOS

UTILIZANDO METODOLOGIAS GEIS EM PROJETOS DE SOFTWARE

Trabalho de Concluso de Curso apresentado ao Curso de Cincia da Computao da Faculdade Comunitria de Taubat da Anhanguera Educacional S.A., como requisito parcial para obteno do ttulo de Bacharel em Cincia da Computao. Orientador: Prof. Johnny Marques

Taubat 2010

Tiago dos Santos

UTILIZANDO METODOLOGIAS GEIS EM PROJETOS DE SOFTWAREAprovado em: ____/____/________ Nota:_________________

BANCA EXAMINADORA

_______________________________________ Prof. Johnny Marques

_______________________________________ Prof. Thalita Biazzuz Veronese

_______________________________________ Prof. Adalton Veloso de Lima

Taubat 2010

RESUMO

O descontentamento com as tradicionais e burocrticas metodologias para desenvolvimento de software levou alguns dos mais influentes desenvolvedores de softwares a assinar um manifesto visando melhoria dos processos de desenvolvimento de software. Desde ento, esse manifesto, o Manifesto gil, definiu e organizou algumas metodologias de desenvolvimento, chamadas de metodologias geis, que ganham cada dia mais fora, e cada vez mais profissionais aderem a seus princpios. As Metodologias geis visam, alm de eliminar os tradicionais atrasos e estouros de oramentos em projetos de software, melhorar a atividade de desenvolvimento de software e garantir que o cliente receba um produto com o mximo de valor para seus negcios, com qualidade assegurada, sem que o prazo e oramento sejam estourados, utilizando para isso tcnicas de gerenciamento de projetos e vrias prticas de engenharia de software que juntas tornam o processo robusto e confivel. Porm existem muitas dvidas e erros quanto implantao dessas novas metodologias, sendo o objetivo deste trabalho explicar o que so metodologias geis e os princpios que as envolvem, e tambm comparar uma metodologia gil com as metodologias tradicionais de desenvolvimento de software. O estudo ser concentrado na metodologia XP (Extreme Programming), por ser uma das mais utilizadas no Brasil e por abordar tanto a rea de gerenciamento de projeto como a rea de engenharia de software.

Palavras-chave:

Desenvolvimento

gil,

Metodologias

de

Desenvolvimento,

Engenharia de Software, Manifesto gil

ABSTRACT

The disappointment with the traditional and bureaucratic methodologies for software development has led some of the most influential software developers to be part of a manifesto to improve software development processes. Since then, this manifesto, the Agile Manifesto, defined and organized some agile development methodologies, called Agile, gaining more popularity every day, becoming more professional to adhere the principles identified. The Agile aim, besides eliminating the traditional delays and budget overruns in software projects, to improve software development activity and ensure that the customer receives a product with the most value for their businesses, with assured quality, without deadline and budget are blown out, making use of techniques of project management and various software engineering practices that together make the process robust and reliable. However there are many doubts and errors in the implementation of these new methodologies, and this project helps to explain what these methods and principles that involve them, and to compare an agile methodology to traditional software development. This study concentrates on the methodology XP (Extreme Programming), since this is one of the most widely used in Brazil and address both the area of project management as the area of software engineering.

Key-words: Agile Development, Development Methodologies, Software Engineering, Agile Manifesto

SUMRIO1 Introduo ................................................................................................................................ 6 1.1 Objetivo ................................................................................................................................ 6 1.2 Motivao e Justificativa ...................................................................................................... 6 1.3 Resultados Esperados ........................................................................................................... 6 1.4 Organizao do Trabalho...................................................................................................... 6 2 Reviso Bibliogrfica .............................................................................................................. 7 2.1 As Metodologias Tradicionais de Desenvolvimento de Software........................................ 8 2.1.1 Metodologia de Desenvolvimento em Cascata ................................................................. 8 2.1.2 Metodologias Derivadas da Metodologia de Desenvolvimento em Cascata .................. 10 2.1.3 RUP (Rational Unified Process) ...................................................................................... 12 2.2 Metodologias geis de Desenvolvimento .......................................................................... 13 2.2.1 Manifesto gil ................................................................................................................. 14 2.2.2 Extreme Programming (XP) ............................................................................................ 17 2.2.2.1 Origem do XP ............................................................................................................... 17 2.2.2.2 Valores do XP ............................................................................................................... 17 2.2.2.2.1 Comunicao ............................................................................................................. 18 2.2.2.2.2 Simplicidade .............................................................................................................. 18 2.2.2.2.3 Feedback .................................................................................................................... 18 2.2.2.2.4 Coragem .................................................................................................................... 18 2.2.2.3 Prticas do XP .............................................................................................................. 19 2.2.2.3.1 Jogo do Planejamento ................................................................................................ 20 2.2.2.3.2 Cliente Presente ......................................................................................................... 21 2.2.2.3.3 Programao em Par .................................................................................................. 21 2.2.2.3.4 Refatorao ................................................................................................................ 22 2.2.2.3.5 Desenvolvimento Guiado por Testes ......................................................................... 22 2.2.2.3.6 Cdigo Coletivo......................................................................................................... 23 2.2.2.3.7 Cdigo Padronizado .................................................................................................. 23 2.2.2.3.8 Design Simples .......................................................................................................... 23 2.2.2.3.9 Metfora .................................................................................................................... 24 2.2.2.3.10 Ritmo Sustentvel .................................................................................................... 24 2.2.2.3.11 Integrao Contnua................................................................................................. 25 2.2.2.3.12 Releases Curtos ....................................................................................................... 25 2.2.2.4 A Equipe Tcnica ......................................................................................................... 25 2.2.2.4.1 Gerente de Projeto ..................................................................................................... 26 2.2.2.4.2 Treinador ................................................................................................................... 26 2.2.2.4.3 Analista de Testes ...................................................................................................... 26 2.2.2.4.4 Desenvolvedor ........................................................................................................... 26 2.2.2.4.5 Cliente........................................................................................................................ 27 2.2.2.5 Mtricas ........................................................................................................................ 27 2.2.2.6 Organizao do Ambiente de Trabalho ........................................................................ 28 3 Comparando as Metodologias Tradicionais com XP ............................................................ 29 3.1 Problemas com as metodologias de desenvolvimento em cascata ..................................... 29 3.2 A Comparao .................................................................................................................... 30 3.3 As Variveis ....................................................................................................................... 31 3.3.1 Custo ................................................................................................................................ 31 3.3.2 Tempo .............................................................................................................................. 31 3.3.3 Qualidade ......................................................................................................................... 32

3.3.4 Escopo ............................................................................................................................. 32 3.3.5 Interaes Entre as Variveis .......................................................................................... 32 3.4 Detalhamento dos Requisitos no Incio do Projeto Versus Detalhamento dos Requisitos Durante o Desenvolvimento ..................................................................................................... 33 3.5 Crescimento Exponencial do Custo de Modificao Versus Crescimento Moderado do Custo de Modificao ............................................................................................................... 34 3.5.1 A Curva de Aumento Exponencial do Custo de Modificaes ....................................... 34 3.5.2 A Curva de Aumento Moderado do Custo de Modificaes........................................... 35 3.6 Escopo Fixo Versus Escopo Varivel ................................................................................ 37 3.6.1 Escopo Fixo ..................................................................................................................... 37 3.6.2 Escopo Varivel ............................................................................................................... 38 3.7 Entrega no Final do Projeto Versus Entregas Frequentes .................................................. 39 3.7.1 Entrega nica .................................................................................................................. 39 3.7.2 Entregas Frequentes......................................................................................................... 40 4 Consideraes Finais ............................................................................................................. 42 4.1 Concluso ........................................................................................................................... 42 4.2 Melhorias Futuras .............................................................................................................. 43 Referncias .............................................................................................................................. 44

6

1 1.1

Introduo ObjetivoEste trabalho tem por objetivo realizar um estudo da utilizao da metodologia

gil XP (Extreme Programming), apresentando as diferenas e a viabilidade de utilizao em comparao com metodologias de desenvolvimento de software tradicionais, em especial a metodologia em cascata.

1.2

Motivao e JustificativaA escolha do estudo deste tema foi feita por no haver estudos comparativos

mais completos entre as metodologias tradicionais de desenvolvimento e a metodologia gil XP.

1.3

Resultados EsperadosEste trabalho visa produzir um relatrio tcnico contendo pesquisa sobre os

passos para a adoo do XP e os resultados da comparao entre XP e as metodologias de desenvolvimento de software tradicionais. Quanto a comparao de XP com as metodologias de desenvolvimento tradicionais, o estudo visar identificar os pontos fortes e fracos de cada uma, e procurar verificar se de fato as metodologias geis possuem vantagens em relao a custo, prazo e qualidade dos projetos de software em comparao as metodologias de desenvolvimento em tradicionais.

1.4

Organizao do TrabalhoNo captulo 2 so apresentadas as metodologias abordadas neste trabalho,

destacando suas principais caractersticas. No captulo 3 feita uma comparao entre as metodologias tradicionais e as metodologias geis. No captulo 4 so apresentadas a considerao final, a concluso do trabalho e as melhorias pretendidas para futuros trabalhos.

7

2

Reviso BibliogrficaDurante toda a histria do desenvolvimento de software sempre foram

comuns atrasos no prazo de projetos, aumento dos custos e qualidade abaixo do tolervel, alm do cancelamento de muitos projetos por um destes motivos ou porque o sistema ficou obsoleto antes mesmo de sua concluso. Projetos que caminham durante todo o tempo conforme o planejado esto longe de ser a maioria. Estudos realizados periodicamente pelo Standish Group International [1], intitulados Chaos Research, apontam as percentagens de projetos que so concludos com sucesso, que so concludos com estouro de oramento ou de prazo e os que so cancelados. Em 1994, no primeiro estudo realizado, os projetos bem sucedidos representavam 16,2%, os cancelados, 31,1%, e os projetos desafiados (com atrasos ou oramento excedido) representavam 52,7%. J em 2009 os projetos bem sucedidos representavam 32%, os cancelados 24% e os projetos com atraso ou oramento excedido 44%. Como possvel observar na Figura 2.1, embora a percentagem de projetos bem sucedidos tenha dobrado, as percentagem de projetos cancelados e de projetos que atrasam ou estouram oramento ainda muito alta.

Figura 2.1 Comparao entre Chaos Report de 1994 e 2009 Visando eliminao dos recorrentes problemas em projetos de software, ao longo do tempo alguns profissionais desenvolveram e adaptaram diversos processos

8

e metodologias que contribuam para que seus projetos tivessem sucesso. Aps algum tempo, esses profissionais reuniram-se e criaram o Manifesto gil, e denominaram estas metodologias como metodologias geis. Este trabalho aborda como as metodologias geis de desenvolvimento podem ser utilizadas como uma soluo para os problemas dos projetos de software, e compara suas vantagens em relao a metodologias de desenvolvimento tradicionais.

2.1

As Metodologias Tradicionais de Desenvolvimento de SoftwarePodemos chamar de metodologias tradicionais de desenvolvimento de

software as metodologias de desenvolvimento em cascata (do ingls waterfall) e processos de desenvolvimento que nela se baseiam [2], j presentes no mercado h vrias dcadas. Alm disso, alguns processos de desenvolvimento, embora no sejam baseados no modelo cascata, acabam sendo adotados em muitos projetos de uma forma que os aproxima muito do modelo em cascata. Isso acontece, por exemplo, em casos de adoo do RUP (Rational Unified Process) [2], fazendo com que RUP comumente seja definido como uma das metodologias tradicionais de desenvolvimento.

2.1.1 Metodologia de Desenvolvimento em CascataDas metodologias tradicionais, a metodologia de desenvolvimento em cascata se destaca historicamente por ser a mais divulgada e utilizada nas empresas, conforme [4]: Em artigos relativamente recentes ([Neill+03], [Laplante+04]), Ph. Laplante e C. Neill relatam que o modelo em cascata ainda o ciclo de vida mais usado, segundo levantamento feito pelos autores. A metodologia de desenvolvimento em cascata divide o desenvolvimento de software em vrias fases, conforme mostra a Figura 2.2, sendo cada fase executada separadamente, e obedece a uma sequncia obrigatria com demarcaes predefinidas de avaliao [3]. A metodologia de desenvolvimento em cascata foi descrita pela primeira vez no estudo do Dr. Winston W. Royce, no ano de 1970, denominado Gerenciando o Desenvolvimento de Grandes Sistemas de Software [5]. As fases da metodologia de desenvolvimento em cascata e sua ordem so:

9

1. Requisitos: devem ser levantados pela equipe do projeto, em conjunto com representantes do cliente, usurios e, possivelmente, especialistas da rea de aplicao [4]. Os requisitos de alta qualidade devem ser claros, completos, sem ambiguidade, implementveis, consistentes e testveis [4]. A fase de requisitos tem como resultado um artefato que especifica os requisitos, o Modelo do Problema [4]; 2. Anlise: rene as atividades que visam a modelar de forma precisa os conceitos relevantes do domnio do problema. Essa modelagem serve tanto para verificar a qualidade dos requisitos obtidos pelas atividades da disciplina de Requisitos quanto para tornar esses requisitos precisos e detalhados o suficiente para que sirvam de base para atividades de Desenho [4]. A fase de anlise tem como resultado um modelo, geralmente um modelo UML nos processos orientados a objetos, que deve conter os detalhes necessrios para servir de base para o desenho do produto [4]; 3. Desenho: tem por objetivo definir uma estrutura implementvel para um produto de software que atenda aos requisitos especificados para ele [4]. O principal artefato desta fase o Modelo de Soluo, uma consequncia do Modelo do Problema, mas que geralmente apresenta muito mais detalhes [4]; 4. Implementao: realiza o desenho de um sistema em termos de diversos tipos de componentes de cdigo fonte e cdigo binrio [4]. a fase em que o sistema de fato desenvolvido. A documentao gerada nessa fase geralmente consiste em comentrios no cdigo fonte e a documentao para usurio; 5. Testes: consiste em operar um sistema ou componente sob condies especificadas, observando ou registrando os resultados e avaliando algum aspecto desse sistema ou componente [4]. A disciplina Teste visa verificar os resultados da implementao, atravs do planejamento, desenho e realizao das atividades desse processo. Com o resultado dos testes so gerados relatrios que visam demonstrar que o sistema no tem erros, ou apontar onde esto os erros do sistema que devem ser corrigidos.

10

Figura 2.2 Fases da Metodologia de Desenvolvimento em Cascata

2.1.2 Metodologias Derivadas da Metodologia de Desenvolvimento em CascataA metodologia de desenvolvimento em cascata deu origem a outras metodologias que seguem alguns principais aspectos, entre os quais podemos destacar a existncia de vrias fases, o detalhamento de todos os requisitos no incio do projeto e a gerao de grande quantidade de artefatos.

11

Uma das variaes da metodologia em Cascata a Cascata com Realimentao [4], representada na Figura 2.3, na qual permitida a sobreposio entre fases e a realimentao de correes.

Figura 2.3 Representao da Metodologia em Cascata com Realimentao Porm, apesar de haver variaes desta metodologia, comumente essas variaes tambm so chamadas de metodologia de desenvolvimento em cascata.

12

2.1.3 RUP (Rational Unified Process)O ciclo de vida do RUP iterativo, e pode ser descrito em duas dimenses que representam basicamente os aspectos dinmicos e estticos do processo [6]. Os aspectos dinmicos do processo, uma vez aprovados, so representados por fases e iteraes. O tempo de vida de um sistema dividido em ciclos de vida, cada qual produzindo um produto novo, pronto para entregar a verso do sistema. Cada ciclo de vida expresso em termos de quatro fases de srie, que so divididas em iteraes, conforme mostra a Figura 2.4. Segundo [7] uma metodologia em cascata no compatvel com RUP, embora no seja incomum encontrar projetos que utilizam um processo em cascata e se fantasiam de RUP. O RUP no um processo de desenvolvimento derivado da metodologia em cascata, porm ao longo dos anos o RUP tem sido adotado de uma maneira que o torna parecido com esta metodologia por muitas empresas. Por esse motivo muitas pessoas tratam, erroneamente, o RUP como uma metodologia de desenvolvimento em cascata. Esse motivo tambm faz com que alguns classifiquem o RUP como uma metodologia tradicional de desenvolvimento.

Figura 2.4 Representao das Fases do RUP

13

2.2

Metodologias geis de DesenvolvimentoMetodologias geis de desenvolvimento so conjuntos de prticas e mtodos

de desenvolvimento, criados e desenvolvidos ao longo das ltimas duas dcadas, que tm por objetivo tornar o desenvolvimento de software rpido, com custo controlvel e melhorar a qualidade do software [7]. Uma das formas utilizadas para isso a diminuio da burocracia encontrada nas metodologias tradicionais de desenvolvimento, sobretudo a metodologia de desenvolvimento em cascata. Segundo [7], para muitas pessoas o apelo das metodologias geis a reao delas burocracia das metodologias tradicionais. A diferena mais evidente que as metodologias geis so menos centradas em documentao, gerando menos documentao para cada tarefa. Para muitas pessoas envolvidas com metodologias geis, a melhor documentao que existe para um software seu cdigo fonte. Mas segundo [7] as diferenas mais importantes das metodologias geis para as metodologias tradicionais so as seguintes premissas: 1. Metodologias Metodologias geis so adaptativas tentam ao invs de predeterminantes. do processo de

tradicionais

prever

detalhes

desenvolvimento no incio do projeto, e acabam tendo muitos problemas quando so necessrias mudanas no projeto, como atrasos na entrega do projeto. Nas metodologias geis a premissa de que sempre haver mudanas no projeto que no podem ser previstas em seu incio, e essas mudanas so bem vindas, estando todos os envolvidos no projeto preparados para elas; 2. Metodologias geis so orientadas a pessoas e no a processos. Metodologias tradicionais definem um processo que ir funcionar bem, independentemente de quem os utilize. Mtodos geis afirmam que nenhum processo jamais ser equivalente habilidade da equipe de desenvolvimento. Portanto, o papel do processo dar suporte equipe de desenvolvimento e seu trabalho. As metodologias geis de desenvolvimento seguem como referncia o desenvolvimento iterativo, em espiral, conforme Figura 2.5, que recomenda que todas as fases descritas no modelo em cascata sejam executadas diversas vezes ao longo do projeto, produzindo ciclos que se repetem ao longo de todo o

14

desenvolvimento e recebem o nome de iteraes [2]. No desenvolvimento iterativo o software cresce a cada iterao, onde o resultado um software pronto, com poucas funcionalidades na primeira iterao e todas as funcionalidades na ltima.

Figura 2.5 Desenvolvimento iterativo, em espiral.

2.2.1 Manifesto gilAntes de as metodologias geis serem adotadas por um nmero grande de desenvolvedores e empresas e ganharem um foco maior, j havia inmeras pessoas que utilizavam metodologias com as premissas dos processos geis em seus projetos [8]. Porm, apesar dessas metodologias terem similaridades, no havia nada que as organizasse. Assim, em fevereiro de 2001 os representantes de cada uma dessas metodologias foram convidados para um workshop em uma estao de esqui em Utah, nos EUA, com o objetivo de discutir essas similaridades entre as diversas metodologias. O resultado do workshop foi a criao do Manifesto gil, que contm a declarao dos valores e princpios comuns a todas as metodologias que discordavam da metodologia em cascata [8]. Vale tambm ressaltar que o termo gil s comeou a ser utilizado a partir dessa data. O Manifesto gil foi um ponto de partida para uma maior divulgao das metodologias geis, e continua sendo at hoje uma importante base para aqueles que queiram utilizar alguma metodologia gil. Seguem abaixo os valores do Manifesto gil [9]:

15

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o ns mesmos e ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos a valorizar: Indivduos e interaes mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. Alm dos valores, o Manifesto gil tambm prega 12 princpios [9]:

Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado.

Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo.

Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho.

16

O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face.

Software funcionando a medida primria de progresso.

Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente.

Contnua ateno excelncia tcnica e bom design aumenta a agilidade.

Simplicidade - a arte de maximizar a quantidade de trabalho no realizado - essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes auto organizveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.

Toda metodologia que pretenda ser uma metodologia gil por regra deve seguir esses valores e princpios. O manifesto gil [8] um ponto de partida para aqueles que compartilham as mesmas idias bsicas, e um de seus frutos foi a criao da Aliana gil, organizao sem fins lucrativos que procura promover o conhecimento e a discusso sobre todas as metodologias geis.

17

2.2.2 Extreme Programming (XP) 2.2.2.1 Origem do XPEsta uma das metodologias geis mais conhecidas. Pode-se dizer que sua origem data de meados da dcada de 1980, dentro da cultura Smalltalk, quando Kent Beck e Ward Cunningham trabalhavam juntos numa empresa chamada Tektronixs [2]. Vrias das prticas do XP vieram do Smalltalk. Kent e Ward, a partir dessas prticas e com o desenvolvimento de outras, desenvolveram ainda na dcada de 1980 um conjunto de boas prticas, condensadas no padro de linguagem Episodes. Com o passar dos anos, alm do aperfeioamento de Kent e Ward sobre essas prticas, tambm surgiram vrias contribuies de outros profissionais sobre algumas das prticas utilizadas por eles. A consolidao do XP se deu em 1996, quando Kent Beck foi contratado para resolver problemas com o projeto de folha de pagamento da Chrysler, chamado de C3, desenvolvido em Smalltalk. Ao analisar o que j existia do projeto, ele sugeriu que o processo fosse reiniciado, a melhor opo frente aos inmeros problemas existentes. Kent ento foi convencido a ser o responsvel pelo projeto. Ao iniciar o projeto, Kent entrevistou cada um dos profissionais envolvidos e durante as entrevistas lhes explicava como o projeto iria seguir daquele momento em diante. Essas explicaes eram as prticas do XP, que foram sendo nomeadas naquele mesmo instante. O prprio nome Extreme Programming XP foi criado durante esse projeto, quando as prticas at ento informais do XP tornaram-se de fato uma metodologia. A metodologia XP foi criada visando retornar o mximo de valor possvel para o cliente a cada dia de trabalho da equipe de desenvolvimento, diminuindo o custo e o risco do projeto.

2.2.2.2 Valores do XPOs valores do XP so parmetros que servem para saber se o projeto est no caminho certo, evitando que membros da equipe voltem-se para seus prprios interesses [10]. Os valores so 4, e cada um deles fundamental para a utilizao da metodologia.

18

2.2.2.2.1

Comunicao

Muitos dos problemas so provocados por falhas na comunicao, onde algo importante no foi transmitido para os envolvidos [10]. A comunicao entre os membros da equipe e entre o cliente e a equipe deve ser rica e direta. A boa comunicao a garantia de que todos os detalhes sero tratados adequadamente, e no restar dvida alguma sobre qualquer parte do projeto. E atravs da comunicao que o cliente passar seu aprendizado sobre o projeto para a equipe. A forma como a metodologia XP mantm a comunicao fluindo empregando vrias prticas que no podem ser feitas sem comunicao [10].

2.2.2.2.2

Simplicidade

Uma das maneiras para tornar um projeto de software gil mant-lo o mais simples possvel. Simplicidade uma das palavras-chave para a metodologia XP. Na metodologia XP, a principal forma de se manter a simplicidade de um sistema realizar implementaes simples do cdigo e modifica-lo inserindo as modificaes necessrias no futuro ao invs de criar generalizaes no cdigo tentando prever futuras funcionalidades que podem nunca serem necessrias [10]. Isso poupa tempo de desenvolvimento, baixando seu custo.

2.2.2.2.3

Feedback

Feedback a realimentao que o cliente fornece equipe de desenvolvimento quando aprende algo novo sobre o sistema e sobre os requisitos, e tambm reflete a realimentao que os desenvolvedores fornecem ao cliente [2]. Na metodologia XP o feedback deve ser constante e rpido. Cada trabalho realizado e entregue ao cliente deve ser avaliado pelo cliente que dar o feedback equipe informando se suas necessidades foram atendidas ou e h mudanas que devem ser realizadas. Isso garante que o cliente ter sempre suas necessidades atendidas. Caso no haja feedback, problemas podem ficar acumulados e a equipe no ter certeza de que o que foi desenvolvido seja satisfatrio ao cliente.

2.2.2.2.4

Coragem

A equipe e o cliente que optar em utilizar o XP em seus projetos precisam de coragem para fazer a adoo com sucesso. Coragem necessria pois a metodologia XP contraria muitos aspectos das metodologias tradicionais de

19

desenvolvimento, e muitas vezes entra em confronto com a forma de trabalho de muitos profissionais envolvidos no projeto. A coragem necessria desde quando se prope um processo novo, passando pela proposta de contratos de escopo varivel, e tambm ao se utilizar todas as prticas do XP que veremos adiante.

2.2.2.3 Prticas do XPO XP tem 12 prticas, que so tcnicas que guiam os projetos que utilizam esta metodologia. Nenhuma dessas prticas nica ou original, todas tem sido utilizadas desde a codificao dos primeiros programas [10], e muitas delas foram abandonadas depois de seus pontos fracos terem se tornado aparentes. Porm as prticas do XP trazem seus maiores benefcios quando todas so utilizadas em conjunto. O ponto fraco de uma prtica compensada pelos pontos fortes das outras [10]. A Figura 2.6 mostra a inter-relao entre as prticas.

Figura 2.6 Prticas da metodologia XP A descrio e a explicao sobre cada uma das prticas esto detalhadas a seguir.

20

2.2.2.3.1

Jogo do Planejamento

Na metodologia XP o planejamento realizado diversas vezes ao longo do projeto, assegurando que a equipe de desenvolvimento esteja sempre trabalhando no que gera mais valor para o cliente e que as prioridades sejam constantemente revisadas [2]. O jogo do planejamento refere-se forma como todo o planejamento tratado no XP. As responsabilidades do cliente e da equipe de desenvolvimento so separadas claramente, sendo o cliente responsvel pelas decises de negcio, e a equipe pelas decises tcnicas [2]. Ao fazer o levantamento das funcionalidades do sistema, so utilizadas estrias. Cada estria representa uma funcionalidade, que registrada em um carto e escrita pelo cliente com suas prprias palavras. Caso uma estria seja muito grande, consumindo muito tempo de desenvolvimento, esta pode ser dividida em tarefas, que so escritas em novos cartes. O cliente deve priorizar cada estria. Para que o cliente priorize da melhor forma, cada estria deve ter seu tempo de desenvolvimento estimado, utilizando-se uma unidade de medida todas as estrias. Um projeto desenvolvido utilizando-se XP dividido em releases. Release o tempo em que um conjunto de funcionalidades dever ser desenvolvido e entregue ao cliente. O tempo de cada release deve ser pequeno, preferivelmente no mximo dois meses. O objetivo de dividir o projeto em releases entregar algo de valor para o cliente o mais rpido possvel, alm de tambm poder receber o feedback do cliente de forma mais rpida. No incio de cada release o cliente deve indicar quais so as estrias que devem ser desenvolvidas no release e prioriz-las, com base no tempo disponvel que a equipe de desenvolvimento acredita que ter. Porm o cliente pode alterar, substituir ou remover algumas estrias caso necessrio. No final do release o sistema deve ser colocado em produo para que todos os usurios possam utiliz-lo. Cada release dividido em iteraes. Um iterao um pequeno espao de tempo dedicado implementao de um conjunto de estrias, que deve ter de uma a trs semanas de durao, e na maioria dos projetos tem duas semanas de durao. No incio da iterao realizada a reunio de planejamento de iterao, na

21

qual definido entre o cliente e a equipe quais estrias sero includas na iterao, com base no tempo que a equipe estima que ter disponvel na iterao, com base na mesma unidade de medida utilizada para estimar as estrias. No ultimo dia da iterao realizada a reunio de encerramento, na qual so executados todos os testes de aceitao para validar todo o sistema. Todos os dias deve ser realizada uma reunio rpida (em torno de 10 minutos) com a equipe de desenvolvimento e o cliente. Esta reunio chamada de stand up meeting, ou reunio em p, pois recomenda-se que todos fiquem em p para que ela no se prolongue. Os dois principais objetivos dessa reunio repassar o que foi realizado no dia anterior e decidir o que ser feito no dia que est comeando [2].

2.2.2.3.2

Cliente Presente

O XP prega que o cliente esteja sempre presente durante todo o projeto. Essa pessoa deve ser algum que realmente usar o sistema quando ele estiver em produo [10]. O cliente deve estar presente para passar suas necessidades para a equipe, para dar o feedback sobre as funcionalidades entregues e para responder as dvidas da equipe, evitando que seja realizado trabalho especulativo [2]. Assim, uma garantia maior de que suas necessidades sero atendidas e o sistema agregar o maior valor possvel para os negcios. O principal objetivo do cliente estar presente que ele possa guiar a direo do projeto [2].

2.2.2.3.3

Programao em Par

Programao em par consiste em dois desenvolvedores programarem juntos durante todo o tempo utilizando o mesmo computador, revezando-se o digitador de tempos em tempos [2]. Programao em par no uma pessoa programando enquanto outra assiste [10]; o objetivo que, juntos, os dois desenvolvedores troquem experincia, pensem e discutam o problema a ser resolvido, chegando a uma soluo mais rapidamente. Alm disso, um pode fazer a reviso do que o outro que est no controle do teclado est digitando, diminuindo assim a possibilidade de um erro passar despercebido [2]. A princpio as pessoas pensam que a programao em par possa diminuir a produtividade da equipe, porm o efeito o oposto. Juntando suas experincias, duas pessoas tendem a resolver um problema com mais rapidez. Como sempre

22

haver uma pessoa verificando o que o outro codifica a possibilidade de erros diminui, o que acaba por diminuir o tempo gasto em identificar e acertar erros de digitao e de lgica. Outro benefcio que nas duplas sempre haver uma pessoas menos experiente do que a outra, e esta ltima acaba passando parte de sua experincia para a outra, deixando todos os desenvolvedores em um alto nvel de experincia [2].

2.2.2.3.4

Refatorao

Consiste na tcnica de revisar o cdigo e melhor-lo com frequncia, sem que isso altere o comportamento do cdigo, mantendo o cdigo o mais legvel e simples possvel e, ao mesmo tempo, a simplicidade do design do software [2]. A refatorao no feita com base em especulaes, e sim quando o sistema precisa. Quando o sistema requer cdigo duplicado (quando necessrio escrever um mesmo trecho de cdigo em outra parte do sistema) ele est precisando de refatorao [10].

2.2.2.3.5

Desenvolvimento Guiado por Testes

Na metodologia XP os testes so obrigatrios, logo testar parte da rotina diria dos desenvolvedores que trabalham com a metodologia XP. Isso feito visando eliminao de qualquer erro no software, e entrega de um software com o mximo de qualidade possvel [2]. Na metodologia XP temos dois tipos de teste: teste de unidade e teste de aceitao. No teste de unidade os testes so feitos medida que o software desenvolvido, e no ao final do desenvolvimento, e cada classe testada isoladamente [2]. Os testes de unidades devem ser automatizados. A justificativa para se escrever os testes medida que se codifica que assim os trechos com erros so encontrados to logo sejam codificados. Outro motivo que, no caso de uma modificao posterior no cdigo para, por exemplo, acrescentar uma nova funcionalidade, o teste executado para verificar se tudo ainda est funcionando como deveria. Os programadores escrevem testes de unidade para que sua confiana na operao do programa possa se tornar parte do programa em si [10]. O teste de aceitao simula a interao do usurio com o sistema e verifica se seu comportamento est correto [2]. como um roteiro passo-a-passo de aes

23

que o usurio deve executar. O teste de aceitao executado ao final de cada iterao, e deve ser criado pelo cliente com a ajuda de um analista de testes [2].

2.2.2.3.6

Cdigo Coletivo

Todas as classes codificadas em um projeto que siga a metodologia XP pertencem a todos da equipe, ou seja, todos da equipe podem alterar qualquer classe do sistema. Os benefcios so a eliminao de ilhas de conhecimento (quando o conhecimento sobre determinada parte do software dominado por apenas uma pessoas), a disseminao do conhecimento e um cdigo melhor escrito por todos, pois, como todos tm acesso ao cdigo, todos devero implementa-lo de forma legvel [2]. Todos os integrantes da equipe so responsveis pelo sistema inteiro, sendo que nem todos conhecem todas as suas partes igualmente, mas todos conhecem um pouco sobre cada parte [10].

2.2.2.3.7

Cdigo Padronizado

O cdigo padronizado pode ser entendido como a adoo de somente um estilo de codificao por todos os programadores do projeto. Padronizar o cdigo ajuda a manter o cdigo legvel para todos na equipe [2]. O padro adotado deve exigir a menor quantidade de trabalho possvel, consistente com a regra de no duplicar cdigo, devendo enfatizar a comunicao da equipe [10].

2.2.2.3.8

Design Simples

A metodologia XP determina que a equipe deve sempre assumir o design mais simples possvel e capaz de fazer uma funcionalidade passar nos testes criados para a mesma, o que leva a um desenvolvimento ser mais gil e menos propenso a erros [2]. Para se dizer que um design simples, necessrio que o projeto siga as seguintes regras [10]:

24

1. O projeto deve executar todos os testes; 2. No deve haver lgica duplicada; 3. O projeto deve expressar todas as intenes importantes para os programadores; 4. Deve haver o menor nmero possvel de classes e mtodos.

2.2.2.3.9

Metfora

Metforas so utilizadas para facilitar a transmisso de idias complexas em uma forma mais simples, tornando mais fcil o entendimento de um determinado assunto [2]. Um exemplo de utilizao de metfora referir um sistema de clculo de penso como uma planilha de clculo, porm no queremos dizer literalmente que o sistema uma planilha de clculo. A metfora apenas ajuda todos os envolvidos no projeto a entender os elementos bsicos e seus relacionamentos [10].

2.2.2.3.10 Ritmo SustentvelEm toda profisso utiliza-se a premissa de que para se produzir mais em menos dias necessrio fazer horas extras. Na maioria das profisses isso pode ser verdade, porm, em desenvolvimento de software e em outras profisses que trabalham com lgica e criatividade, essa premissa atrapalha a produtividade, j que horas extras acabam por desgastar os trabalhadores, diminuindo sua capacidade de concentrao e criatividade [2]. A abordagem empregada pela metodologia XP com o ritmo sustentvel recomenda que no se pode trabalhar uma segunda semana com horas extras [10]. Trabalhar alm do horrio pode acelerar o desenvolvimento nos primeiros dias, mas efeitos colaterais comeam a aparecer assim que as pessoas se cansam [2]. Trabalhar em ritmo sustentvel garante que as pessoas sempre chegaro no dia seguinte para trabalhar bem dispostos, com plena capacidade de concentrao e criatividade.

25

2.2.2.3.11 Integrao ContnuaSempre que uma funcionalidade terminada deve ser feita a integrao dessa funcionalidade com o restante do sistema. Uma maneira simples de se fazer isso ter uma mquina dedicada apenas integrao [10]. Na mquina de integrao, o par com cdigo a ser integrado deve baixar a verso atual, baixar as modificaes, conferindo e resolvendo qualquer coliso, e executar os testes at que todos estejam 100% corretos [10]. Caso algum erro tenha surgido, o par que est integrando deve realizar a correo imediata deste erro. O processo de integrao normalmente realizado vrias vezes por dia.

2.2.2.3.12 Releases CurtosReleases curtos (ou entregas frequentes) tm por objetivo entregar valor para o cliente o mais rpido possvel e de forma contnua. Quanto mais curto o release, maior o fluxo de entrega de valor para o cliente, e menor o tempo de retorno de investimento para o cliente [2]. Cada entrega deve ter o menor tamanho possvel, contendo requisitos de maior valor para o negcio [10]. Embora o release deva ser o mais curto possvel, no se pode implementar e entregar uma funo incompleta apenas para tornar mais curto o ciclo de entrega [10].

2.2.2.4 A Equipe TcnicaCertos papis precisam ser preenchidos para que um time que siga a metodologia XP funcione [10]. Pode haver outros papeis, porm os mais comum em uma equipe XP so: Gerente de Projeto; Treinador; Analista de Teste ou Testador; Desenvolvedor ou Programador; Cliente.

26

2.2.2.4.1

Gerente de Projeto

Responsvel pelos assuntos administrativos do projeto. Seu papel administrar o relacionamento com o cliente e liberar a equipe de questes no ligadas diretamente atividade de desenvolvimento, alm de administrar o relacionamento com o cliente, assegurando que o mesmo participe ativamente do desenvolvimento e fornea as informaes para que a equipe possa implementar o sistema desejado [2]. O gerente de projeto deve ter coragem, confiana e ser persistente para que o time compra suas funes [10].

2.2.2.4.2

Treinador

O treinador o responsvel tcnico do projeto. um profissional tecnicamente bem preparado com a funo de orientar a equipe a seguir as boas prticas recomendadas pela metodologia XP [2]. Todo participante de um time que siga a metodologia XP deve compreender sua aplicao de XP at certo ponto, sendo o treinador o responsvel por entender mais profundamente todas as prticas de XP e guiar a equipe caso aparea algum problema [10].

2.2.2.4.3

Analista de Testes

Responsvel por ajudar o cliente a escrever os teste de aceitao [2], o analista de testes focado no cliente. Quando os testes funcionais no so parte do conjunto de integrao, o analista de testes responsvel por executar os testes funcionais regularmente e apresentar os resultados em um lugar bem visvel [10].

2.2.2.4.4

Desenvolvedor

No XP no existem divises entre analistas, projetistas e programadores [2]. So os desenvolvedores que analisam, projetam e codificam o sistema, ou seja, so eles que efetivamente constroem o sistema. O desenvolvedor deve ter as seguintes habilidades [10]: Habilidade de se comunicar; Habilidade de simplicidade; Habilidades tcnicas (programar, refatorar, fazer testes);

27

Disposio de abrir mo do sentimento de posse individual; Reconhecer e enfrentar seus medos (ter coragem).

2.2.2.4.5

Cliente

O cliente o representante da empresa para quem o software est sendo desenvolvido. O cliente deve ficar com o time, estar disponvel para responder questes, resolver disputas e definir prioridades de menor escala [10].

2.2.2.5 MtricasA mtrica a ferramenta bsica de gerenciamento da metodologia XP. Ela permite que o time defina a velocidade do projeto [10]. Exemplos de mtricas utilizadas em projetos XP so: Nmeros de testes escritos; Status das funcionalidades (no iniciadas, em andamento, concludas); Andamento, em pontos, da iterao. As mtricas so as formas de comunicar a todos os envolvidos no projeto sobre seu andamento, principalmente os problemas no projeto. O meio de comunicao das mtricas um grande mural [10], conforme modelo apresentado na Figura 2.7, que deve ser bem visvel a todos.

Figura 2.7 Exemplo de Mural

28

Deve haver um cuidado na utilizao das mtricas, j que elas tendem a se deteriorar com o tempo, devendo-se utilizar trs ou quatro de cada vez, e tir-las quando j serviram seu propsito [10].

2.2.2.6 Organizao do Ambiente de TrabalhoPara que se possa desenvolver um projeto utilizando-se a metodologia XP, uma das necessidades uma sala apropriada onde a equipe possa desenvolver se trabalho da melhor forma possvel. A organizao do ambiente de trabalho tem importncia vital para um projeto que siga a metodologia XP porque a forma como a equipe se organiza influencia diretamente a sua capacidade de adotar as prticas do XP [2]. Um dos principais pontos em relao organizao do ambiente de trabalho que todos os membros das equipe possam trabalhar prximos uns dos outros [2]. Isso facilita a comunicao entre eles, permite maior facilidade para programao em par, e permite que os membros escutem acidentalmente conversas para as quais eles tm contribuies vitais [10]. O layout recomendado para um escritrio de um projeto XP um espao aberto, onde todos podem se ver e comunicar-se facilmente, com algumas reas fechadas que possam ser usadas para guardar objetos pessoais, fazer ligaes particulares ou mesmo para algum que precise passar um tempo sozinho sem ser interrompido [10]. As mesas devem ser grandes o suficiente para pelo menos duas pessoas sentarem-se juntas, o que permite a programao em par. Deve tambm haver espao para que as pessoas circulem com facilidade.

29

3 3.1

Comparando as Metodologias Tradicionais com XP Problemas com as metodologias de desenvolvimento em cascataGrande parte dos problemas em projetos de software atribudo s

metodologias de desenvolvimento tradicionais. Muitas falhas nos conceitos das metodologias tradicionais so apontadas como causa desses problemas. No mesmo estudo em que o Dr. Winston W. Royce descreveu a metodologia de desenvolvimento em cascata, ele acrescentou aps a descrio das fases: eu acredito neste conceito, mas a implementao descrita acima arriscada e convida ao fracasso [5]. A justificativa de que a fase de teste, que a ultima, o primeiro momento em que o sistema experimentado. No caso em que o sistema entregue no corresponde ao esperado ou alguns requisitos no tenham sido cumpridos, uma grande reformulao necessria. H tambm problemas nas premissas das metodologias de desenvolvimento tradicionais, uma vez que seguem prticas industriais. Segundo [2], existe um forte apelo no sentido de utilizar as prticas industriais em qualquer processo de fabricao, inclusive no desenvolvimento de software. Porm praticas industriais no so adequadas atividade de desenvolvimento de software, que envolve muita atividade intelectual e criatividade [2][3], diferente do trabalho manual, que depende basicamente de habilidades manuais. Teles [2] cita DeMarco e Liste (1987):O desenvolvimento intrinsecamente diferente da produo [industrial]. Mas os gerentes de desenvolvimento sempre permitem que o seu pensamento seja moldado por uma filosofia gerencial derivada inteiramente do ambiente de produo [industrial].

importante compreender que para gerenciar trabalhadores do conhecimento de forma apropriada, preciso adotar medidas praticamente opostas quelas indicadas para o trabalho manual.

Segundo [4] o modelo em cascata puro de baixa visibilidade para o cliente, que s recebe o resultado final do projeto. Isso faz com que o cliente s comece a ter o retorno sobre o investimento teoricamente a partir do final do projeto.

30

Muitos profissionais tambm consideram o fato de todos os requisitos serem levantados e detalhados no incio do projeto como um dos motivos que levam a falhas nos projetos que utilizam as metodologias tradicionais, j que no h garantia nenhuma de que os requisitos no iro mudar at o final do projeto. Isso aliado ao fato de que comumente o cliente s utilizar o sistema aps a entrega no final do projeto acaba gerando funcionalidades que no atendem as necessidades reais do cliente. As excessivas burocracia e documentao geradas por ela so tambm apontadas como fatores geradores de problemas. Martin Fowler em seu artigo afirma que h tanta coisa a se fazer para seguir a metodologia que todo o ritmo de desenvolvimento fica mais lento [8].

3.2

A ComparaoAps conhecermos as caractersticas das metodologias tradicionais de

desenvolvimento e das metodologias geis, em especial da metodologia XP, podemos agora compar-las, expondo suas principais diferenas e seus pontos fortes e fracos. Durante o estudo, alguns pontos foram identificados como as principais diferenas entre as metodologias tradicionais e as metodologias geis, neste caso a metodologia XP. Essas diferenas sero listadas sempre com a caracterstica das metodologias tradicionais precedendo as caractersticas da metodologia XP. As principais diferenas so: Custo de modificao com crescimento exponencial Versus custo de modificao com crescimento moderado; Detalhamento dos requisitos no incio do projeto Versus detalhamento dos requisitos durante o desenvolvimento; Escopo fixo Versus escopo varivel; Entrega no final do projeto Versus entregas frequentes. Alm da comparao, sero apontados os motivos que podem levar escolha de uma metodologia tradicional de desenvolvimento ou de uma metodologia gil.

31

3.3

As VariveisAntes, porm, de fazermos a comparao entre as metodologias, devemos

conhecer quatro variveis que fazem parte de projetos de software: Custo; Tempo; Qualidade; Escopo. Uma das diferenas entre as metodologias tradicionais e a metodologia XP a forma como cada uma controla essas variveis.

3.3.1 CustoA quantidade de dinheiro destinada a um projeto de software deve ser bem dimensionada. A primeira impresso de que quanto mais dinheiro destinado a um projeto, melhor ser o andamento do projeto. Porm, dinheiro demais no incio do projeto cria mais problemas do que resolve, devendo iniciar o projeto com pequenos investimentos, e aumentando-o com o tempo [10]. Destinar pouco dinheiro ao projeto tambm pode trazer problemas. Com falta de dinheiro o projeto no ser capaz de resolver o problema de negcios de cliente [10]. Geralmente a rea de negcios da empresa deseja destinar o mnimo de recursos possvel para o projeto. Deve haver um equilbrio entre a necessidade de investimento que o projeto necessita e o investimento que a rea de negcios da empresa pode fazer.

3.3.2 TempoEm teoria, quanto maior o tempo disponvel para se entregar um projeto, melhor. Mas deve-se tomar cuidado, pois com muito tempo disponvel a equipe pode relaxar, acreditando que sempre tero tempo suficiente. Muito tempo tambm significa tempo maior para o retorno de investimento. Tempo insuficiente pode condenar o projeto. A qualidade ser insuficiente, o escopo no ser realizado, e custo e tempo aumentaro para acertar os problemas gerados.

32

O desafio conseguir calcular o tempo de entrega do projeto de forma que no sobre nem falte tempo.

3.3.3 QualidadeA qualidade talvez seja a varivel mais importante em um projeto. Talvez por esse motivo qualidade deveria ser uma constante e no uma varivel. Sacrificar a qualidade em um projeto de software pode trazer ganhos a curto prazo, mas o custo muito grande [10], principalmente a longo prazo. Por outro lado, investir em qualidade utilizando as tcnicas certas muitas vezes pode significar terminar o projeto mais cedo ou obter mais resultados em um mesmo perodo [10].

3.3.4 EscopoEscopo tudo aquilo que se deseja que um software faa. Porm o escopo uma varivel de difcil definio. Nem os programadores nem o empresrios tm mais do que uma vaga noo do que valioso no software em desenvolvimento [10]. possvel definir um escopo geral do que se deseja, mas a dificuldade est em definir os detalhes do escopo.

3.3.5 Interaes Entre as VariveisAs quatro variveis interagem entre si, mas no existe uma relao simples entre elas [10]. Ao se alterar uma delas no possvel saber com certeza como as outras se comportaro. A Figura 3.1 representa a ligao entre as quatro variveis. Alguns exemplos dessas interaes so: Investindo mais dinheiro pode-se expandir o escopo; Expandir o escopo, geralmente, significa aumentar o tempo do projeto; Aumentar a qualidade pode diminuir o tempo de entrega. Porm nem sempre possvel ter os resultados esperados apenas alterando uma das variveis. Por exemplo, no se pode diminuir o tempo de entrega do software apenas investindo mais dinheiro.

33

Figura 3.1 - Variveis

3.4

Detalhamento dos Requisitos no Incio do Projeto Versus Detalhamento dos Requisitos Durante o DesenvolvimentoComo vimos no captulo 2.1, nas metodologia tradicionais de desenvolvimento

todos os detalhes dos requisitos so levantados e analisados nas primeiras fases do projeto, deixando a implementao do software somente para depois que essas fases tiverem terminado. Ao iniciar a fase de implementao, todos os requisitos j foram mapeados, analisados e desenhados de forma que a tarefa do programador somente codificar as funcionalidades. O maior problema em relao a esse procedimento est no fato de que mudanas no escopo sempre ocorrem. A nica constante em um projeto de software a mudana [2]. At que todos os requisitos sejam levantados, analisados, detalhados e desenhados alguns meses se passaro, e nenhuma linha de cdigo ter sido escrita ainda. Nesse tempo que passou bem provvel que alguns dos requisitos tenham mudado, o que pode tornar obsoleto parte do trabalho realizado nas fases anteriores. Logo, mudanas em projetos que utilizam metodologias tradicionais de desenvolvimento no so bem-vindas. Portanto, nesses projetos, incertezas quanto aos requisitos sempre existem, por mais que os requisitos sejam analisados. Projetos que utilizam XP como metodologia de desenvolvimento lidam com a mudana de forma diferente. O problema no a mudana por si s, pois ela vai acontecer, mas a falta de habilidade para se lidar com a mudana quando ela chega [10]. Para a metodologia XP, as mudanas so bem-vindas. Como uma exigncia da metodologia XP que o cliente esteja sempre presente durante o desenvolvimento do projeto (captulo 2.2.2.3.2), o detalhamento

34

de cada funcionalidade realizado quando o desenvolvedor inicia sua codificao, tendo o cliente por perto para que os detalhes sejam explicados e as dvidas sejam tiradas. Alm disso, no XP o cliente tem toda a liberdade de escolher as funcionalidades que deseja que sejam desenvolvidas em cada release e mudar a deciso caso seja necessrio. O cliente tambm pode mudar algum detalhe de uma funcionalidade que est sendo desenvolvida ou que j teve seu desenvolvimento concludo.

3.5

Crescimento Exponencial do Custo de Modificao Versus Crescimento Moderado do Custo de Modificao

3.5.1 A Curva de Aumento Exponencial do Custo de ModificaesUm dos pressupostos universais sobre engenharia de software que o custo de modificar um programa aumenta exponencialmente ao longo do tempo [10]. A curva de aumento exponencial do custo de manuteno pode ser visto na Figura 3.2. Em teoria a descoberta de problemas deveria acontecer nas primeiras fases do projeto, o que tornaria barata a resoluo desses problemas: caso o problema seja encontrado somente quando o software estiver em produo, por exemplo, o custo seria centenas ou milhares de vezes mais alto do que se descoberto na fase de anlise [2].

Figura 3.2 Curva de aumento exponencial das modificaes

35

Da mesma forma, a modificao de funcionalidades j desenvolvidas tambm tem um alto custo. Acrescentar um novo campo em um formulrio algum tempo depois dele ter sido desenvolvido, por exemplo, teria um custo exponencialmente mais alto em relao a ter acrescentado esse campo durante o desenvolvimento inicial do formulrio. Geralmente a causa do alto custo das modificaes est na complexidade do design do projeto e na necessidade de se alterar todos os artefatos desenvolvidos nas fases anteriores, sob o risco de desatualizar a documentao. Seguindo essa premissa, as metodologias de desenvolvimento tradicionais procuram formas de resolver todos os problemas relacionados ao desenvolvimento do software o mais cedo possvel. As seguintes prticas so utilizadas pelas metodologias tradicionais para evitar o alto custo de modificaes e correes: Detalhar, analisar e desenhar todo o sistema no incio do projeto, com todos os detalhes possveis; Prever futuras funcionalidades que o sistema venha a ter; Desenvolver funcionalidades genricas, tentando facilitar modificaes futuras, caso venham a ocorrer. O problema com essas prticas que todas se baseiam na tentativa de prever detalhes das funcionalidades, sem ter nenhum feedback se essa previso vlida ou no. Quando se erra em uma dessas previses ocorre exatamente o que se tentou evitar: uma modificao indesejada no software. Mesmo que se consiga mapear todos os detalhes das funcionalidades, esses detalhes representaro a necessidade atual do cliente, e com o passar do tempo essas necessidades certamente iro mudar [2], o que far com que sejam necessrias modificaes no projeto para atender as novas necessidades do cliente.

3.5.2 A Curva de Aumento Moderado do Custo de ModificaesA metodologia XP segue a premissa de que o custo das modificaes aumentam vagarosamente ao longo do tempo [10] e no exponencialmente, o que torna o custo da modificao aceitvel a qualquer momento durante o desenvolvimento do software, e at mesmo depois de finalizado o projeto. A Figura 3.3 apresenta o crescimento moderado do custo das modificaes.

36

Figura 3.3 Curva de aumento moderado das modificaes O baixo custo das modificaes obtido com a metodologia XP atravs da utilizao das prticas apresentadas no captulo 2.2.2.3. possvel e aconselhvel empregar tecnologias que permitam chegar ao baixo custo de modificao do software como, por exemplo, linguagens e banco de dados orientados a objetos, ferramentas e ambientes de desenvolvimento avanados, computadores com maior poder de processamento, entre outros [2][10]. Seguindo essa premissa, no precisamos tentar prever os detalhes de todas as especificaes no incio do projeto. Tambm no precisamos tomar decises importantes antecipadamente, mas deixaramos para tomar essas decises o mais tarde possvel, durante o processo [10]. O baixo custo de manuteno leva os projetos XP a no necessitarem das fases de requisitos, anlise e desenho, e apenas um levantamento inicial dos requisitos realizado. Como as funcionalidades no so detalhadas no incio do projeto, elas so detalhadas somente no momento em que sero codificadas, com o cliente ento detalhando o que precisa (conforme vimos no captulo 2.2.2.3.2). Aps a funcionalidade ter sido entregue, o cliente avalia se realmente atende sua

necessidade, pedindo modificaes caso necessrio. Essa forma de trabalho mantm a garantia de que tudo o que est sendo desenvolvido o que o cliente realmente quer, e caso o cliente encontre algo que precise de alterao, o custo da mesma no ser proibitivo.

37

Outro impacto relacionado s generalizaes comumente feitas no cdigo do software para prepar-lo para possveis futuras mudanas, e com isso tentar reduzir o custo dessas mudanas. Com o baixo custo das mudanas essas generalizaes no so necessrias, logo as prticas do XP induzem o desenvolvedor a manter o design do sistema o mais simples possvel (captulo 2.2.2.3.8).

3.6

Escopo Fixo Versus Escopo VarivelQuando uma empresa pretende desenvolver um software para atender uma

determinada necessidade, o primeiro passo definir as especificaes iniciais para o projeto e informaes adicionais pertinente ao projeto [2]. Ao se definir o escopo, o prximo passo definir o custo do projeto. Assumindo que a empresa contrate uma consultoria para o desenvolvimento, cada consultoria contatada pela empresa enviar um oramento com base nas especificaes fornecidas pela mesma. Porm, desconhecido como o custo do projeto pode ser determinado.

3.6.1 Escopo FixoQuando se utilizam as metodologias tradicionais de desenvolvimento, geralmente o clculo do custo do projeto feito estimando e fixando o esforo necessrio para se desenvolver o projeto com base nas informaes passadas pela empresa, e com base nisso calcula-se o tempo necessrio e o custo. A consultoria tenta prever o grau de dificuldade que o projeto poder ter. Porm o projeto pode se demonstrar mais fcil do que o previsto, o que pode representar maior lucro para a consultoria, ou ento pode ser mais difcil de se implementar, representando prejuzo. Quando a negociao realizada dessa forma, so definidas trs variveis: escopo, tempo e custo. A quarta varivel, qualidade, varia com o andamento do projeto. Caso o projeto seja de fcil implementao e no haja problemas em seu andamento, a consultoria far o possvel para manter a alta qualidade do software. Mas se a implementao for difcil e seu andamento apresentar muitos problemas, o projeto pode sofrer atrasos, extrapolando o tempo definido para o projeto. Neste caso a consultoria poder escolher sacrificar a qualidade do software para minimizar o atraso na entrega.

38

Outro problema que podemos encontrar quando se fixa o escopo de um projeto que, como j foi visto, muito provvel que os requisitos do projeto mudem durante seu desenvolvimento. Com o escopo fixado, caso o cliente queira mudar alguma parte do escopo poder haver algum conflito entre cliente e fornecedor, o que pode prejudicar o projeto sob muitos aspectos.

3.6.2 Escopo VarivelA abordagem que a metodologia XP d para o escopo a de mant-lo varivel, fixando o prazo, o custo e a qualidade. Como foi visto, mudanas so bemvindas no XP, o que permite que se deixe o escopo do projeto aberto para que o cliente decida sobre o que desenvolver somente quando ele precisar de uma determinada funcionalidade. Isso elimina o problema de se tentar prever a dificuldade do projeto. Independente da facilidade de desenvolvimento do projeto, a forma como o planejamento da metodologia XP executado faz com que se mantenha um padro de qualidade, pois no h tanta presso em relao ao tempo, e a qualidade no precisa ser sacrificada em troca de maior velocidade de desenvolvimento. O fato de o escopo no ser fixo no significa que o fornecedor no ir desenvolver todas as funcionalidades que o cliente precisa. Em todo comeo de uma iterao o cliente deve escolher as funcionalidades que deseja que sejam desenvolvidas. A quantidade de funcionalidades varia de acordo com a dificuldade das funcionalidades escolhidas e o tempo disponvel estimado pelos

desenvolvedores (como visto no captulo 2, seo 2.2.2.3.1). No caso de uma desas funcionalidades apresentar uma dificuldade maior do que o previsto e demandar mais tempo de desenvolvimento, no podendo ser concluda na iterao, ela dever ser terminada na prxima iterao. Caso ocorra o contrrio, ou seja, a funcionalidade for mais simples e sobrar tempo na iterao, o cliente poder escolher uma funcionalidade que possa ser desenvolvida no tempo liberado. Como o cliente est presente enquanto a equipe de desenvolvimento estima o tempo disponvel na iterao, essa estimativa tende a ser a mais prxima possvel do real. Sendo assim, a equipe sempre tentar desenvolver o mximo de funcionalidades em uma iterao, respeitando-se a qualidade do software.

39

A metodologia XP tambm leva o cliente a, no ato da escolha das funcionalidades a ser desenvolvidas, escolher sempre aquelas com maior. As funcionalidades com prioridades mais baixas so sempre deixadas para mais tarde, e somente se sobrar tempo do projeto elas sero desenvolvidas. Isso evita que funcionalidades que no tragam valor para os negcios tomem tempo de desenvolvimento da equipe.

3.7

Entrega no Final do Projeto Versus Entregas FrequentesUma empresa investe em um projeto de software visando um retorno desse

investimento atravs de aumento de vendas, melhoria na qualidade de seus produtos, reduo de custos, etc. [2]. O retorno do investimento realizado em um projeto de software s se inicia depois que o software entra produo. A seguir descrito como as metodologias tradicionais de desenvolvimento e a metodologia XP lidam com o retorno de investimento no projeto.

3.7.1 Entrega nicaNas metodologias tradicionais o software todo desenvolvido e testado, e ento entregue ao cliente e posto em produo. O cliente s ir conhecer de fato o software depois que todas as funcionalidades foram desenvolvidas. Isso significa que o cliente no ter os benefcios que se deseja do software durante todo o tempo de desenvolvimento do projeto. O retorno de investimento s vir aps o sistema entrar em produo, como mostra a Figura 3.4. Levar mais tempo para o cliente obter o retorno sobre o investimento realizado no projeto, e em alguns casos funcionalidades podem at mesmo j estar obsoletas antes mesmo de entrar em produo. Isso representa um menor retorno do investimento realizado no projeto.

40

Figura 3.4 Retorno de investimento em metodologias tradicionais de desenvolvimento

3.7.2 Entregas FrequentesComo vimos no captulo 2, os projetos XP so divididos em diversos releases e ao final de cada um deles entregue e posto em produo um conjunto de funcionalidades. A prtica de releases curtos do XP foi pensada visando que o cliente obtenha o retorno de investimento o mais rpido possvel aps o incio do projeto, e que esse retorno de investimento aumente a cada nova entrega de funcionalidades do software. Projetos utilizando a metodologia de desenvolvimento XP obtm um retorno de investimento muito mais rpido do que projetos que utilizam metodologias tradicionais de desenvolvimento. A Figura 3.5 mostra como acontece o retorno de investimento em projetos de software que utilizam o XP como metodologia de desenvolvimento de software.

41

Figura 3.5 Retorno de investimento com a metodologia de desenvolvimento XP

42

4

Consideraes FinaisH muito mais pontos de diferenas entre as metodologias tradicionais de

desenvolvimento e a metodologia de desenvolvimento gil XP. Este trabalho abordou as diferenas mais importantes que podem levar escolha de uma ou de outra. Embora XP ainda seja uma metodologia relativamente nova e pouco utilizada, h muitos casos de sucesso que demonstram que, utilizando a metodologia de desenvolvimento XP, possvel administrar um projeto de desenvolvimento de software que no exceda o oramento, no atrase, tenha um tempo de desenvolvimento relativamente baixo e acima de tudo tenha uma qualidade alta. Por outro lado as metodologias tradicionais ainda so muito utilizadas, e continuaro sendo utilizadas por muito tempo. Embora tenham suas falhas, muitos projetos que as utilizam correm sem atrasos, dentro do oramento e com alta qualidade. A deciso de qual das metodologias utilizar deve ser muito bem ponderada, e feita com base no conhecimento que se tem de cada uma. Alguns projetos e equipes de desenvolvimento podem ser administrados de melhor forma com metodologias tradicionais, outros podem fazer melhor uso das prtica da metodologia XP, o que depende de vrios fatores, que incluem desde o tipo de projeto, a cultura da empresa e at a motivao dos membros das equipes em utilizar determinada metodologia.

4.1

ConclusoNeste trabalho foram apresentadas as metodologias tradicionais de

desenvolvimento e a metodologia gil XP e suas principais caractersticas. Aps a abordagem das metodologias, apresentou-se uma comparao entre os pontos onde as metodologias mais se diferem e que podem ter maior impacto sobre os projetos de software. O estudo foi realizado atravs de consultas a livros e sites da Internet, buscando informaes de profissionais experientes na rea de

desenvolvimento de software. Este estudo encontra-se sumarizado no captulo 3.

43

Metodologias geis de desenvolvimento, sobretudo a metodologia XP, esto em ascenso. A cada dia que passa mais projetos fazem uso dessas novas metodologias. A princpio a metodologia XP pode parecer complicada, com muitas regras, e exigir muita dedicao dos profissionais que o utilizam, porm pode tornar o trabalho de desenvolvimento mais produtivo, mais valioso e at mesmo mais divertido com a utilizao de suas prticas. As vantagens da utilizao da metodologia XP so visveis tanto para a equipe de desenvolvimento quanto para a rea de negcios da empresa. Os ganhos vo desde as entregas frequentes de funcionalidades, que comeam em cerca de dois meses de projeto e garantem um retorno de investimento mais rpido, at a alta qualidade do software, obtida principalmente com as prticas de desenvolvimento guiado por testes, design simples, refatorao e integrao contnua. Mas para se adotar o XP necessrio que o cliente esteja disposto a deixar algum sempre presente com a equipe de desenvolvimento, o que em algumas empresas um fator invivel. Sem o cliente presente a metodologia XP deixa de ser vivel, pois dificultar prticas como o Jogo do Planejamento e os Testes de Aceitao, alm de dificultar a comunicao, sobretudo no que se refere ao feedback. A metodologia XP tambm exige que a equipe de desenvolvimento seja, sobretudo, muito disciplinada, para que prticas como desenvolvimento guiado por testes e refatorao sejam utilizadas corretamente e em todo o tempo de projeto.

4.2

Melhorias FuturasFuturas melhorias para este trabalho devem incluir: uma pesquisa mais

abrangente sobre os pontos fortes e fracos tanto das metodologias tradicionais quanto das metodologias geis; as desvantagens da metodologia XP; estudo de caso de empresas que trocaram as metodologias tradicionais pelas metodologias geis; um roteiro de adoo da metodologia XP sugerindo por onde comear a adoo; incluso da metodologia gil Scrum na comparao, cuja adoo vem aumentando nos ltimos anos.

44

Referncias[1] The Standish Group International: Estados Unidos. Site da empresa The Standish Group International. Disponvel em . Acesso em [2] TELES, Vinicius Manhes. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. Rio de Janeiro: Novatec Editora, 2004. [3] REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Brasil: Brasport, 2006. [4] Paula Filho, Wilson de Pdua. Engenharia de Software: Fundamentos, Mtodos e Padres. Rio de Janeiro: LTC, 2009. [5] Managing the Development of Large Software Systems: Concepts and Techniques. Dr. Winston W. Royce. Disponvel em

. Acessado em 27/09/2010. [6] FAVRE, Liliana. UML and the Unified Process. Estados Unidos: IRM Press, 2003. [7] FOWLER, Martin. UML essencial: um breve guia para a linguagem-padro de modelagem de objetos. Estados Unidos: Bookman, 2005. [8] A nova Metodologia. Estados Unidos. Artigo escrito por Martin Fowler sobre a criao das metodologias geis. Disponvel em nova-metodologia/>. Acesso em: 04/10/2010. [9] Agile Manifesto. Estados Unidos. Site do Manifesto para o Desenvolvimento gil de Software. Disponvel em . Acesso em: