Upload
cjr-unb
View
551
Download
0
Embed Size (px)
DESCRIPTION
Visão geral da metodologia de desenvolvimento XP Programming feita pelo Trainee Artur de Azevedo no dia 19/05/2011
Citation preview
Extreme Programming
Kent Beck
Criador do XP Programming e Test Driven Development
• Engenheiro de software• Popularizou cartões CRC e desenvolveu o
JUnit junto a Erich Gamma
Kent Beck
• 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
• Metodologia ágil para equipes pequenas e médias.• Desenvolvimento de softwares com requisitos vagos e
em constante mudança.• Constante acompanhamento e realização de vários
pequenos ajustes durante o desenvolvimento.
O Que é?
• Codificar• Testar• Ouvir• Modelar
Atividades
• 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
• 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
• Programadores devem ouvir o que o cliente precisa que o sistema faça.
• Deve-se compreender as necessidades o suficiente para passar um feedback sobre como podem ser resolvidas, ou não podem.
Ouvir
• 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
• Comunicação• Simplicidade• Feedback• Coragem• Respeito
Valores
• Passar a todos os desenvolvedores uma visão do sistema que equivale à visão dos usuários finais.
• Designs simples• Metáforas comuns• Colaboração de usuários e desenvolvedores• Comunicação verbal frequente.
Comunicação
• 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
• 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
• 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
• Respeito pelos outros e pelo próprio trabalho.• Programadores nunca devem submeter
alterações que deixam de compilar, fazem testes de unidade existentes falharem ou atrasam de alguma forma o trabalho de outros.
• Ninguém deve se sentir ignorado: alto nível de motivação e dedicação ao projeto.
Respeito
• Jogo do planejamento: reunião semanal entre desenvolvedores e cliente em que se identificam prioridades e estimativas para as funcionalidades.
• Reuniões em pé: reuniões semanais rápidas abordando tarefas realizadas e tarefas a realizar.
• Projeto simples: desenvolver estritamente o necessário, sem se preocupar em implementar futuras funcionalidades antes do tempo.
Práticas
• Teste de aceitação: testes construídos pelo cliente para aceitar um determinado requisito de sistema.
• Padrões de codificação: a equipe de desenvolvimento deve estabelecer regras de codificação para todos os desenvolvedores.
• Integração contínua: nunca esperar para integrar a nova funcionalidade desenvolvida, isso só aumenta a chance de conflito ou erro.
Práticas
• Programação em pares: Duas pessoas programam juntas no mesmo computador. Desta forma o código sempre é revisto por duas pessoas, diminuindo a ocorrência de erros.
Práticas
• Método tão eficiente quanto as pessoas envolvidas.
• Necessitade de reuniões frequentes.• Pode levar a dificuldades contratuais.• Falta de documentação robusta.
Críticas