uma metodologia adaptativapara desenvolvimento de software

Transcrição

1 do Minho, Outubro 24 1 extreme Progra ming uma metodologia adaptativapara desenvolvimento de software Ademar Aguiar ademar.aguiar@fe.up.pt XP é adequada para pequenasemédias equipas(2-12 elementos) lidar comrequisitos vagos ouemconstante alteração sistemas rapidamente testáveis emfracçõesde dia Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Extreme Progra ming (XP) O que é XP? Porquemotivotemmerecido tanta atenção? Emqueconsiste? Quando é apropriada? História 1990 Kent Beck começou a estudarformas melhores de desenvolver software, juntamente comward Cuningham 1996 Kent começou umprojecto na DaimlerChrysler onde usou novos conceitos para desenvolvimento O resultado foi a Extreme Programing Os quatro valoresfundamentaisparaumxp ersão -comunicação -simplicidade -feedback -coragem Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de XP é. lightweight (vs heavyweight ) eficiente debaixo-risco flexível e muito agradável de usar éuma disciplina adaptativa parao desenvolvimentode software XP distingue-se por. Feedback antecipadoe continuado através de curtosciclosde desenvolvimento Planeamentoincremental começandocomumplanoglobal quese espera evoluir ao longode todo o projecto Escalonamento flexível para responder às exigênciasdos clientes/negócio Testes escritos por programadorese clientes ajudamamonitorizar progresodo projecto dão segurança na evolução permitemdiagnosticar problemas rapidamente Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de

2 do Minho, Outubro 24 2 XP distingue-se por. Estruturae propósito do sistema comunicado oralmentee atravésde testes ecódigo Processode designevolutivo durante todaavidado sistema Estreita colaboração entre programadores semlhes exigir capacidades excepcionais Integrar práticas que se adaptambem aos objectivosde curto-prazodos programadores aos interesesde longo-prazodo projecto Controlo de Projectos Quatro variáveis de controlo Custo Tempo Qualidade Âmbito (da Funcionalidade) Não é posível fixaro valor de todas as variáveis simultaneamente O âmbito é a variável que nos oferecea mais valiosa forma de controlo Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Learning to Drive Conduzir nãoésó apontarocaro na direcção certa Éestar constantementecomatençãoà estrada Éfazer pequenas correcções paraumladoeparaooutro,sem nunca tirar os olhos da estrada Porto Braga Lisboa Custo de alterar ModeloAntigo Custo de Alteração Requisitos Análise Design Implementação Teste Produção Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Learning to Drive Aodesenvolversoftware Tudo muda:requisitos, design,negócio,tecnologia,equipa. Oproblema nãoéestar sempre tudoamudar Oproblemaé adificuldadeemconstantemente nos adaptarmosàmudança É necesário Muitofeedback emuita habilidadeemalterarcomcustos baixos Custodealterar. Novo Modelo? Custo de Alteração Tempo Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de

3 do Minho, Outubro 24 3 Comoreduziro custode alterar? Design simples semelementosextra necesários Testes automatizados confiança, segurançadasalterações Ter bastante práticaa alterar código semmedo, comcoragem atitude de constante refinamento do design (refactoring) Quadro de valores daxp Comunicação Testing, pairing and estimating requires that programers and customers need to co municate Simplicidade Do the simplest thing that could posibly work Feedback Ask the system, Code smels Coragem Fix it!, Tos it!, Test it! Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Ciclo típicode desenvolvimento Pares de programadores programamemconjunto O desenvolvimento é orientado por testes Test first, then code (add functionality) Os programadores evoluemo design do sistema, aumentando o seu valor sempre que é necesário A integraçãoé imediatamente efectuada apóso desenvolvimento, incluindo testes de integração Princípios fundamentais da XP Feedback Rápido Design o maissimples posível Alterações pequenase incrementais Assumir que as mudançassão inevitáveis Produzir trabalhode qualidade Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Desenvolvimento Adaptativo Especular Colaborar Aprender Práticas XP The Planning Game. Smal Releases. Metaphor. Simple Design. Testing. Refactoring. Pair Programing. Colective Ownership. Continuous Integration. 40-hour Week. On-site Customer. Coding Standards. Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de

4 do Minho, Outubro 24 4 Planning Game Clientes decidem Âmbito Prioridades Composiçãodas entregas Data dasversões/entregas Técnicosdecidem Estimativas Consequências Processo Escalonamentodetalhado (função do risco) The practices support each other. The weaknes of one is covered by the strengths of others. -Kent, 1999 Universidade do Minho, 24 de Outubro de Simple Design O designcorecto parao software éaquele que Pasa todos os testes Não temlógica repetida Declara tudo aquilo que é importante para os programadores Temo menor númerode clases e métodos Put in what you need when you need it Evitar Muitos hooks Sermuitoabstracto Projectado para o futuro longínquo e incerto. O futuroéincertoe éfácil alterar qdoé preciso Universidade do Minho, 24 de Outubro de Smal Releases Versõesmuitoreduzidasimplementandoos requisitosde maiorvalor parao cliente Utilização de ciclosmuitoreduzidos Anteciparversõescomvalor parao cliente Feedback rápido Sentidode responsabilidade Riscoreduzido Confiançado Cliente Ajuste aosrequisitos Testing Umpedaço de programa semumteste automatizado simplesmente não deve existir! Os testes de unidades dão confiança aos programadores na execução do sistema Os testes funcionaisidempara os clientes Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Metaphor Uma visão comumdo sistema Exemplos Umsistemade processamento de encomendas é como um tapete rolante onde vão sendo depositados materiais que vão sendo encaminhados para diversos pontos de saída onde serão processados The Internet is like air-trafic control, with al-powerful master controlers observing everything, teling each packet where to go. Refactoring Definição Uma série de pequenos pasos, cada umdos quais altera a estrutura interna do programa semalterar o seu comportamento exterior -Martin Fowler, 1999 Aoadicionarfuncionalidade Antes:existe algumaforma de alteraro programa que torne a adição mais simples? Depois: existe alguma forma de tornar o programa mais simples e passe todos os testes? Não fazer refactoring especulativamente, mas apenas quando o sistema e o processo o pedem Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de

5 do Minho, Outubro 24 5 Pair Progra ming Todoo códigoé escritoporduaspesoasnuma únicamáquinacomumtecladoe umrato. Duas pessoas, duas funções diferentes Táctica Comoimplementar estafuncionalidade? Estratégia Isto funciona? Quetestes não funcionarão? Como é que podemos tornar isto mais simples? Continuous Integration Ciclos curtos de Code and Test Integrare testar após poucas horas aadicionar funcionalidade -no máximo umdia If a test fails -you broke it! Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Colective Code Ownership O desenvolvimentode código comobjectos naturalmente se estende a todo o sistema -devese ir até onde seja necessário A coordenação de alteraçãodas classes é morosa e cria fortes resistências Don t coordinate, just do it; integrate frequently (Continuous Integration) 40-hour week Todos queremos Estar frescos e entusiasmadostodas as manhãs Estar cansados e satisfeitos todas as noites À sexta-feira, estar cansado e satisfeito o suficiente para se sentir emter dois dias para fazer algo que não trabalhar À segunda-feira, ir trabalhar cheio de vontade e ideias Trabalho fora-de-horas podeser umsintoma de problemas sériosno projecto :( Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Colective Code Ownership. Semprequealguémvêoportunidadede valorizar umpedaçode códigodeve fazê-lo logo Whoever finds a snake, kils it Permitea evolução rápida do sistema Todos são responsáveis por todo o sistema Os testes protegema funcionalidade do sistema Colective Code Ownership + Refactoring promovema reutilização Need it? Enhance it, subclas it, use it. Lots of programers, no waiting! On-Site Customer Umcliente deve sentar-se coma equipa, disponibilizar-se para responder a dúvidas e definir prioridades empequenos detalhes Não é posível pagar para ter umcliente na equipa? Se o sistema não merece o tempo do cliente, talvez não valha a penaserconstruído! -Kent, 1999 Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de

6 do Minho, Outubro 24 6 Coding Standards Colective code ownership, Pair programing e refactoring requerema definiçãode normas de escritade código O ideal: serimposível dizer quemescreveuoquê Asnormas devemsimplificaraomáximoo trabalho Reforçama comunicação entre todos na equipa Devemser adoptadas voluntariamentepor toda a equipa Considerar XP quando. Sedesenvolvenumcontexto de rápida mudança os requisitos são vagos e imprecisos Se valoriza suceso emvez de pompae circunstância Se valorizao trabalhoemequipa emvez de força-bruta Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Principais dificuldades da XP? Estarsemprea encontraras soluções maissimples Admitir faltade conhecimento e ter que aprender Colaborar comos restantes colegas de equipa Derubar bareiras emocionais para cooperar Mais Informação sobrexp Livros Extreme Programming Explained: Embrace Change -Kent Beck, 1999 Extreme Programming Installed -Ron Jefries, Ann Anderson and ChetHendrickson, 2000 Planning Extreme Programming -Kent Beck and Martin Fowler, 2000 Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de Zonasde turbulênciaparaa XP Grandes Especificações EspertoDemais. O TamanhoImporta Curva Exponencialde Custos de Alteração Feedback lento Testes? Não, obrigado! Mais Informação sobrexp. URL s Conferências XP 2000, Cagliary, Itália OOPSLA 2000, Minneapolis, EUA Universidade do Minho, 24 de Outubro de Universidade do Minho, 24 de Outubro de