*************************************************
********** ENG - Extreme Programming 2 **********
*************************************************

Data     : 20/05/2004 a 21/05/2004
Versão   : 04/07/2007
Professor: Fabrício Jailson Barth
Autor    : Leandro Salvador ( leandrosalvador.com.br )

* Introdução
Extreme Programming, também conhecida como XP, é uma nova abordagem para desenvolvimento de software que possui regras e práticas simples, as quais num primeiro momento parecem inábeis e ingênuas, mas rapidamente se tornam mudanças bem-vindas.
Os clientes são parceiros no processo de desenvolvimento e os desenvolvedores contribuem ativamente, independentemente da experiência, de forma que a teoria e a prática se suportem mutuamente, desta forma atividades improdutivas são aparadas para reduzir custos e frustrações.
A XP pode ser implementada aos poucos na metodologia atual ou de uma única vez, seja como for, muitos benefícios serão incorporados a qualquer projeto de desenvolvimento de software.
Em um projeto XP a qualidade do código é muito importante e algumas práticas focadas na qualidade incluem programação em par, refactoring e criar testes antes do código, ocupando o lugar de honra, pois boas unidades de teste e a cobertura de testes de aceitação é a marca de um projeto XP.
Os desenvolvedores são responsáveis por provar ao cliente que o código trabalha corretamente, não o cliente provar que o código possui problemas, e o cliente deve sempre estar disponível, sendo desejável que a equipe seja composta por desenvolvedores capazes de prosseguir em paralelo, corajosamente fazendo mudanças em qualquer parte do sistema exigido, mas também é desejável uma integração livre de erros destes esforços.

* O que é XP
Extreme Programming (XP) é uma aproximação deliberada e disciplinada para desenvolvimento de software que é bem sucedida porque atinge a satisfação do cliente e cuja metodologia é desenhada para entregar o software que o seu cliente necessita quando ele é necessário.
A XP encoraja os desenvolvedores a sentirem-se confiantes em mudar as exigências do cliente, mesmo no final do ciclo de vida, enfatizando o trabalho em equipe, fazendo com que gerentes, clientes e desenvolvedores sejam todos parte de um time dedicado em desenvolver um software de qualidade.
A XP implementa um caminho simples, porém efetivo, de estilo de desenvolvimento em grupo que melhora um projeto de software em basicamente quatro caminhos
    - comunicação
    - simplicidade
    - feedback
    - coragem
Os programadores XP comunicam-se com seus clientes e seus companheiros de equipe e deixam o design simples e limpo, pegam feedback testando o software desde o primeiro dia e entregam o sistema para o cliente tão cedo quanto possível e implementam mudanças como sugerido.
Com esses fundamentos os programadores XP são capazes de responder corajosamente a mudanças de exigências e tecnologias.
A XP é muito parecida com um quebra-cabeça, há muitas pequenos pedaços e individualmente as peças não fazem sentido, mas quando combinadas juntas, pode-se ver uma figura completa.

* Uma Mudança no Modo de Programar
A XP é baseada na idéia de que um software feito de forma simples e elegante é mais valioso do que um software complexo e difícil de manter.
O fato de que um projeto típico gasta (financeiramente) em torno de vinte vezes mais em pessoal do que em hardware significa que um projeto de 2 milhões de dólares em programadores por ano gastará em torno de 100 mil dólares em computadores por ano.
Digamos que os programadores são espertos e eles encontram uma maneira de economizar 20% dos custos em hardware através de alguns truques de programação muito sofisticados, isto fará o código mais difícil de entender e manter, mas economizará 20% (ou 20 mil dólares) por ano, uma grande economia.
Agora e se ao invés de escrever programas assim os programas forem simples de entender, pode-se esperar economizar não menos do que 10% do custo com pessoal (ou 200 mil dólares), uma economia muito maior, e isto com certeza é algo que o cliente irá observar.
Além disso um outro ponto importante para o cliente são os bugs: a XP enfatiza não apenas testar, mas testar bem.
Os testes são automatizados e provêem uma rede segura para programadores e clientes, são criados antes, durante e depois de o código ser escrito.
Conforme os bugs são encontrados novos testes são adicionados e isto faz com que os bugs não apareçam duas vezes, algo que o cliente certamente irá notar.
Outra característica que o cliente irá notar é a atitude que os programadores XP têm para mudar as exigências, pois a XP nos encoraja a realizar mudanças e freqüentemente o cliente verá oportunidades reais de tornar o sistema mais útil depois de ter sido entregue.
A XP acelera isto pegando o feedback do cliente cedo enquanto ainda há tempo para mudar a funcionalidade ou aumentar a aceitação do usuário.
Muito do que está na XP é uma reavaliação da maneira como o software é criado e a qualidade do código é muito mais importante do que um simples recurso.
Desta forma, o fato de o cliente não ver o código não significa que não deveríamos nos esforçar em criar algo do qual podemos nos orgulhar.

* Quando Usar XP
A XP foi criada como resposta aos tipos de problemas que necessitam de mudanças freqüentes.
Em muitos ambientes de desenvolvimento de software a mudança dinâmica ocorre constantemente, nestes casos a XP será bem sucedida enquanto outras metodologias falharão.
A XP também foi projetada para focar-se nos problemas relacionados ao risco do projeto.
Se o cliente precisa de um novo sistema até uma data específica o risco é alto.
Se o sistema é um novo desafio para a equipe de desenvolvimento o risco é ainda maior.
Se o sistema é um novo desafio para toda a indústria do software o risco é ainda muito maior.
As práticas da XP são ajustadas para diminuir o risco e aumentar a probabilidade de sucesso, e geralmente é ajustada para pequenos grupos de programadores, entre 2 e 12, embora projetos com mais de 30 foram bem sucedidos.
Os programadores podem ser medianos, não necessariamente experts, mas XP não deve ser usada em projetos com muita gente, pois em projetos com exigências dinâmicas ou alto risco uma equipe pequena de programadores XP será melhor que uma grande, e é desejável que o time de desenvolvimento seja prolongado, com baixa rotatividade.
Por falar em time de desenvolvimento, o time XP inclui não apenas os desenvolvedores, mas os gerentes e clientes também, todos trabalhando juntos lado a lado, fazendo perguntas, negociando escopo e calendário, criando testes funcionais que requerem mais que apenas os desenvolvedores estarem envolvidos em produzir o software.
Uma outra exigência é a testabilidade, onde deve-se ser capaz de criar unidades automatizadas e testes funcionais.
Se por um lado algumas coisas serão desqualificadas por esta exigência, é surpreendente quantas não serão.
É necessário aplicar pequenos testes ingênuos em algumas coisas, talvez até mudando o desenho do sistema para facilitar o teste, pois onde há vontade, há um caminho para teste.
A última coisa na lista é produtividade, pois projetos XP unanimemente relatam maior produtividade de programação quando comparados a outros projetos com o mesmo ambiente corporativo, mas este nunca será o objetivo da metodologia XP.
O objetivo real sempre foi entregar o software necessário quando necessário, se isto é o importante para o projeto, então pode ser a hora de utilizar XP.

* Necessidade de uma Outra Metodologia
Muitas vezes o software parece uma oficina cujas ferramentas estão todas desordenadas e o trabalho não pode ser feito  porque não é possível começar nada.
A XP foi baseada em observações do que torna um programa de computador mais rápido ou mais devagar, sendo uma nova metodologia importante por dois motivos:
O primeiro e mais importante é a re-examinação das práticas de desenvolvimento de software que se tornaram procedimentos de operação padrão.
O segundo é que esta é uma de diversas novas metodologias de software leve, ou seja, com poucas regras, práticas e documentos.
A XP tem poucas regras e um modesto número de práticas, todas fáceis de seguir, e também é um ambiente de desenvolvimento limpo e conciso, observando o que faz o desenvolvimento de software ir mais rápido ou mais devagar, fazendo com que os programadores sintam-se livres para serem criativos e produtivos mas cotinuem organizados e focados.

* O Cliente Está Sempre Disponível
Um dos poucos requisitos da XP é ter o cliente disponível, não apenas para ajudar o time de desenvolvimento, mas para ser parte dele, pois todas as fases de um projeto XP requerem comunicação com o cliente, de preferência face a face, no local.
Para o cliente poderá parecer muito tempo e o departamento responsável por liberar o funcionário poderá tentar passar um trainee como um expert, mas a equipe XP precisa do expert.

* Padrões de Codificação
O código deve estar formatado de acordo com o padrão de codificação, uma vez que padrões de código deixam o código consistente e fácil para todo o time ler e refabricar (refactor).

* Codificar o Teste Unit Antes
Criar os testes primeiro, antes do código, torna muito mais fácil e rápido criar o código, uma vez que esta combinação entre criar uma unidade de teste e criar algum código para fazer isto passar é quase o mesmo que codificar direto mas, se já é possível ter os testes, não será necessário criá-los depois, economizando algum tempo agora e muito tempo depois.
Criar um teste unitário ajuda o desenvolvedor a realmente considerar o que precisa ser feito, pois as exigências são fixadas firmemente pelos testes, facilitando para que não haja qualquer engano em uma especificação escrita em forma de código executável.
Além disso o feedback é feito imediatamente enquanto se trabalha, o que freqüentemente não está claro quando um desenvolvedor termina toda a funcionalidade necessária.
Se criamos nossos testes unitários antes então sabemos quando estamos prontos: todos os testes unitários rodaram.
Há também um benefício para o desenho do sistema, pois geralmente é muito difícil testar alguns sistemas de software que costumam ser codificados antes e testados depois, freqüentemente por um time completamente diferente, mas criando testes antes o desenho será influenciado por um desejo de testar tudo de valor para o cliente e o desenho refletirá isto, sendo mais fácil de testar.
Há um ritmo para desenvolver o software de teste unitário antes:
Primeiro cria-se um teste para definir algum pequeno aspecto do problema em mãos.
Então cria-se o código mais simples que fará o teste passar.
Então cria-se um segundo teste.
Agora adiciona-se ao código criado para fazer este novo teste passar, mas não até ter-se um terceiro teste ainda.
Para finalizar continua-se até não haver mais nada para testar.

* Par de Programadores
Todo o código incluído em uma liberação de produção é criado por duas pessoas trabalhando juntas em um único computador, pois o par de programadores incrementa a qualidade do software sem impactar o prazo de entrega.
- isto é aparentemente contraditório, mas duas pessoas trabalhando em um único computador adicionará muito mais funcionalidade do que duas trabalhando separadamente, sem contar que possuirá muito mais qualidade
- o aumento de qualidade traz grandes economias mais tarde no projeto
- a melhor maneira de programar em par é apenas sentarem-se lado a lado em frente do monitor
- uma pessoa escreve e pensa taticamente sobre o método sendo criado, enquanto a outra pensa estrategicamente sobre como o método se ajusta na classe
- leva tempo para se acostumar com a programação em par, mas não se preocupe se isto parecer ilógico no começo

* Integração Freqüente
Os desenvolvedores devem integrar e liberar código no repositório de códigos a cada poucas horas, sempre que possível, e em qualquer caso nunca deve prender as mudanças por mais do que um dia.
A integração contínua freqüentemente evita divergência ou fragmentação de esforços de desenvolvimento, onde os desenvolvedores não estão comunicando-se sobre o que pode ser reutilizado, ou o que poderia ser compartilhado, pois todos precisam trabalhar com a versão mais atualizada, e as mudanças não devem ser feitas em códigos obsoletos causando dores de cabeça na integração.
Cada par de desenvolvimento é responsável por integrar seu próprio código todas as vezes em que houver um intervalo razoável de tempo, isto pode ser quando os testes unitários tiverem sido rodados a 100% ou alguma porção da funcionalidade planejada estiver terminada.
A integração é uma atividade do tipo "pague-me agora ou pague-me mais depois".

* O Código Pertence a Todos
A propriedade coletiva do código encoraja todos a contribuirem com novas idéias em todos os segmentos do projeto, pois qualquer desenvolvedor pode mudar qualquer linha de código para adicionar funcionalidade, corrigir bugs ou fazer refactor e ninguém se transforma em um obstáculo para mudanças.
Se o time inteiro já tem alguma responsabilidade pelas decisões de arquitetura, não deveriam receber a autoridade também?
A idéia é cada desenvolvedor criar testes unitários para seu código assim que é desenvolvido e todo o código que é liberado no repositório de código deve incluir testes unitários.
O código que é adicionado, erros como são corrigidos, e antigas funcionalidades como são mudadas deverão ser cobertas pelo teste automático, desta forma pode-se confiar na suíte de testes para checar todo o repositório, e antes de qualquer código ser liberado ele deve passar por toda a suíte de testes a 100%.
Uma vez que o código estiver no lugar qualquer um pode fazer nudanças em qualquer método de qualquer classe e liberar isto no repositório de código conforme necessário, quando combinado com integração freqüente os desenvolvedores raramente anunciam que uma classe foi extendida ou reparada.
Na prática a propriedade coletiva do código é realmente mais confiável do que colocar uma única pessoa encarregada de cuidar de classes específicas, especialmente porque uma pessoa pode deixar o projeto a qualquer momento e desfalcar a equipe.

* Otimize Depois
Não deve-se otimizar o código até o fim do projeto e nunca deve-se tentar adivinhar o que será o funil do sistema, deve-se medir isto.
A idéia é fazer o sistema trabalhar, fazer isto certo, então fazer isto rápido.

* Não Trabalhar Acima do Tempo Estipulado
Trabalhar acima do tempo estipulado suga o espírito e a motivação do time, e projetos que requerem tempo extra para serem concluídos no prazo atrasarão não importa o que seja feito.
Ao invés disso é melhor fazer uma reunião de planejamento de liberação (cronograma) para mudar o escopo do projeto ou tempo, pois aumentar os recursos adicionando mais pessoas é uma péssima idéia quando o projeto está atrasado.

* Testes Unitários
Os testes unitários são uma das pedras preciosas da XP, mas o estilo de testes XP é um pouco diferente.
Primeiro deve-se criar ou baixar um framework de teste unitário (unit test framework) para ser capaz de criar suítes de testes automatizadas.
Depois deve-se testar todas as classes no sistema (os triviais métodos getter e setter geralmente são omitidos).
Por último deve-se tentar criar suas próprias suítes de teste, antes do código.

* Conclusão
A XP é realmente uma metodologia dinâmica, que pode otimizar incrivelmente o desenvolvimento de software e garantir produtos com qualidade, testados em tempo real e da forma mais produtiva possível.
Existe um grande foco nos testes, que devem ser feitos antes mesmo do código, permitindo que os programadores compreendam plenamente o que codificarão antes de porem a "mão na massa".
A proximidade com o cliente é outro item fundamental, pois insere na equipe de desenvolvimento alguém que conhece profundamente o sistema e pode sugerir melhorias a todo instante, participando ativamente das atividades da equipe.
Prioriza-se a clareza do código muito mais do que sua otimização, pois considera-se que um projeto baseado em XP deve ser de fácil manutenção acima de tudo.
Pode existir um certo preconceito por parte dos gerentes que implementarão uma equipe de desenvolvimento XP, pois um dos príncipios fundamentais da metodologia XP é que os programadores não trabalhem acima do tempo estipulado, uma vez que quantidade de trabalho pode ser inversamente proporcional à qualidade do mesmo.
Enfim, a XP é muito bem-vinda em projetos que possuam um número relativamente pequeno de programadores e que devam ter qualidade e facilidade de manutenção acima de tudo.

* Referência Bibliográfica
http://www.extremeprogramming.org


----------//----------