1. Introdução

O objetivo desta parte teórica é o de analisar conceitualmente duas formas de produção de softwares, ou seja, a produção de softwares através da técnica denominada Engenharia de Software clássica e a denominada Programação Xp. Durante a exposição serão definidos e apresentados os pontos positivos e negativos de cada uma delas.

Com o fim de facilitar o entendimento e a abordagem desta monografia, principalmente para aqueles leitores não familiarizados com a terminologia técnica de computação, é importante ter alguns conhecimentos prévios de nomenclatura e de conceitos que serão apresentados a seguir:

- Software: Uma seqüência de comandos definidos por uma linguagem de programação, que o computador é capaz de processar e com ela gerar algum tipo de resultado [5]. Normalmente um software tem como objetivo básico, automatizar uma função repetitiva, até então desenvolvida de forma manual, semi-automatizada ou mal automatizada. O software é, portanto, algo lógico, abstrato e não físico como o computador.

- Engenharia de Software: Um conjunto de etapas e ações necessárias para se produzir um software que funcione adequadamente. Assim como na construção de um prédio, antes do início da execução de sua construção, os engenheiros precisam analisar a área, o tipo do terreno, o dimensionamento das estruturas, o formato, além de outros detalhes, para depois poder construí-lo, na construção de um software também é necessário coletar uma série de informações para projetá-lo e depois desenvolvê-lo de forma a atender plenamente os requisitos para o qual foi idealizado. Em simples palavras, há que se seguir uma seqüência de atividades – uma “receita de bolo” - para ter sucesso no desenvolvimento de um software e chegar aos resultados esperados.

2. Engenharia de Software Clássica

     2.1. Histórico

Em meados dos anos 40 e 50, com o grande avanço dos computadores, engenheiros de todas as áreas da engenharia começaram a trabalhar também com programação de softwares e aos poucos passaram a utilizar metodologias de engenharia para produzi-los. Naquela época, praticamente não havia softwares prontos para serem comprados e com o qual se poderiam executar as ações desejadas, como, por exemplo, fazer os cálculo estrutural para o dimensionamento das vigas e das lajes de um prédio. Desta forma havia a necessidade de se desenvolver um software para atender a este requisito.

     2.2. Modelo de produção de software em cascata
 
Um dos modelos de desenvolvimento de software através da Engenharia de Software clássica é o de produção em cascata. Trata-se do modelo mais usado até os dias de hoje para a produção de software, conhecido também como “modelo clássico de produção de software”. Foi sugerido por Winston Royce na década de 70 [1].

Nos últimos anos, grupos de programadores uniram-se e começaram a rebater esse modelo criando métodos alternativos de desenvolvimento, como a Programação Xp que será objeto de discussão deste trabalho de conclusão.

Abaixo um esquema mostrando as etapas do modelo de produção em cascata:

Como anteriormente descrito, o modelo em cascata teve origem na engenharia tradicional e como se pode observar pelo esquema acima, divide-se nas seguintes fases [1],[5],[9],[13]:

1. Levantamento de Requisitos
2. Análise de Requisitos
3. Projeto
4. Implementação
5. Testes
6. Manutenção

A figura representa o modelo em cascata de forma seqüencial. O modelo mostra que o processo de produção inicia-se com o levantamento de requisitos, passando pelas diversas etapas até culminar na fase de manutenção. No gráfico pode-se também observar atividades em ordem reversa, mas estas não necessariamente ocorrem em ordem seqüencial, mostrando que qualquer etapa subseqüente pode influenciar o resultado de uma etapa anterior, a qual deve ser refeita ou ajustada, o que representa as possíveis alterações que podem ser necessárias durante um projeto e produção de um software.

Apesar do modelo apresentado possibilitar uma volta às etapas anteriores, na prática, o que sucede é a utilização quase que estritamente do modelo em cascata na forma seqüencial do topo até a base. Desta forma, o modelo de Royce propõe a finalização das fases para continuação do projeto, ou seja, é necessário terminar uma fase para seguir para outra fase.

A seguir discute-se, em detalhes, cada uma das etapas do modelo de produção em cascata.

     2.2.1. Levantamento de Requisitos

Levantamento de requisitos é o primeiro passo para o desenvolvimento do software. Como bem diz o nome, esta fase tem como objetivo levantar informações para definir o que o software deverá fazer quando implementado. Por meio de entrevistas e acompanhamento do dia-a-dia dos usuários do sistema busca-se coletar informações que serão utilizadas para modelar o software.

Deve-se sempre levar em consideração que não existe nenhum método de levantamento de requisitos que garanta que o desenvolvimento do software será perfeito. O que sim existe são metodologias e profissionais especializados na coleta de dados que otimizam a captação de informações e com isso minimizam os desvios no projeto. Esta é uma fase muito importante no desenvolvimento do software, pois uma coleta dos requisitos mal efetuada pode resultar em um software que não cumpre com as necessidades requeridas. Por outro lado, uma coleta de informações bem executada, junto com uma boa análise, são fatores chaves para que a modelagem das funcionalidades do software atenda o almejado pelo cliente.

Segundo pesquisa do Standish Group [2] como mostra a tabela abaixo, aproximadamente 25% das falhas nos projetos provêm diretamente de erros gerados na fase de levantamento de requisitos, onde o usuário não especifica direito os requisitos (12.8%) somado com uma especificação incompleta de requisitos por parte do desenvolvedor de software (12.3%).

Já nas pesquisas realizadas nos projetos das forças aéreas americanas [3], mostram que 41% dos erros em projetos ocorrem devido a erros de requisitos na especificação do software, como mostra o gráfico abaixo:

Estas e outras estatísticas apenas confirmam que uma grande porcentagem dos erros nos projetos de produção de software estão relacionados com o levantamento dos requisitos. Ou seja, é necessário ter muito cuidado e carinho no levantamento de requisitos, já que é a partir deles que serão feitas todas as análises e definições das funcionalidades do software.

     2.2.2. Análise de Requisitos

Análise de requisitos é a documentação de todos os requisitos levantados durante a fase de exploração na empresa. De forma sistemática descreve-se quais funcionalidades e restrições o software deve ser projetado. Esse documento, que de modo geral, é constituído por diversas folhas de papel, servirá de base para conversas entre os programadores e os projetistas e estes com o cliente. A partir desta análise objetiva-se gerar o software esperado pelo cliente.

Os requisitos são divididos em dois grandes grupos: requisitos funcionais e requisitos não-funcionais.

     2.2.2.1 Requisitos funcionais

Requisitos funcionais são as funcionalidades de um software, não fazendo parte da análise se o software será programado com a linguagem A ou B e se a funcionalidade X será feita de um modo otimizado ou não. Por exemplo, em um sistema de automatização de loja, os seguintes requisitos são funcionais:

   1. Ao final de cada compra, o sistema deve imprimir um cupom fiscal;
   2. Se um produto não existe na base de dados do estoque, dar uma notificação ao operador;
   3. Se o produto passou da data de validade, enviar um e-mail ao funcionário responsável.

     2.2.2.2 Requisitos não-funcionais

Os requisitos não-funcionais descrevem o sistema como um todo, de modo a restringi-lo a um determinado domínio, domínio este formado pelas restrições impostas ao sistema, como por exemplo:

   1. O sistema deve ter um tempo de resposta rápido para não deixar o usuário impaciente;
   2. O sistema pode ser utilizado em qualquer sistema operacional;
   3. O sistema precisa ter a opção de fazer backup para, em caso de perda dados, não se perder todo o seu conteúdo.

Confiabilidade, eficiência e portabilidade do software fazem parte de requisitos não-funcionais.

   2.2.3. Projeto

Com o sistema todo documentado, o modelo de produção em cascata propõe a passagem para fase de projeto. Nesta fase começa-se a trabalhar com modelos mais próximos da implementação do software. A estrutura de dados adequada para o software em questão é definida nesta fase e a interface do sistema (parte do software através da qual o usuário tem acesso às funcionalidades do sistema) é discutida nesta etapa do processo. Por exemplo, qual será o formato da apresentação das funcionalidades do software na tela para facilitar o uso do usuário, que tipos de recursos multimídias estarão disponíveis. As definições de cores e fontes de texto também podem ser definidas nesta etapa.

Quando os sistemas são muito abrangentes é necessário fazer a divisão em módulos; neste caso, também define-se nesta fase quais módulos serão necessários para compor o sistema.  

   2.2.4. Implementação

Todos os esforços das fases anteriores do modelo de produção em cascata foram feitos para se chegar a esta fase de implementação. O objetivo final de toda a Engenharia de Software clássica é desenvolver um programa ou sistema de programas que funcione adequadamente e atenda as necessidades especificadas pelo cliente; logo, com simples palavras, a fase de implementação pode ser definida como o processo de programar as funcionalidades do software.

O computador não consegue interpretar casos de uso, diagramas de classes e outros detalhes da especificação do software, o que sim pode interpretar é uma codificação feita em alguma linguagem de programação.

Os documentos com os detalhes do software começam a ser transformados em muitas linhas de códigos, às vezes até milhões delas, e após um determinado prazo de tempo o resultado será um software executando rotinas sobre o hardware do computador.

Existem muitos modelos prontos que facilitam a implementação do software, como por exemplo, os frameworks. Os frameworks contém estruturas que podem ser utilizadas para diversos tipos de aplicações, implicando na diminuição do trabalho de codificação de um software. Outra explicação de framework é “prover uma solução para uma família de problemas semelhantes” (A framework is a set of classes that embodies an abstract design for solutions to a family of related problems) [4].

Além dos modelos que facilitam o desenvolvimento, também existem métodos para agilizar a programação.

A fase de implementação termina quando toda a especificação foi cumprida. Mas isso por si só, não é uma garantia completa e nem exclui a possibilidade do aparecimento de erros durante a fase de testes do software.

   2.2.5. Testes

Na fase de testes busca-se justamente garantir a integridade do software. Dada uma entrada (input), o programa deve gerar um resultado esperado (output) ou reagir de forma esperada.

Durante o processo de produção de software, diversos fatores como prazos para sua entrega, gasto de tempo excessivo em determinada funcionalidade, etc., fazem com que os programadores não tenham atenção absoluta no desenvolvimento do software. Assim, se explica porque em geral surgem erros, que podem passar despercebidos.

Esta fase é importantíssima em sistemas de risco, como softwares de piloto automático em aviões, controle de tráfego aéreo, lançamento de foguetes; caso erros não sejam percebidos, vidas podem estar em risco.

Existem diversos tipos de testes, tais como testes de interface, testes de módulos e testes de lógica [1], [5]. Dependendo do tipo de software em questão, cria-se um modelo de testes específico para a avaliação e detecção de um problema potencial.

Mesmo quando se localiza um determinado erro, sua correção pode não ser fácil, podendo ser necessário refazer todo o software ou não se encontrar soluções a curto ou médio prazo. Apesar de não ser fácil encontrar erros, já que nem sempre são óbvios e podem surgir em situações adversas e em tempos aleatórios, existem técnicas para auxiliar nos testes. Um exemplo de erro que ocorreu aleatoriamente e de forma inesperada que ficou muito conhecido foi durante o lançamento da versão beta do Windows 98 diante de diversos jornalistas. No momento em que o Bill Gates ligou o computador pela primeira vez, apareceu uma tela azul e foi necessário reiniciar o computador; mas na segunda tentativa, a apresentação do Windows ocorreu tranqüilamente.

   2.2.5.1. Técnicas de Teste

Entre as técnicas mais explorados no mercado de software, encontram-se: caixa-preta, caixa-branca, caixa-cinza, dentre outras. [5]
 
Caixa-preta: São testes onde não se tem acesso ao código fonte. São executados na interface do software e utilizados para verificar se as funcionalidades estão gerando os resultados esperados. Por exemplo, se um botão virtual for ativado, o teste verifica se o sistema executa corretamente o comando relacionado ao botão ou não. Neste exemplo, o botão é a interface do software.

Caixa-branca: Atua diretamente no código fonte do software. Testa as escolhas lógicas (if, else, case), os laços (while, for) e as demais estruturas lógicas do código.

Caixa-cinza: é uma mescla dos testes caixa-preta com o caixa-branca, podendo-se ter acesso restrito a certas partes do código, ao mesmo tempo que se tem liberdade de explorar a interface.

Além das técnicas para testes de software, o mercado desenvolveu testes automatizados, que agilizam a depuração do software. Um exemplo de teste automatizado é um gerador de entradas do tipo que o programa espera receber do usuário, e posterior análise dos resultados gerados, informando se o software está ou não respondendo de forma esperada.

   2.2.6. Manutenção

A fase de Manutenção começa após a entrega do software para o cliente, ou seja, quando o software entra finalmente em uso. É normal que, após utilizar o software, o cliente surja com novas idéias de funcionalidades até então não implementadas ou não pensadas. Com isso, o desenvolvedor precisa prover essas novas funcionalidades para o cliente alterando o código inicial. Além disso, podem ter sobrado erros desapercebidos na programação, pode ter ocorrido mudanças das regras do negócio, etc.

Desta forma, a fase de manutenção cuida dos seguintes casos:

   - Erros que não foram corrigidos na fase anterior e acabam surgindo após a entrega do produto.
   - Insatisfação do cliente com o desempenho, talvez devido à demanda do uso, consumo exagerado da capacidade de processamento da máquina, entre outros, sendo necessário uma otimização do software.
   - Com o surgimento de novas tecnologias e o passar do tempo, funcionalidades do software podem ficar obsoletas, sendo necessário refazer o código.

Em resumo, ajustes de erros, otimizações e necessidades de se refazer o software fazem parte desta fase de manutenção.

Pesquisas feitas pela GTE, TRW e IBM revelam os custos gerados com os erros que ocorrem durante as diversas fases do projeto, representados na figura abaixo [6].

O que chama atenção é a base da pirâmide, mostrando que erros identificados na fase de manutenção do projeto tem um custo 20 vezes maior caso fossem identificados na fase de levantamento e análise de requisitos.

Logo, o sucesso desta fase é inversamente proporcional à qualidade das fases anteriores. Se as fases anteriores foram cuidadosamente executadas e bem sucedidas, a parte de manutenção do software, relacionada aos erros e otimizações das funcionalidades desenvolvidas, será quase nula. Caso contrário, será um trabalho árduo e caro. Em particular, a documentação do sistema deve ser muito bem feita, pois sua falta pode quase que impossibilitar a manutenção, encarecendo-o decisivamente.

3. Programação Extrema (Xp)

   3.1. Histórico

A Programação Xp faz parte dos métodos conhecidos como “métodos ágeis” [1]  e que tem se apresentado como uma alternativa válida ao método de Engenharia de Software clássica no desenvolvimento de software.

Existem outros modelos de desenvolvimento de software pertencentes ao grupo de métodos ágeis, como Scrum [1], Crystal [1], Adaptive Software Development [1] e Feature Driven Development [1], mas neste trabalho de conclusão vamos analisar somente a metodologia Xp.

No início dos anos 90, em virtude da explosão da Internet e o surgimento das linguagens orientadas a objetos, Kent Beck, um dos fundadores da Programação Xp, assim como outros programadores experientes, sentiram a necessidade de criar metodologias mais modernas para o desenvolvimento rápido e eficiente de softwares [1].

Com um espírito inovador e portanto na busca incessante de geração de novas idéias, esse grupo se opôs às regras dos procedimentos clássicos predominantes no mercado desenvolvedor de softwares, tais como: pouca iteração desenvolvedor-cliente, documentos e processos rígidos e burocráticos, muitos erros de código e pouca flexibilidade. [1]

Nos dias 11 a 13 de fevereiro de 2001 ocorreu em Utah “The Agile Manifesto”, o (“Manifesto Ágil”), realizado por um grupo de 17 desenvolvedores de software, dentre eles, Kent Beck, para discutir alternativas aos modelos vigentes de desenvolvimento de softwares [8].

O manifesto contém quatro princípios:
     1. Individuals and interactions over processes and tools - Indivíduos e interações são mais importantes que processos e ferramentas.
     2. Working software over comprehensive documentation - Software funcionando é mais importante do que documentação extensa.
     3. Customer collaboration over contract negotiation - Colaboração com o cliente é mais importante do que negociação de contratos.
     4. Responding to change over following a plan - Resposta a mudanças é mais importante que seguir o plano original.

     3.2. Motivações

O gráfico [11] abaixo mostra no modelo tradicional de produção de software, apresentado acima como a Engenharia de Software clássica, o custo de alterações do software por tempo de desenvolvimento:

Já a Xp por meio de uma nova fórmula de desenvolvimento de software, baseada nas suas três regras - valores, práticas e princípios (explicados abaixo) - gera o gráfico [11] abaixo mostrando o custo das alterações no decorrer do tempo:

 

Estes resultados de custos extremamente menores com o uso da Programação Xp quando comparado ao método da Engenharia de Software clássica somente são possíveis graças às novas linguagens orientadas a objetos, que facilitam as mudanças e a reutilização de código, bem como a experiência adquirida nos últimos 50 anos no desenvolvimento de software, além de técnicas para testar o software cada vez melhores e mais eficientes.

Logo, hoje, o modelo de Programação Xp pode deixar de ser um mito para ser a nova realidade em produção de softwares. [11]

   3.3. As 3 regras da Programação Xp

Como mencionamos acima, são três as regras que precisam ser respeitadas em um projeto utilizando a metodologia de Programação Xp, ou seja: valores, práticas e princípios.

   3.3.1. Valores

São cinco os valores da Programação Xp:
     - simplicidade
     - feedback
     - comunicação
     - coragem
     - respeito.

   3.3.1.1. Simplicidade

Ao invés de se preocupar com requisitos que podem ser necessários no futuro, a Programação Xp sugere se pensar nesses detalhes só quando aparecer esta necessidade. Assim, não gasta-se tempo em nada que não seja necessário no momento. Os programadores devem programar o que o cliente necessita no presente.

   3.3.1.2. Feedback

Em Programação Xp, o cliente, além de ter a importância financeira, uma vez que sustenta o projeto, também é um agente ativo no seu desenvolvimento. Desta maneira, quanto mais próximo o cliente está do desenvolvimento, acompanhando as versões quase que semanais do software e podendo usá-las e testá-las, mais fáceis e rápidas são as resoluções das dúvidas dos desenvolvedores e mais cedo descobrem-se os erros.

Do lado do cliente, este tem confiança no projeto, uma vez que interage constantemente com os releases e com os desenvolvedores participando ativamente do andamento do software. Do lado dos desenvolvedores, estes têm um feedback quase que instantâneo sobre o funcionamento do programa, ao escrever e executar os testes automatizados.

Assim sendo, por meio de feedbacks rápidos as duas partes interessadas no projeto obtém vantagens, vantagens estas que não existiam nos modelos anteriores de desenvolvimento de softwares.

   3.3.1.3. Comunicação

Um cliente normalmente não entende absolutamente nada ou entende muito pouco de desenvolvimento de software. Está tão acostumado com as facilidades que o mundo eletrônico possibilita que acaba pensando que tudo se faz em um clique de mouse, em segundos. Assim, pensa que as funcionalidades mais complexas podem ser desenvolvidas facilmente.

Para resolver esse e outros problemas, quanto mais ativa for a comunicação dos desenvolvedores com o cliente, mais fácil será o diálogo entre ambas as partes e melhores benefícios as partes sentirão. O benefício do desenvolvedor é entender cada vez mais rápido, as dúvidas e necessidades do cliente, além de esclarecer ao cliente, os pontos de entendimentos ainda não muito claros, possibilitando um direcionamento do desenvolvimento do software praticamente como a vontade exata do cliente. Em Programação Xp, quanto mais interação pessoal e quanto menos por meio de documentação, melhores serão os resultados obtidos. [11]

   3.3.1.4. Coragem

Os programadores que estão em uma equipe que está utilizando a Programação Xp não devem ter medo de enfrentar novas idéias e desafios por parte dos clientes. Precisam aceitar com coragem as retificações e continuar programando mesmo que o trabalho possa ser mais árduo em relação ao proposto originalmente. Se for necessário refazer todo o código ou descartá-lo completamente, torna-se necessário coragem e mãos à obra para realizá-los. [11]

As regras estabelecidas pela Programação Xp foram criadas para motivar os programadores a enfrentarem os novos desafios. Como acontece algumas vezes, a empresa decide mudar a tecnologia do projeto, mesmo depois de seu início, logo, erros e mudanças podem acontecer e a equipe precisa estar preparada para estas surpresas e atuar o mais rápido possível na adequação do projeto.

   3.3.1.5. Respeito

Quando se programa em pares, é normal que apareçam divergências entre as pessoas com relação à melhor forma de programar uma determinada função. Nesses momentos, cada membro do par precisa respeitar o outro e juntos pensarem qual a melhor solução, deixando de lado as vontades e vaidades individuais e aceitando as idéias do companheiro.

Com relação aos demais membros da equipe, como o Coach e o Tracker , a equipe também precisa estar preparada para ser cobrada em relação aos prazos e receber chamadas de atenção por parte do Coach em caso de necessidade.

   3.3.2. Práticas

Existem doze práticas em Xp, que serão explicadas detalhadamente a seguir.[5], [11], [13], [17], [20]

   3.3.2.1 Planejamento

Reuniões semanais entre desenvolvedores e cliente devem ocorrem para estabelecer que funcionalidades devem ser implementadas durante a próxima semana. Os programadores escutam as necessidades do cliente, analisam o lado técnico e entram em acordo a respeito do que será feito durante a próxima semana, de modo a produzir o máximo possível, sem abrir mão da qualidade do projeto.

Depois de uma semana, acontece uma outra reunião para o cliente avaliar o que foi desenvolvido, podendo-se testar a versão do software incrementada em relação a última semana. Novamente programadores e clientes conversam para definir as metas para a próxima semana, e assim sucessivamente até o final do projeto.

Em Programação Xp, essas reuniões semanais recebem o nome de “planejamento”, uma vez que se planejam os detalhes do desenvolvimento do software.

    3.3.2.2 Releases pequenos

O software é desenvolvido de forma incremental, possibilitando que em períodos curtos de tempo sejam acrescentadas novas funcionalidades, que serão disponibilizadas para o cliente quase que semanalmente. Dessa forma, erros são logo detectados pelo cliente e podem ser consertados rapidamente pelos programadores.

Funcionalidades desenvolvidas não da forma pensada pelo cliente não correm risco de serem programadas durante um longo período de tempo até que sua inadequação seja descoberta, pois ao utilizar a pequena versão já pronta, o cliente comunica o fato imediatamente aos programadores que, por sua vez, fazem os ajustes necessários.

Se forem somados todos os minutos ganhos com essas pequenas versões, no final do projeto, a fase de manutenção tende a ser muito curta.

   3.3.2.3 Metáfora

Como a Programação Xp trabalha com uma equipe de programadores em conjunto com o cliente, muitas vezes existem dificuldades de comunicação entre as partes. “Metáfora” em Programação Xp é a criação de uma linguagem padrão para todos conversarem a mesma língua, facilitando o entendimento.

A metáfora pode ser exemplificada com a criação de um exemplo que compara o software com algum processo natural para o cliente. Se o cliente é um médico, busca-se explicar as funcionalidades como partes do corpo, e assim por diante, criando-se analogias que facilitam o entendimento.

   3.3.2.4 Design Simples

Como mencionado anteriormente, a Programação Xp trabalha com fases incrementais do software para facilitar a inclusão de novas funcionalidades. É necessário prover um projeto com o menor número de classes e métodos, com códigos simples e claros além de fácil implementação e de fácil alteração, sem se preocupar se a classe ou o método implementado atenderá as necessidades futuras do projeto.

O leitor pode pensar que essa estratégia é muito perigosa, já que se preocupa com o presente e funcionalidades futuras não são levadas em consideração para tomadas de decisões [1], mas as técnicas usadas em Xp foram desenvolvidas de modo que esse risco seja minimizado.

   3.3.2.5 Testes

Algo muito comum em desenvolvimento de software são erros que surgem no decorrer do projeto. O ideal seria que tudo fosse perfeito, ou seja, dada uma certa entrada de dados no computador, o algoritmo implementado gera o resultado esperado. Como não vivemos num mundo perfeito, os programadores são seres humanos e também podem cometer erros. Assim, a Xp propõe a utilização de testes automatizados para avaliar as funcionalidades do software.

Antes de criar uma funcionalidade nova é recomendável criar um teste específico para o método a ser implementado. No entanto, caso ele seja muito simples, não se deve perder tempo com isso. O teste deve receber entrada de dados do tipo que o método receberá na prática e gerar os resultados (sem nenhum cálculo, por exemplo). Se o teste foi executado de forma satisfatória, inicia-se a programação da nova funcionalidade.

Os principais tipos de testes realizados em Xp são os testes de unidade e de aceitação. O teste de unidade é o teste que verifica se os resultados gerados são os esperados. O teste de aceitação verifica a interação entre todas as partes necessárias para que certa funcionalidade funcione.

   3.3.2.6 Refazer o sistema

Ordenar uma estante de livros é algo muito simples, mas com o passar do tempo, se o número de livros aumenta muito, a arrumação vai ficando mais complexa, pois livros de diferentes coleções acabam misturados e começa a ficar difícil encontrar um livro entre os muitos guardados. A solução é reorganizar tudo de novo.

O exemplo acima ilustra uma situação semelhante ao código do software. Com o passar do tempo, novas funcionalidades foram implementadas, alterações necessárias foram feitas e os códigos que antes eram claros para todos os programadores passam a ficar sem sentido e difícil de serem entendidos. Nesse momento é preciso parar o que está sendo feito e dedicar algum tempo para refazer os códigos antigos. Assim, o código como um todo continuará claro, fácil de alterar e de entender, garantindo um futuro mais tranqüilo aos desenvolvedores.

   3.3.2.7 Programação Pareada

Todo código em Programação Xp precisa ser desenvolvido através do trabalho de programadores em dupla. Uma pessoa programa e o seu par acompanha tudo ao seu lado, para corrigir eventuais erros, discutir melhores soluções e manter o programador concentrado no que está fazendo.

Apesar dessa revolução de programar-se em pares, causada pela Xp, que gerou e continua gerando muitas discussões sobre suas vantagens e desvantagens, a prática mostra que duas cabeças pensam melhor que uma e assim, assume-se que o código desenvolvido em duplas tem menos erros em relação ao desenvolvido individualmente, que a concentração do programador é muito maior quando há alguém ao seu lado olhando tudo o que está sendo feito, evitando que o primeiro se distraia com atividades não relacionadas ao projeto, etc. Assim, a qualidade do software final é muito superior, diminuindo eventuais gastos com otimizações e com manutenção [1]. Fora isso, é comum que uma dupla não fique junta por mais de uma ou duas semanas, existindo uma troca saudável de pares, de modo que todos possam adquirir conhecimento de todas as partes do software.

   3.3.2.8 Propriedade coletiva do código fonte

No modo tradicional de desenvolvimento de software, divide-se o sistema em módulos que são passados para equipes de programadores diferentes. Ao final, ocorre a integração de todos os módulos, de modo que uma equipe não tenha acesso ao código das demais. A Programação Xp propõe que todos os programadores conheçam o código, podendo alterá-lo em caso de necessidade, sem burocracia no aguardo da autorização do autor do código original e/ou da outra equipe.

Essa técnica evita que se gastem horas para compreender e buscar o erro, além de possibilitar que as melhores soluções sejam adotadas. Como cada programador entende o que foi feito, pode ter uma solução melhor, alterando rapidamente o código, agregando  melhoria ao software. E para que todos os programadores tenham acesso a todos os códigos, costuma-se utilizar, o “CVS” que controla todas as versões do software e mantém a mais atualizada.

   3.3.2.9 Cliente ativo

Um ditado popular diz que o gado engorda com os olhos do dono. Em Xp, ao invés de gado, temos o software. Com o cliente ativo acompanhando as pequenas versões do software evita-se que funcionalidades sejam criadas em períodos longos de tempo, sem a real necessidade desta ocorrência, conseguindo-se assim que erros sejam logo detectados e possibilitando uma maior eficiência no seu desenvolvimento.

Quando a Xp trata do tema “cliente ativo”, não é uma exigência fazê-lo ficar ao lado dos desenvolvedores o dia inteiro, o que seria um exagero, já que ele precisa trabalhar no seu negócio. Cliente ativo em Xp significa que quanto maior for o contato desenvolvedor-cliente, mais chances o projeto tem de ser concluído da forma mais correta e mais rapidamente.

Após a equipe ter implementado uma certa funcionalidade, ocorre um feedback rápido do cliente, posicionando se esta ou não de acordo com o que ele pretendia do software. Com isso, agiliza-se o desenvolvimento das demais funcionalidades e, se houver necessidade, fazem-se ajustes imediatos do que já foi desenvolvido.

Não necessariamente é o cliente ou um funcionário da empresa que ocupa a posição de cliente ativo; uma pessoa que tenha pleno domínio da necessidade do cliente também pode assumir esse papel.

   3.3.2.10 Padrão de codificação

Os programadores podem conversar uns com os outros para esclarecerem suas dúvidas e para entenderem alguma parte do código. É interessante notar que o código por si só também é um meio de comunicação entre a equipe [11]. Isso é obtido por meio de padrões na programação definidos pela equipe desde do início, usando-se o código como meio de comunicação, facilitando assim o entendimento. Apesar de normalmente, já existirem padrões de programação relacionado à linguagem usada, impor essa regra força a todos programarem com o padrão especificado. Por exemplo, um padrão de programação utilizando Java, exige que o nome do pacote (package) seja do formato: nomeDoPacote, ou seja, inicia-se com letra minúscula (‘n’) e a cada nova palavra inicia-se com letra maiúscula (‘D’,’P’).

Se houver a necessidade de criar novos padrões, é preciso ter um consenso de todos os integrantes, o que implica em terem conhecimento harmônico do que esta sendo desenvolvido pelos mesmos. É fundamental que haja um comprometimento generalizado de uso dos novos padrões. Assim, o padrão de codificação ajuda a deixar o código de forma que todos possam entendê-lo com facilidade.
 
   3.3.2.11 Integração contínua

A maior parte do mercado desenvolve software em módulos e utilizam métodos para fazer a integração destes assim que concluídos. Apesar de todos os esforços, erros acontecem quando se juntam todas as partes dos diferentes módulos, podendo-se gastar muito tempo e muito dinheiro para colocar tudo em sincronia.

Xp utiliza uma técnica de integração contínua, que propõe aos programadores fazerem a sincronização do código com as demais partes que estão sendo desenvolvidos por outras duplas quase que diariamente e, muitas vezes durante um mesmo dia. Assim, os conflitos de integração podem ser facilmente verificados e solucionados aos poucos. Uma integração após muitos dias implicaria num acúmulo de problemas de integração, o que tornaria o trabalho muito mais difícil.

   3.3.2.12 Semana de 40 horas

Conta-se a história de um feitor de escravos, que fazia seus escravos trabalharem vinte horas por dia, produzindo em média cada um uma quantidade X de tijolos diariamente. O filho desse feitor era muito astuto e aconselhou seu pai que, ao invés de fazer os escravos trabalharem vinte horas e só dormirem quatro, que trabalhassem somente dez horas e o resto do dia poderiam passear, com a condição que dormissem pelo menos oito horas diárias. O feitor sabia que o filho era muito astuto e fez um teste, resultando que no final do dia, cada escravo produzia duas vezes (2X) mais tijolos.

Esse exemplo mostra uma realidade em empresas que desenvolvem software. Próximo da data da entrega do projeto, uma vez que sua finalização está, geralmente, longe da data planejada, programadores, gerentes de projeto e o restante da equipe são praticamente obrigados a trabalharem por dias consecutivos fazendo horas extras. O cansaço físico gerado por esse aumento no número de horas semanais trabalhadas causa um mau rendimento dos funcionários, que acabam cometendo mais erros e entregando um software instável.

Xp é o conselho do filho astuto do feitor. Ela estabelece um número máximo de horas semanais trabalhadas de forma que os integrantes da equipe não se desgastem e possam trabalhar de forma mais eficiente, já que o importante não é o número de horas trabalhadas e sim o rendimento da produção dentro das horas trabalhadas.

   3.3.3. Princípios

É notável notar que a Xp tem uma série de valores a serem cumpridos para atingir o objetivo de produzir um software de alta qualidade num curto período de tempo. O conceito da Xp é colocar esses valores em prática, tornando possível utilizar todo o potencial dessa metodologia inovadora.

   3.4. Ciclo de vida em um Projeto com Programação Xp

Durante o projeto de desenvolvimento de um software utilizando a metodologia Xp ocorrem diversas fases [9]. Dentre elas temos as fases de exploração, planejamento, primeira iteração, produção, manutenção e morte.

   3.4.1. Fase de exploração

Esta é uma fase com duração de duas semanas a seis meses, onde o objetivo é analisar tecnologias tanto de software como de hardware para tomar decisões sobre quais devem ser usados, de forma que viabilizem o projeto sob os aspectos econômico-financeiro e técnico.

O cliente começa a escrever histórias, histórias essas, que mostram as telas do sistema e as funcionalidades esperadas que o software realize. Normalmente estas descrições são feitas em fichas.

   3.4.2. Fase de planejamento

Com as histórias definidas, cliente e programadores discutem quais delas devem ser priorizadas e qual o tempo estimado para o desenvolvimento dessas histórias, o que gerará o primeiro release, que é uma parte pequena do software, contendo algumas funções já implementadas até aquele momento.

Essas reuniões repetem-se até que se conclua a iteração do release, ou seja, até que desenvolvedor e empresa fiquem satisfeitos com as funcionalidades desenvolvidas até o momento. O tempo recomendado para cada iteração é de uma a no máximo quatro semanas e para cada release o tempo recomendado é de um a quatro meses. 

   3.4.3. Fase da primeira iteração

Programadores sentam-se em pares [11], definem que história será programada e começam a desenvolver os testes de unidade. Em seguida desenvolvem a funcionalidade e após algum tempo de desenvolvimento, já é possível gerar um primeiro release e mostrar para o cliente. Normalmente, essa fase é mais lenta em relação às subseqüentes, uma vez que os programadores estão se acostumando com as tecnologias, com a estrutura do sistema e com as regras do negócio. O que de fato ocorre é que nas próximas fases é possível entregar releases em tempos cada vez mais curtos.

   3.4.4. Fase de produção

Essa fase ocorre após a entrega do primeiro release. O software é colocado numa “incubadora” para simular o ambiente real que será usado. Testes de aceitação já podem ser feitos a partir do momento em que o número de classes e relacionamentos de diversas partes do código já é considerável. Continua-se desenvolvendo os restantes das histórias, os testes, refazendo código, reuniões e releases.

   3.4.5. Fase de manutenção

O código ao longo de um desenvolvimento fica cada vez mais robusto e funcionalidades implementadas anteriormente podem ficar obsoletas e devido a novas funcionalidades surgidas, o código pode ficar confuso e erros podem surgir. Essa fase dedica-se a enxaguar o código, ou seja, refazê-lo, além de inserir novas tecnologias.

   3.4.6. Fase de morte

Um projeto de desenvolvimento de software pode chegar ou não ao seu final. Em caso positivo, o software foi desenvolvido e o cliente não necessita de mais funcionalidades, atingindo-se assim objetivo do cliente e o projeto estará concluído.

Por outro lado, a fase de morte pode ocorrer caso o cliente desista do projeto ou os custos de desenvolvimento inviabilizem a continuação do mesmo.

3.5. Papéis na Programação Xp

Um projeto utilizando Xp é gerenciado por pessoas com dois papéis distintos: o Coach e o Tracker.

   3.5.1. Coach

É o responsável por fazer os programadores cumprirem as regras da Xp e pelo controle da evolução do projeto. Tem também uma importante função como motivador do grupo, por exemplo, em momentos difíceis durante a execução do projeto, onde o grupo necessita estar confiante e coeso. Normalmente é a pessoa mais experiente da equipe e que tem habilidade e capacidade de atuar como um bom mediador entre todas as partes envolvidas no projeto. Durante um mesmo projeto, pode-se revezar o papel de Coach na equipe desenvolvedora.

   3.5.2. Tracker

Cada história tem um tempo estimado para ser executada, sendo que com a soma do tempo de todas as histórias estima-se o tempo total de produção do software. Por meio de ferramentas existentes no mercado, ferramentas estas que auxiliam o controle do desenvolvimento do projeto, como o Xplanner [10], o Tracker insere os tempos estimados das histórias e pode gerenciá-las, verificando se estão sendo feitas nos prazos corretos. Assim como o Coach, pode-se trocar o Tracker durante um mesmo projeto.

   3.5.3. Programador

É o responsável por desenvolver o código do projeto. A rotina do programador é escolher uma história do cliente, sentar com seu par, discutir possíveis alterações no sistema, elaborar testes, implementar a funcionalidade e sincronizar o código gerado com a base que mantém todo o código do sistema atual [11].

   3.5.4. Cliente

Como mencionado anteriormente, é o idealizador do software ou aquela pessoa que sabe exatamente o que o sistema precisa contemplar, tendo um papel ativo e relevante durante todo o período de desenvolvimento do software. Além disto, é o elemento que fornece o total suporte econômico-financeiro ao projeto, caso este papel seja ocupado pelo real cliente do projeto.

* CVS:[5] "O CVS, ou Concurrent Version System (Sistema de Versões Concorrentes) permite que se trabalhe com diversas versões de arquivos organizados em um diretório e localizados local ou remotamente, mantendo-se suas versões antigas e os logs de quem e quando manipulou os arquivos." -pt.wikipedia.org/wiki/CVS

Parte II