XP - Extreme Programming
Engenharia de Software
Lewis Carroll
“Se você não sabe para onde você quer ir, qualquer caminho você pode seguir e
XP
– Extreme Programming
• Extreme Programming, mais conhecido simplesmente como XP, foi criado por Kent Beck nos anos 90, e
é um dos métodos ágeis que melhor cobre aspectos técnicos do desenvolvimento de software.
• O Extreme Programming (XP) utiliza uma abordagem “extrema” no desenvolvimento iterativo.
• Novas versões podem ser construídas várias vezes por dia.
• Incrementos são entregues aos clientes a cada 2 semanas.
• Todos os testes devem ser realizados em todas as versões e cada versão só é aceita se os testes forem concluídos com sucesso.
XP - Extreme Programming
• O desenvolvimento incremental é mantido através de releases de sistema pequenos e frequentes.
• O envolvimento do cliente significa compromisso do cliente com a equipe em tempo integral.
• “Pessoas e não processos” por meio de programação em pares, propriedade coletiva do código e um processo que evita longas horas de trabalho.
• Mudanças suportadas através de releases regulares de sistema.
Valores XP
• Comunicação
• O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em
desenvolvimento e possui algumas ideias sobre que funcionalidades podem resolvê-los.
• Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de
solucionar o problema do cliente.
• Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos
que precisam ser vencidos, é preciso que haja comunicação entre as partes.
XP prioriza o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de
Valores XP
• Feedback
• Feedback significa fazer perguntas e aprender com as respostas.
• A única maneira de saber o que o cliente realmente quer é perguntar a ele.
• A única maneira de saber se o código faz o que realmente deve fazer é testá-lo.
• Quanto mais cedo você pode obter feedback, mais tempo você tem para reagir.
XP fornece rápido e frequente feedback. As práticas XP apoiam o
Valores XP
• Simplicidade
• Construa apenas o que precisa ser construído.
• Não adicione complexidade desnecessária.
• Não tente prever o futuro.
• “Eu acho que vamos precisar disso no futuro, então, vou aproveitar e já fazer”.
O princípio YAGNI (You Ain’t Gonna Need It ou Você não vai precisar disso)
Valores XP
• Coragem
• Significa tomar as decisões duras quando necessário: se um recurso não está funcionando, corrija-o; se algum
código não é lá essas coisas, melhore-o; se você não vai ter como entregar tudo o que prometeu, informe ao cliente.
• A coragem é uma virtude difícil de aplicar. Ninguém quer estar errado ou quebrar uma promessa. A única
maneira de se recuperar de um erro, no entanto, é de admiti-lo e corrigi-lo.
Equipes XP consideram mudanças inevitáveis e procuram se adaptar a elas com segurança e com coragem.
Valores XP
• Respeito
• Para com os outros e para consigo mesmo.
• Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, caso se importem uns
com os outros. Respeito é o mais básico de todos os valores.
• Ninguém na equipe deve se sentir desvalorizado ou ignorado.
Mudanças e XP
• O senso comum da engenharia de software diz que se deve projetar pensando em mudanças.
• Vale a pena gastar tempo e esforço antecipando as mudanças já que, posteriormente, esse esforço reduz custos no ciclo de vida.
• No entanto, o XP afirma que isso não vale a pena já que as mudanças não podem ser antecipadas de forma confiável.
• Ao invés disso, propõe melhorias constantes do código (refatoração) para tornar as mudanças mais fáceis quando essas precisam ser implementadas.
Refatoração
• Refatorar é alterar a estrutura do código sem alterar o seu comportamento. É uma prática que permite que o desenvolvedor melhore o design do código, tornando-o mais limpo e fácil de se compreender.
• É uma técnica essencial para prevenir que o código se deteriore.
• Para que o desenvolvedor possa alterar o código com segurança de que o comportamento não será alterado, é essencial que o código possua uma boa base de testes.
“Qualquer idiota pode escrever código que um computador pode entender. Bons programadores escrevem código que seres humanos
Exemplos de Refatoração
• Reorganização de uma hierarquia de classes para remover código duplicado.
• Organização e renomeação de atributos e métodos para torná-los mais fáceis de entender.
Test-Driven Development (TDD)
• Escrever teses antes do código esclarece o que deve ser implementado.
• Os testes são escritos na forma de programas para que possam ser executados automaticamente.
• Os testes incluem checagem de que foram executados corretamente.
• Geralmente conta com um framework de testes como o Junit.
• Todos os testes anteriores e novos são executados automaticamente quando uma nova funcionalidade é adicionada, para checar se a nova funcionalidade não introduziu erros.
Envolvimento
do Cliente
• A função do cliente no processo de testes é ajudar a desenvolver testes de aceitação para as histórias que serão implementadas no próximo release do sistema.
• No entanto, a pessoa que assume a função de cliente tem tempo limitado disponível e não pode trabalhar em tempo integral com a equipe de desenvolvimento.
• Eles podem pensar que prover os requisitos seja contribuição suficiente e se tornarem relutantes em se envolverem no processo de testes.
Automação
de Testes
• A automação de testes significa que os testes são escritos como componentes executáveis antes que a tarefa seja implementada.
• Esses componentes de teste devem ser autômatos, devem simular a submissão de entrada para ser testada e devem avaliar se o resultado atende à especificação de saída Um framework de testes
automatizados (ex. Junit) é um sistema que facilita a escrita de testes executáveis e a submissão de um conjunto de testes para execução.
• Como os testes são automatizados, sempre existe um conjunto de testes que podem ser rapidamente e facilmente executados.
Programação em Pares
• Em XP, programadores trabalham em pares sentando junto para desenvolver código.
• Isso ajuda a desenvolver propriedade coletiva do código e espalha o conhecimento na equipe.
• Serve como um processo de revisão informal pois cada linha do código é observada por mais de uma pessoa.
• Encoraja a refatoração pois toda a equipe pode se beneficiar dessa atividade.
• Algumas avaliações sugerem que a produtividade do desenvolvimento com programação em pares é similar a de duas pessoas trabalhando independentemente.
Programação em Pares
• Na programação em pares os programadores sentam-se juntos na mesma estação de trabalho para desenvolver softwares.
• Os pares são criados dinamicamente para que todos os membros da equipe trabalhem com cada um dos outros membros durante o processo de desenvolvimento.
• O compartilhamento de conhecimento que acontece durante a programação em pares é muito importante por reduzir os riscos gerais de um projeto quando um membro da equipe vai embora.
Vantagens
da Programação em Pares
• Apoia a ideia da propriedade coletiva e responsabilidade pelo sistema.
• Os indivíduos não são responsabilizados por problemas no código. Ao invés disso, a equipe tem responsabilidade coletiva na solução desses problemas.
• Funciona como um processo de revisão informal porque cada linha de código é observada por pelo menos duas pessoas.
• Ajuda a apoiar a refatoração, que é um processo de melhoria do software.
• Em processos nos quais a programação em pares e a propriedade coletiva são usados, outros se beneficiam imediatamente da refatoração, o que provavelmente fará com que apoiem o processo.