Extreme Programming

Métodos Ágeis

O artigo anterior desta série abordou sobre o Processo Unificado, que inovou no desenvolvimento do software orientado a objetos. No entanto, embora seu formato fosse estruturado e a introdução da UML tenha sido um grande avanço, muitas dificuldades ainda persistiam na tentativa de obter o controle do projeto. A maior delas era a quantidade de artefatos para controlar o processo que dificultava a adoção por pequenos cases.

Mas essa época foi um momento fértil na Engenharia de software e rapidamente apareceram várias outras metodologias que alavancaram a produção de software e mudaram a forma de pensar de muitos projetistas.

Uma delas foi o EXtreme Programming (XP), sobre o qual será abordado agora.

Os métodos Ágeis

Antes de falar sobre o XP, é importante lembrar da situação em que o desenvolvimento de software se encontrava e como os eventos desta época impactaram no futuro da engenharia.

Na virada do milênio, começaram a ganhar visibilidade vários processos alternativos, que prometiam uma entrega mais rápida de software e ao mesmo tempo focavam num melhor relacionamento com o cliente.

Neste cenário de acontecimentos, em “fevereiro de 2001 um grupo de profissionais extraordinários do desenvolvimento de software reuniu-se em um Resort de Ski em Wasatch Range para discutir melhores maneiras de desenvolver software. Esse encontro deu origem ao Manifesto para Desenvolvimento Ágil de Software, uma declaração com os princípios que regem o desenvolvimento ágil” (GOMES, 2014).

Partindo da esquerda, Stephen Mellor, Ward Cunningham, Dave Thomas, Andrew Hunt, Martin Fowler e James Grenning

O Manifesto se tornou o embasamento filosófico para os chamados Métodos Ágeis que, segundo SOMMERVILLE (2011), “universalmente, baseiam-se em uma abordagem incremental para a especificação, o desenvolvimento e a entrega do software. Eles são mais adequados ao desenvolvimento de aplicativos nos quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento”.

Esse evento em especial acendeu um estopim que faria uma explosão de inovações surgirem nos anos que se seguiram. Esse manifesto mudou muitas mentes e continua mudando.

Para conferir o manifesto, acesse https://agilemanifesto.org.

A programação extrema

A partir do manifesto, algumas metodologias inovadoras ganharam visibilidade na comunidade, o XP foi uma delas.

Segundo PRESSMAN (2006), “apesar do trabalho inicial sobre as ideias e métodos associados ao Extreme Programming (XP) ter ocorrido durante o final da década de 1980, o trabalho pioneiro sobre o assunto, escrito por Kent Beck, foi publicado em 1999”.

Em sua essência, trata-se de um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento.

Ele é organizado em torno de conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software (TELES, 2004)

O ciclo de vida do XP é baseado em quatro valores, que o desenvolvedor precisa aplicar o tempo todo:

1. Comunicação;
2. Simplicidade;
3. Feedback;
4. Coragem.

Comunicação

A comunicação deve ser contínua, tanto com o cliente como entre os membros da equipe. O objetivo é criar o melhor relacionamento possível, dando preferência às conversas pessoais em detrimento de outros meios como telefone, email, chats etc.

Simplicidade

É preciso fomentar a implementação de funcionalidades com base nos problemas de hoje, deixando os problemas do futuro para o futuro. Como os requisitos são mutáveis, deve-se implementar apenas o que é estritamente necessário, de forma simples e com o mínimo de código possível.

Feedback

Para o XP funcionar, os membros da equipe precisam ser profissionais comunicativos e com facilidade de se relacionar. Assim os feedbacks sobre as estratégias e, principalmente, sobre alterações no código são melhor recebidas e aceitas pelos membros do time.

Coragem

Errar é natural, e quebrar o código de um sistema acontece cedo ou tarde. Por isso é necessário ter coragem para lidar com isso e confiança nos mecanismos de proteção do XP como, por exemplo, os Testes Automatizados.

A coragem ajuda, principalmente, quando a possibilidade de simplificar o software é detectada. A Refatoração deve ser feita o quanto antes, mantendo a legibilidade do código (isso será abordado mais adiante neste artigo). Por isso a equipe precisa ser corajosa e acreditar nos valores do XP para que o software evolua com segurança e agilidade.

As práticas do XP

As atividades são baseadas em quatro atividades básicas:

• Ouvir: é preciso ouvir (e ouvir bastante) para entender as regras de negócio do sistema. Antes de qualquer coisa é preciso ter domínio sobre o negócio a ser implementado, para que o Design e a codificação ocorram de forma fluida;
• Desenhar: o bom design é uma excelente ferramenta para o entendimento de sistemas complexos. Por isso, é preciso manter o design sempre simples, evitando aumentar a complexidade que ocorre pela criação de funcionalidades que não sejam realmente necessárias. Para isso existe o princípio YAGNI (You aren’t gonna need it/Você não vai precisar disso) que diz para fazer as coisas somente no momento em que realmente for preciso. Antecipar a implementação antes que seja necessário é um desperdício de tempo, porque aumenta a complexidade do design do software e talvez a implementação adicional nunca seja usada de fato;
• Codificar: o código fonte deve ser coletivo, ou seja, todos os membros podem modificá-lo e devem ter o conhecimento claro sobre ele. Por isso deve existir um guia para padronização do código (que pode ser definido pelo próprio time), de forma que todos codifiquem da mesma forma;
• Testar: os Testes Automatizados devem ser escritos antes do código real ser produzido. Além disso, os times ágeis devem utilizar a prática da Integração Contínua, para certificar que tudo está realmente funcionando antes de colocar o novo código em produção.

Observando essas quatro atividades, o XP apresenta 13 práticas para que o processo aconteça.

Prática 1. A presença do Cliente

O XP insiste que o cliente deve estar presente no dia a dia do projeto, pois isso contribui para o sucesso. O contrário também é considerado verdade, pois a ausência do cliente é um sério fator de risco.

A presença do cliente para tirar dúvidas, sempre que for possível, propicia uma série de pequenos ajustes e evita mudanças bruscas ao longo do caminho. Isso poupa um tempo incrível de trabalho.

Apesar de existirem vários meios de comunicação, a conversa presencial é a forma mais eficaz, pois proporciona identificar outras informações como os gestos do cliente, expressões faciais, postura, tom de voz, entre outros.

As expressões faciais que demonstram falta de entendimento, por exemplo, não são visíveis por telefone ou por chat, e podem ocasionar interpretações e decisões equivocadas no projeto.

Prática 2. O jogo de planejamento

O planejamento acontece diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades, garantindo que a equipe esteja trabalhando no que é mais importante para o cliente.

Os projetos são divididos em Releases e Interações, de forma que o cliente e a equipe tenham oportunidade de revisar o planejamento.

• Interações: são períodos de poucas semanas, onde um conjunto de funcionalidades é implementado.
• Releases: são períodos de alguns meses, onde as entregas geram um valor definido, ou seja, o cliente pode usar o software;

As interações

Para cada Interação, ocorre uma reunião chamada de Jogo do Planejamento, onde “o cliente escreve histórias de usuário em cartões que representam a necessidade da funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for preciso para que eles possam implementá-la” (GOMES, 2014).

Como “parte da equipe de desenvolvimento, o cliente discute cenários com outros membros da equipe. Juntos, eles desenvolvem um ‘Cartão de História’, englobando as necessidades do cliente” (SOMMERVILLE, 2011)

As funcionalidades são descritas pelo cliente nesses pequenos cartões chamados de “Histórias”, respeitando o espaço de cada cartão para ficar o mais objetivo possível. Isso força o cliente a pensar melhor na funcionalidade. Em seguida, o cliente atribui um valor (de prioridade) para cada cartão.

“Membros da equipe XP avaliam, então, cada História e lhe atribuem um custo, medido em semanas de desenvolvimento. Se a História precisar de mais do que três semanas de desenvolvimento, pede-se para o cliente dividir a História em Histórias menores e a atribuição de valor e custo ocorre novamente” (PRESSMAN, 2006).

Nesse processo o cliente fica sabendo dos custos do desenvolvimento e, junto com a equipe, prioriza as funcionalidades que deverão fazer parte de cada Release.

Exemplo de um cartão de História

Os releases

Com as Histórias definidas, o cliente deve colocá-las nos Releases. Não é necessário que todas as Histórias sejam distribuídas, pois durante as reuniões de Interação, o cliente vai aos poucos aprendendo mais sobre o sistema e, mudando sua visão, identificará melhor suas reais necessidades.

Segundo SOMMERVILLE (2011), cada Release deve conter “um conjunto mínimo de funcionalidades útil, que fornece o valor do negócio”.

Os Realeases devem ser ordenados, com tamanhos fixos e pequenos o suficiente para entregas rápidas. “Cada projeto é realizado para atender às necessidades atuais, e nada mais” (SOMMERVILLE, 2011).

O trabalho dos programadores

Após definidas as Histórias da Interação, os integrantes do time escolhem os cartões que irão implementar naquele dia de trabalho. Isso ocorre todos os dias até a próxima reunião de Interação, onde as mudanças e novas prioridades poderão ser definidas.

As mudanças nos requisitos

Em cada reunião de Interação, o cliente poderá mudar as Histórias que achar necessário, criando novas, substituindo as existentes ou removendo as desnecessárias. Assim, o XP simplifica as mudanças do projeto, gerando benefícios para o cliente mais rapidamente.

O cliente pode mudar o projeto quantas vezes quiser, mas só é permitido fazer isso na reunião de Interação. Uma vez definidas as Histórias de uma Interação, o cliente não poderá alterá-las e terá que concordar com o que está sendo implementado até a próxima reunião, onde poderá solicitar uma História que ajuste o que foi feito ou deixar como está.

Prática 3. Reunião diária

Chamada de “Stand up meeting” (ou “Reunião em Pé”) para denotar uma conversa rápida, esta reunião deve ocorrer todos os dias (preferencialmente de manhã) com todos os integrantes do time e, se possível, com a presença do cliente.

Cada membro deve comentar o que fez no dia anterior, fazendo com que a equipe fique atualizada sobre o andamento do projeto. Também é propício cada um apresentar os desafios enfrentados e as soluções criadas por eles. Esse feedback ajuda principalmente quando um desafio parecido acontecer novamente, pois todos saberão como resolver ou a quem procurar para um auxílio.

Stand up meeting deve ser uma reunião diária

Nessa reunião é decidido diariamente quais os cartões de História irão para quais membros do time. Isso não deverá ser decidido apenas por um único membro, mas por toda a equipe, pois assim, com uma visão do todo, será possível ter uma decisão mais assertiva sobre as dependências e desafios de cada História.

É importante que esta reunião seja o mais breve possível, mas é muito importante que todos os membros falem por alguns minutos.

Prática 4. Programação em pares

No XP, os desenvolvedores nunca trabalham sozinhos, sempre em pares. O “Pair Programming” (ou Programação em pares) deve acontecer em um mesmo computador, onde duas pessoas trabalhem juntas. Uma das pessoas será o Condutor, que assumirá o teclado e digitará os comandos. A outra pessoa será o Navegador, que acompanhará o trabalho como estrategista.

Quando o Condutor estiver cansado, poderá pedir para trocar de posição, tornando-se um Navegador. Esse revesamento é fundamental e deve ser praticado sempre. Não apenas a troca de papel (Condutor/Navegador), mas também a troca de pares, de forma a propiciar um conhecimento abrangente de toda a equipe dentro do projeto.

Esse processo provoca uma revisão permanente do código, pois enquanto o Condutor está digitando, o Navegador estará o tempo todo observando para evitar que algum erro passe despercebido. Dessa forma, erros que dariam muito trabalho para serem detectados e corrigidos depois, são corrigidos facilmente, detectados pela pessoa que não está com as mãos no teclado.

Programação em Pares

A programação em par produz ideias mais simples e eficazes, pois quando uma pessoa sugere uma solução muito difícil, a outra identifica a complexidade e, na medida que terá dúvidas, poderá sugerir simplificações.
O código produzido é quase livre de defeitos, pois por causa do processo contínuo de revisão, pouquíssimos erros permanecem no código.

Distrações como e-mail, mensagens instantâneas, cansaço ou internet causam uma perda de produtividade que o programador não consegue perceber. Mas com a presença do companheiro, ele terá um compromisso maior, porque seu trabalho envolve mais alguém.

Prática 5. Refatoração

A Refatoração é o ato de alterar um código sem afetar a funcionalidade que ele executa. É utilizado para tornar o software mais simples de manter, utilizando Testes Automatizados para garantir que as modificações não interrompam seu funcionamento original (TELES, 2004).

O código-fonte mal formulado despende muito tempo para ser entendido e modificado. Em contrapartida, um código legível é rapidamente corrigido ou alterado. A Refatoração não deve alterar o comportamento do código, mas apenas torná-lo mais legível.

A prática da Refatoração é especialmente útil para código coletivo, onde todos que precisarem analisá-lo possam entendê-lo. Quando não se usa a refatoração, o código vai ficando cada vez mais ilegível na medida que vai crescendo, dificultando para toda a equipe.

Em XP, um projeto sem Refatoração não tem a menor chance de sobrevivência. A agilidade de produzir feedback rapidamente para o cliente só é possível com alterações rápidas e constantes no código.

O XP enfatiza uma continua remodelagem através da Refatoração!

“Todos os desenvolvedores devem refatorar o código continuamente assim que encontrarem melhorias de código. Isso mantém o código simples e manutenível” (SOMMERVILE, 2011)

Porém, a Refatoração também tem um preço: é acompanhada pelo risco de código parar de funcionar. Para resolver isso, o XP possui um ferramenta que combate o risco de se quebrar um código que está funcionando, como será abordado na próxima prática do XP.

Prática 6. Desenvolvimento Guiado por Testes

A ideia principal do “Test-Driven Development” (ou Desenvolvimento Guiado por Testes) é minimizar ao máximo o tempo de depuração em um projeto, através da implementação de Testes Automatizados.

Atenção: Quem não está acostumado com o termo, pode confundir “Teste Automatizado” com “Teste Automático”, mas são duas coisas diferentes. Para ser “automático”, bastaria uma ferramenta que fizesse uma bagatela de testes partindo de um simples clique num botão. Já para um teste “automatizado”, alguém tem que “automatizá-lo”, ou seja, implementar uma rotina que efetue os testes desejados. É este segundo cenário que chamamos de “Testes Automatizados”.

Os Testes Automatizados avisam se o código continua produzindo as mesmas respostas após ter sido alterado, provendo uma enorme segurança ao processo de Refatoração e injetando coragem no desenvolvedor.

Como os testes precisam ser implementados pelo desenvolvedor, produzi-los é um investimento que gera retornos no futuro, tais como:

• Por serem implementados, os testes se tornam grandes aliados para o entendimento do design do sistema, servindo de “documentação” para a compreensão do código fonte;
• Sempre que um teste detecta uma falha, a equipe ganha tempo de desenvolvimento, pois tem a oportunidade de corrigir o problema rapidamente;
• Evita longas sessões de depuração que costumam tomar boa parte do tempo dos projetos.

“Quanto mais tempo se leva para descobrir que você cometeu um erro, mais caro é para corrigi-lo” (BOEHM, 1988)

O XP trabalha com dois tipos de testes:

1. Teste de Unidade: é realizado sobre cada unidade (classe, método ou função) do sistema com a finalidade de verificar se os resultados gerados estão corretos;
2. Teste de Aceitação: são efetuados sobre cada História do sistema, verificando não apenas uma unidade em particular, mas as interações entre um conjunto de classes ou rotinas que implementam uma funcionalidade.

Para implementar os testes, a equipe pode fazer uso de frameworks de testes, que já possuem diversas funcionalidades, permitindo asserções para várias situações.

Uma característica importante do TDD é o conceito de “test-first”, ou seja, “primeiro o teste”. Isso significa que cada nova funcionalidade, após ser devidamente pensada, deve ter seu Teste de Unidade implementado “antes que a funcionalidade em si seja implementada” (SOMMERVILLE, 2011).

Isso força o desenvolvedor a “pensar antes de fazer”, o que gera código mais simples de entender e livre de remendos, que poderiam ser causados por erros de design.

Prática 7. Código Coletivo

Um projeto implementado de forma clássica, geralmente é dividido em pedaços, de forma que cada membro da equipe fique responsável por uma ou mais partes. Isso gera nos projetos as chamadas “Ilhas de Expertise” onde uma pessoa sozinha acaba possuindo o domínio sobre uma área do projeto, de forma que somente ela conhece aquela parte do código.

O XP defende o contrário! O conhecimento do projeto não deve ser limitado a uma pessoa, mas, pelo contrário, toda a equipe deve ter o conhecimento de tudo e saber como alterar qualquer parte do projeto.

O XP incentiva a propriedade coletiva do software, isto é, “os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos e todos os desenvolvedores assumem responsabilidade por todo o código. Qualquer um pode mudar qualquer coisa”. SOMMERVILLE (2011)

Dessa maneira, cada parte do software pode ser mantida por diferentes desenvolvedores ao longo de sua vida, forçando que o código esteja sempre sendo revisado e levando a equipe a ser mais ágil no desenvolvimento.
Como não existe um único especialista, qualquer pessoa pode mexer no código sem precisar esperar por uma pessoa mais experiente.

O código coletivo exige coragem por parte dos desenvolvedores, pois diversas vezes ao dia o desenvolvedor terá de mexer em partes do sistema que não foram construídas por ele. Isso só é possível através de Refatoração e TDD.

Prática 8. Padrões de codificação

Um dos valores fundamentais do XP é a comunicação, o que inclui o código fonte produzido. A equipe deve se comunicar de forma clara através do código fonte.

Como são diferentes programadores, existirão diferentes estilos. Essa diferença no código dificulta a compreensão do código por todos da equipe.

Trecho de um documento de padronização de estilo de programação

Por esse motivo, deve-se adotar um mesmo estilo de codificação por todos para que exista a mesma velocidade de compreensão. Isso é alcançado estabelecendo um padrão que seja aceito pela maioria e documentado em algum lugar para ser usado como referência.

Nos momentos de Programação em Pares, o Navegador pode ajudar o Condutor, lembrando-o sobre o padrão documentado e mantendo assim a qualidade do código.

Prática 9. Design simples

O XP procura entregar valor para o cliente, determinando que é preciso sempre assumir o design mais simples possível e que faça uma funcionalidade passar nos Testes Automatizados.

Em um projeto de software a mudança é constante, pois requisitos, design, tecnologia e os membros da equipe mudam. O problema não está na mudança em si, mas na incapacidade de lidar com ela.

“Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças.” (Charles Darwin)

Segundo TELES (2004), para manter um design simples, o XP recomenda os quatro valores mencionados no começo deste artigo:

1. Comunicação: o design simples comunica sua intenção de forma mais eficaz que um design complicado;
2. Simplicidade: o design simples torna o software mais leve e mais fácil de ser alterado a qualquer momento, visto que é mais fácil de ser compreendido. Como explica PRESSMAN (2006), “um projeto XP segue rigorosamente o princípio KIS (Keep it simple/mantenha a simplicidade). Um projeto simples é sempre preferível em relação a uma representação mais complexa”;
3. Feedback: com um design simples, a equipe é capaz de avançar de forma mais ágil e obter feedback do cliente mais rapidamente;
4. Coragem: o design simples é aquele que a equipe trabalha apenas para resolver o problema de hoje. Problemas do futuro, mesmo que já sejam previstos, são deixados para o futuro. É necessário coragem para assumir que a equipe será capaz de resolver o problema no futuro caso ele realmente se manifeste.

Segundo PRESSMAN (2006), “se um problema de projeto difícil é encontrado […] o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto. Denominado ‘Solução de Ponta’, este protótipo é implementado e avaliado”.

Ao longo das reuniões de Integração, o design precisa evoluir, mas deve manter-se simples e claro para que a equipe possa fazer alterações no software a qualquer momento e com facilidade.

Mais uma vez, isso só é possível com Refatoração e TDD.

Prática 10. Metáfora

Muitas vezes, alguém está explicando algo e não há nada que faça o interlocutor compreendê-lo. Depois de algumas tentativas, a pessoa faz uma comparação daquele assunto com algo que o interlocutor conhece bem. Neste momento, em um instante, consegue entender toda a explicação simplesmente porque a outra pessoa utilizou um artifício chamado Metáfora.

O XP utiliza a Metáfora para comunicar diversos aspectos do projeto e criar uma visão comum. A equipe deve buscar Metáforas que permitam explicar as ideias centrais do projeto de forma simples e objetiva. Isso facilitará a comunicação com o cliente e com os outros envolvidos no projeto.

Falar da Metáfora é muito fácil, o problema é criá-la :)

Desenvolver uma Metáfora é um exercício de criatividade e abstração. Para TELES (2004), é necessário olhar para os lados e pensar nas coisas mais absurdas, tentando relacioná-las com o problema a ser resolvido. Normalmente, um simples “insight” pode economizar meses de trabalho.

A utilização da Metáfora é uma prática que anda de mãos dadas com Ritmo Sustentável, que será abordado a seguir, pois sem um Ritmo Sustentável fica difícil ter criatividade e boas ideias.

Prática 11. Ritmo sustentável

O XP desaconselha o uso de horas extras, recomendando Ritmos Sustentáveis de trabalho. Por duas razões:

1. Permitir que os desenvolvedores trabalhem apenas oito horas por dia é mais humano e demonstra respeito com a individualidade;
2. A integridade de cada membro da equipe aumenta a agilidade do projeto.
   Programadores exaustos cometem mais erros, assim, a equipe que não trabalha por um tempo excessivo se mantém mais efetiva.

Os desenvolvedores devem chegar descansados todos os dias. Pessoas descansadas produzem melhor, têm ideias eficazes, são mais atentas e poupam tempo do desenvolvimento, ou seja, não é vantagem trabalhar mais. Vantagem é trabalhar de forma mais eficaz e inteligente.

ASTELS (2002) fala da necessidade de equilíbrio entre a carga de trabalho e a de descanso, recomendando que se “trabalhe 100% durante as 40 horas e descanse 100% no resto. Se algum deles não tiver foco feito com 100%, um afetará o outro”.

O XP compreende a natureza humana do desenvolvimento de software e percebe que trabalhar mais horas significa diminuir o ritmo de produção e atrasar o projeto, por mais estranho que isto possa parecer no início.

A adoção do Ritmo Sustentável é um desafio a ser vencido! As equipes que conseguem adotar esta prática colhem muitos frutos dela. Seus projetos são mais ágeis, as pessoas convivem de forma mais harmoniosa e não precisam sacrificar a vida pessoal em nome do trabalho.

Prática 12. Integração contínua

Quando uma nova funcionalidade é implementada ela pode afetar outras que já estavam funcionando. Por isso é imprescindível uma integração que coloque todas as funcionalidades para operarem juntas e certificar que os novos códigos adicionados não esteja quebrando nada dentro do sistema.

Nos processos clássicos, novos módulos são integrados após um determinado ciclo de desenvolvimento. No XP não é assim! Ao invés de esperar muito tempo para integrar as partes do sistema, a equipe deve integrar com a maior frequência possível, testando o sistema inteiro várias vezes por dia. Essa prática é chamada de Integração Contínua (JEFFRIES, 2001).

XP = integração várias vezes por dia

Uma das dificuldades de se integrar diversas vezes ao dia diz respeito ao tempo necessário para fazer o build de todo o sistema, por isso, esse tempo precisa ser mantido baixo ao longo de todo o projeto.

As formas de conseguir isso são:

• Fazer com que a interdependência (acoplamento) entre os arquivos seja baixa;
• Para softwares compilados, é preciso que o compilador só processe os arquivos que tiverem sido editados e utilize diretamente o código objeto para os demais. Trabalhar com carregamento dinâmico de bibliotecas quando isso for possível é uma ótima alternativa;
• Para softwares baseados na web, é preciso usar ferramentas para build baseadas em conteinerização (Git HUB actions, Bitbucket Pipelines, TravisCi, CircleCi etc), que instalam o projeto e executam testes sempre que um novo código fonte é adicionado.

Se o build começar a ficar lento, a equipe precisa tratar logo da questão e descobrir uma forma de mantê-lo rápido. Isso é uma prioridade!

O uso da Integração Contínua permite que a equipe possa avançar com agilidade ao mesmo tempo que diminui a possibilidade de erros.

Duas categorias de ferramentas são sumamente necessárias:

1. Sistema de controle de versão: é uma ferramenta essencial no processo de integração, pois possibilita facilidade e rapidez na tarefa de obter o código fonte e armazenar as suas mudanças, detectando conflitos entre as versões e oferecendo maneiras de resolvê-los. A mais popular (pelo menos no momento que este artigo foi escrito) é o GIT;
2. Ferramenta de build: é uma ferramenta capaz de compilar todo o sistema e executar outras atividades que se façam necessárias. A ferramenta deve ser capaz de obter o código fonte do repositório, instalar as dependências do projeto e executar os Testes Automatizados, devolvendo um feedback sobre a situação atual do projeto

Prática 13. Releases curtos

O XP objetiva gerar um fluxo contínuo de valor para o cliente, de forma que o projeto produza pequenos avanços gradualmente, buscando grandes recompensas o mais rapidamente possível.

Para isso acontecer, é preciso implementar Releases Curtos.

O XP sugere que a equipe de desenvolvimento implemente o quanto antes as funcionalidades mais importantes, solicitando ao cliente que selecione primeiro o conjunto de funcionalidades que poderá gerar o valor mais alto. Assim, os primeiros Releases deverão fornecer o máximo de valor, de modo que o cliente consiga obter retorno o mais rápido possível.

Trabalhando com Releases Curtos, o cliente tem oportunidade de avaliar o projeto com mais frequência, tendo mais chances de reduzir eventuais despesas caso o projeto não esteja atingindo os resultados esperados.

A abordagem tradicional é mais arriscada que a do XP, pois os usuários não têm a chance de avaliar o software sempre, e o projeto só começa a gerar receita após a conclusão.

Conclusão

O XP é ideal para equipes que desejam agilidade no seu processo, mas não querem abrir mão da excelência técnica.

Alguns pontos mais polêmicos como Testes Automatizados, Programação em pares, Código Coletivo e, principalmente, ausência de horas extras acabam causando estranheza para algumas equipes. Não se pode tirar a razão destes, pois se essas práticas forem mal usadas, podem realmente trazer aumento de custo e de prazo nos projetos.

Por isso é importante entender bem o propósito do XP e sua real essência.

Disciplina e criatividade são duas qualidades imprescindíveis para quem pretende usar Métodos Ágeis em projetos. Somente a partir de uma visão criativa sobre a metodologia e uma disciplina equilibrada para cumpri-la é que todos poderão ter benefícios reais e palpáveis.

Leia todos os artigos desta série:

• Os Processos de Software
• O Modelo em Cascata
• O Modelo Incremental
• O Modelo em Espiral de Boehm
• O Processo Unificado
• Extreme Programming

Referências para Aprofundamento

ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming: Guia prático. Rio de Janeiro, RJ, Campus, 2002.

BOEHM, B.W; Papaccio, P.N. Understanding and Controlling Software Costs. IEEE. 1988.

GOMES, André Faria. Agile: Desenvolvimento de software com entregas frequentes e foco no valor de negócio. São Paulo, SP, Brasil. Casa do Código, 2014.

JEFFIES, Ron; ANDERSON, Ann; HENDRICKSON, Chet. Extreme Programming Installed 1a Edição. Addison-Wesley Professional, 2001

PRESSMAN, Roger S; Engenharia de Software. 6a edição. McGraw-Hill, New York, EUA, 2006.

SOMMERVILLE, Ian. Engenharia de Software 9a. Edição. São Paulo, SP, Pearson, 2011.

TELES, V. M. Extreme Programming. São Paulo, SP, Brasil. Novatec, 2004.