Kent Beck criou o Extreme Programming (XP) para levar as práticas ágeis a níveis extremos, com foco no código, testes frequentes, feedback constante e comunicação entre a equipe. O XP envolve atividades como codificação, teste, escuta de clientes e modelagem para desenvolver software com requisitos vagos de forma ágil.

1. Extreme Programming

2. Kent Beck Criador do XP Programming e Test Driven Development

3. Engenheiro de software Popularizoucartões CRC e desenvolveu o JUnitjunto a Erich Gamma Kent Beck

4. Leva as práticas benéficas de outros modelos de desenvolvimento a níveis “extremos”, na teoria de que se algo é bom, mais é melhor. Programação Extrema

5. Metodologiaágilparaequipespequenas e médias. Desenvolvimento de softwares com requisitosvagos e emconstantemudança. Constanteacompanhamento e realização de váriospequenosajustesdurante o desenvolvimento. O Queé?

6. Codificar Testar Ouvir Modelar Atividades

7. O único produto realmente importante do processo de desenvolvimento de software é o código. Sem o código, não há um produto funcional. Pode-se usar código para facilitar a comunicação: o código é sempre claro e conciso, não possibilitando ambiguidade. Codificar

8. Se alguns testes podem eliminar algumas falhas, muitos testes podem eliminar muitas falhas. Testes de Unidade determinam se uma funcionalidade funciona como desejado. Testes de aceitação determinam se os requisitos compreendidos pelos programadores satisfazem o cliente. “Testathon”: evento em que programadores se juntam para desenvolver testes, como um “brainstorm de testes”. Testar

9. Programadoresdevemouvir o que o clienteprecisaque o sistemafaça. Deve-se compreender as necessidades o suficienteparapassar um feedbacksobrecomopodemserresolvidas, ounãopodem. Ouvir

10. Um bom modelo evita várias dependências no sistema, de forma que alterar uma parte do sistema não afeta as outras. Na teoria seria mais simples apenas codificar, mas após um certo ponto o sistema se torna muito complexo e suas dependências deixam de ser claras. Modelar

11. Comunicação Simplicidade Feedback Coragem Respeito Valores

12. Passar a todososdesenvolvedoresumavisão do sistemaqueequivaleàvisão dos usuáriosfinais. Designs simples Metáforascomuns Colaboração de usuários e desenvolvedores Comunicação verbal frequente. Comunicação

13. Começar com a solução mais simples. Funcionalidades extras podem ser adicionadas depois. Não investir em requisitos que podem ser alterados antes de se tornarem relevantes. Facilidade na Comunicação. Simplicidade

14. Feedback do Sistema: testes de unidade, testes de integração. Feedback direto do estado do sistema. Feedback do Cliente: testes funcionais, de aceitação. O cliente pode direcionar o desenvolvimento. Feedback da Equipe: novos requisitos, alteração nos requisitos. A equipe estima diretamente o tempo de implementação. Feedback

15. Reestruturar o código quando necessário. Revisar o sistema atual e modificá-lo para que futuras implementações sejam mais simples. Saber quando descartar código obsoleto, não importando o esforço de sua implementação. Persistência! Pode-se perder um dia inteiro em um problema e resolvê-lo rapidamente no dia seguinte. Coragem

16. Respeitopelos outros e peloprópriotrabalho. Programadoresnuncadevemsubmeteralteraçõesquedeixam de compilar, fazem testes de unidadeexistentesfalharemouatrasam de alguma forma o trabalho de outros. Ninguémdeve se sentirignorado: alto nível de motivação e dedicaçãoaoprojeto. Respeito

17. Jogo do planejamento: reuniãosemanal entre desenvolvedores e clienteemque se identificamprioridades e estimativaspara as funcionalidades. Reuniõesempé:reuniõessemanaisrápidasabordandotarefasrealizadas e tarefas a realizar. Projeto simples:desenvolverestritamente o necessário, sem se preocuparemimplementarfuturasfuncionalidades antes do tempo. Práticas

18. Teste de aceitação: testes construídospeloclienteparaaceitar um determinadorequisito de sistema. Padrões de codificação: a equipe de desenvolvimentodeveestabelecerregras de codificaçãoparatodososdesenvolvedores. Integraçãocontínua:nuncaesperarparaintegrar a nova funcionalidadedesenvolvida, issosóaumenta a chance de conflitoouerro. Práticas

19. Programaçãoem pares:Duaspessoasprogramam juntas no mesmocomputador. Desta forma o códigosempreérevistoporduaspessoas, diminuindo a ocorrência de erros. Práticas

20. Métodotãoeficientequanto as pessoasenvolvidas. Necessitade de reuniõesfrequentes. Podelevar a dificuldadescontratuais. Falta de documentaçãorobusta. Críticas