Na informática e mais particularmente na engenharia de software , a Extreme Programming ( XP ) é um método ágil mais orientado para o aspecto de implementação de uma aplicação, sem descurar o aspecto de gestão de projetos . XP é adequado para pequenas equipes com necessidades variáveis. O XP leva os princípios simples ao extremo.
A programação extrema foi inventada por Kent Beck , Ward Cunningham e Ron Jeffries enquanto trabalhava em um projeto de cálculo da folha de pagamento “C3” na Chrysler. Kent Beck, gerente de projeto emMarço de 1996, começou a refinar o método de desenvolvimento usado no projeto. Este nasceu oficialmente em outubro de 1999 com o livro Extreme Programming Explained por Kent Beck .
No livro Extreme Programming Explained , o método é definido como:
Seu principal objetivo é reduzir os custos de mudança. Nos métodos tradicionais, as necessidades são definidas e geralmente fixadas no início do projeto de TI, o que aumenta os custos subsequentes de modificações. O XP se esforça para tornar o projeto mais flexível e aberto a mudanças, introduzindo valores, princípios e práticas essenciais.
Os princípios desse método não são novos: eles existem na indústria de software há décadas e nos métodos de gerenciamento há ainda mais tempo. A originalidade do método é levá-los ao extremo:
A programação extrema é baseada em ciclos de desenvolvimento rápidos (iterações de algumas semanas), cujos estágios são os seguintes:
O ciclo se repete enquanto o cliente puder fornecer cenários para entrega. Geralmente, o ciclo que antecede a primeira entrega é caracterizado pela sua duração e pelo grande volume de funções de bordo. Após o primeiro lançamento, as iterações podem se tornar mais curtas (uma semana, por exemplo).
Enquanto enfatiza as boas práticas de programação, o XP recomenda um desdobramento por iterações curtas e gerenciadas coletivamente, com envolvimento constante do cliente. O resultado é uma redefinição da relação entre cliente e fornecedor com resultados surpreendentes em termos de qualidade do código, prazos e satisfação do cliente .
A programação extrema baseada em cinco valores fundamentais.
ComunicaçãoEssa é a forma fundamental de evitar problemas. As práticas recomendadas pelo XP requerem comunicação intensa. O teste, a programação em pares e o jogo de planejamento forçam os desenvolvedores, tomadores de decisão e clientes a se comunicarem. Se, apesar de tudo, surge uma falta, o coach é responsável por identificá-la e colocar essas pessoas novamente em contato.
SimplicidadeA maneira mais fácil de obter o resultado é a melhor. Antecipar extensões futuras é perda de tempo. Um aplicativo simples será mais fácil de atualizar.
ComentáriosO feedback é essencial para o programador e o cliente. Os testes de unidade indicam se o código está funcionando. Os testes funcionais dão o andamento do projeto. As entregas frequentes permitem que a funcionalidade seja testada rapidamente.
CoragemAlgumas mudanças exigem muita coragem. Às vezes, você precisa alterar a arquitetura de um projeto, descartar o código para produzir um melhor ou tentar uma nova técnica. A coragem é a saída para uma situação inadequada. É difícil, mas a simplicidade, o feedback e a comunicação tornam essas tarefas acessíveis.
RespeitoEste valor foi adicionado na segunda edição de Extreme Programming Explained por K. Beck. Esse valor inclui respeito pelos outros, bem como respeito próprio. Os programadores nunca devem confirmar alterações que interrompam a compilação, façam com que os testes de unidade existentes falhem ou atrasem o trabalho de seus colegas. Os membros respeitam o próprio trabalho buscando sempre a qualidade e o melhor design para a solução e isso por meio da refatoração .
Esses cinco valores são divididos em treze práticas que se reforçam mutuamente:
Cliente no localUm representante do cliente deve, se possível, estar presente durante toda a duração do projeto. Ele deve ter o conhecimento do usuário final e ter uma visão global do resultado a ser obtido. Ele faz seu trabalho normal, estando disponível para responder às perguntas da equipe.
Jogo de planejamento ou pôquer de planejamentoO cliente cria cenários para a funcionalidade que deseja alcançar. A equipe avalia o tempo necessário para implementá-los. O cliente então seleciona os cenários de acordo com as prioridades e o tempo disponível.
Integração contínuaQuando uma tarefa é concluída, as alterações são imediatamente incorporadas ao produto completo. Isso evita a sobrecarga de trabalho relacionada à integração de todos os elementos antes da entrega. O teste facilita muito essa integração: quando todos os testes passam, a integração está completa.
Pequenas entregasAs entregas devem ser tão frequentes quanto possível. A integração e os testes contínuos reduzem drasticamente o custo de entrega.
Ritmo sustentávelA equipe não faz horas extras. Se for o caso, o cronograma deve ser revisto. Um desenvolvedor cansado funciona mal.
Testes de aceitação (ou testes funcionais)A partir dos cenários definidos pelo cliente, a equipe cria procedimentos de teste que permitem verificar o andamento do desenvolvimento. Quando todos os testes funcionais forem aprovados, a iteração estará concluída. Esses testes costumam ser automatizados, mas nem sempre é possível.
Na verdade, apenas os testes de não regressão podem ser potencialmente automatizados devido à sua recorrência.
A receita funcional de um aplicativo é cada vez mais confiada a especialistas de teste independentes dos desenvolvedores.
Testes de unidadeAntes de implementar um recurso, o desenvolvedor escreve um teste que verificará se seu programa se comporta conforme o esperado. Este teste será mantido até o final do projeto, enquanto a funcionalidade for necessária. Cada vez que o código é modificado, executamos todos os testes escritos por todos os desenvolvedores e sabemos imediatamente se algo não está mais funcionando.
Design simplesO objetivo de uma iteração é implementar os cenários selecionados pelo cliente e somente isso. Antever as próximas evoluções seria uma perda de tempo sem ter a garantia de um ganho subsequente. Os testes permitirão alterar a arquitetura posteriormente, se necessário. Quanto mais simples for o aplicativo, mais fácil será evoluí-lo nas próximas iterações.
Uso de metáforasMetáforas e analogias são usadas para descrever o sistema e como ele funciona. O funcional e o técnico são compreendidos muito melhor quando concordam nos termos que usam.
Refatoração (ou retrabalho de código)Melhoria regular da qualidade do código sem modificar seu comportamento. Nós retrabalhamos o código para começar de novo em uma base melhor, mantendo as mesmas funcionalidades. As fases de refatoração não trazem nada para o cliente, mas permitem que os desenvolvedores avancem em melhores condições e, portanto, mais rápido.
Propriedade coletiva do códigoA equipe é coletivamente responsável pelo aplicativo. Cada desenvolvedor pode fazer alterações em qualquer parte do código, mesmo aquelas que ele não escreveu. Os testes dirão se algo não funciona mais.
Convenção de nomesUma vez que todos os desenvolvedores estão envolvidos em todo o código, é essencial estabelecer e seguir padrões de nomenclatura para variáveis, métodos, objetos, classes, arquivos, etc.
Programação em paresA programação é feita em pares. O primeiro driver (ou piloto ) chamado segura o teclado. É ele quem trabalhará na parte do código a ser escrita. O segundo parceiro (ou co-piloto ) chamado está lá para ajudá-lo, sugerindo novas possibilidades ou detectando possíveis problemas. Os desenvolvedores frequentemente mudam de parceiros e funções, o que melhora o conhecimento coletivo do aplicativo e melhora a comunicação dentro da equipe.
Este método é baseado em:
Em vez da desvantagem do método, falaremos mais facilmente de ambientes desfavoráveis nos quais o método XP não é aplicável.
Nesse caso, apenas parte das práticas pode ser realizada. Os principais contextos desfavoráveis são: