*********************************************** ********** ENG - Extreme Programming ********** *********************************************** Data : 01/04/2004 a 02/04/2004 Versão : 04/07/2007 Professor: Fabrício Jailson Barth Autor : Leandro Salvador ( leandrosalvador.com.br ) * Links - www.extremeprogramming.org * Introdução - XP é uma nova abordagem para desenvolvimento de software - XP possui regras e práticas simples que num primeiro momento parecem inábeis e ingênuas, mas rapidamente se tornam mudanças bem-vindas - os clientes são parceiros no processo e os desenvolvedores contribuem ativamente independentemente da experiência - a teoria e a prática devem se suportar mutuamente - atividades improdutivas são aparadas para reduzir custos e frustrações - XP pode ser implementada aos poucos na metodologia atual ou de uma única vez - de qualquer forma, muitos benefícios serão incorporados a qualquer projeto - a qualidade do código é muito importante em um projeto XP - práticas focadas na qualidade incluem programação em par, refactoring e criar testes antes do código - o teste ocupa o lugar de honra - boas unidades de teste e a cobertura de testes de aceitação é a marca de um projeto XP - um projeto XP traz a atitude que os desenvolvedores são responsáveis por provar ao cliente que o código trabalha corretamente, não o cliente provar que o código possui problemas - o cliente deve sempre estar disponível - é desejável que a equipe seja composta por desenvolvedores capazes de prosseguir em paralelo, corajosamente fazendo mudanças em qualquer parte do sistema exigido, mas também é desejável um integração livre de erros destes esforços * O que é XP - Extreme Programming (XP) é uma aproximação deliberada e disciplinada para desenvolvimento de software - XP é bem sucedida porque atinge a satisfação do cliente - a metodologia é desenhada para entregar o software que o seu cliente necessita quando ele é necessário - XP encoraja os desenvolvedores a sentirem-se confiantes em mudar as exigências do cliente, mesmo no final do ciclo de vida - XP também enfatiza o trabalho em equipe - gerentes, clientes e desenvolvedores são todos parte de um time dedicado em desenvolver um software de qualidade - XP implementa um caminho simples, porém efetivo, de estilo de desenvolvimento em grupo - XP melhora um projeto de software em basicamente quatro caminhos - comunicação - simplicidade - feedback - coragem - programadores XP comunicam-se com seus clientes e seus companheiros de equipe - eles deixam o design simples e limpo - eles pegam feedback testando o software desde o primeiro dia - eles entregam o sistema para o cliente tão cedo quanto possível e implementam mudanças como sugerido - com esses fundamentos programadores XP são capazes de responder corajosamente a mudanças de exigências e tecnologias - XP é muito parecido com um quebra-cabeça - há muitas pequenos pedaços - individualmente as peças não fazem sentido, mas quando combinadas juntas, pode-se ver uma figura completa - XP é uma partida significativa dos métodos de desenvolvimento de software tradicionais e resulta em uma mudança no modo de programar * Uma Mudança no Modo de Programar - XP é baseada na idéia de que software feito de forma simples e elegante é mais valioso do que software complexo e difícil de manter - um projeto típico gasta em torno de vinte vezes mais em pessoal do que em hardware - isto significa que um projeto de 2 milhões de dólares em programadores por ano gastará em torno de 100 mil dólares em computadores por ano - digamos que os programadores são espertos e eles encontram uma maneira de economizar 20% dos custos em hardware através de alguns truques de programação muito sofisticados - isto fará o código mais difícil de entender e manter, mas economizará 20% (ou 20 mil dólares) por ano, uma grande economia - agora e se ao invés de escrever programas assim os programas forem simples de entender - pode-se esperar economizar não menos do que 10% do custo com pessoal (ou 200 mil dólares), uma economia muito maior - isto com certeza é algo que o cliente irá observar - um outro ponto importante para o cliente são os bugs - XP enfatiza não apenas testar, mas testar bem - testes são automatizados e provêem uma rede segura para programadores e clientes - testes são criados antes, durante e depois de o código ser escrito - como bugs são encontrados novos testes são adicionados - os bugs não aparecem duas vezes, e isto é algo que o cliente irá notar - outra atitude que o cliente irá notar é a atitude que os programadores XP têm para mudar exigências - XP nos encoraja a realizar mudanças - freqüentemente um cliente verá uma oportunidade real de fazer o sistema mais útil depois de ter sido entregue - XP acelera isto pegando o feedback do cliente cedo enquanto ainda há tempo para mudar a funcionalidade ou aumentar a aceitação do usuário - muito do que está na XP é uma reavaliação da maneira como o software é criado - a qualidade do código é muito mais importante do que um simples recurso - o fato de o cliente não ver o código não significa que não deveríamos nos esforçar em criar algo do qual podemos nos orgulhar * Quando Usar XP - XP foi criada como resposta aos tipos de problemas que necessitam de mudanças freqüentes - em muitos ambientes de software a única constante é a mudança dinâmica - é nestes casos que a XP será bem sucedida enquanto outras metodologias falharão - XP também foi projetada para focar-se nos problemas relacionados ao risco do projeto - se o cliente precisa de um novo sistema até uma data específica o risco é alto - se o sistema é um novo desafio para a equipe de desenvolvimento o risco é ainda maior - se o sistema é um novo desafio para toda a indústria do software o risco é ainda muito maior - as práticas da XP são ajustadas para diminuir o risco e aumentar a probabilidade de sucesso - XP é ajustada para pequenos grupos de programadores, entre 2 e 12, embora projetos maiores de 30 foram bem sucedidos - os programadores podem ser medianos, não são necessários programadores com Ph.D. para usar XP - mas XP não pode ser usada em projetos com muita gente - deveríamos notar que em projetos com exigências dinâmicas ou alto risco uma equipe pequena de programadores XP será melhor que um grante tipo - XP requer um time de desenvolvimento prolongado - o time XP inclui não apenas os desenvolvedores, mas os gerentes e clientes também, todos trabalhando juntos lado a lado - fazendo perguntas, negociando escopo e calendário, e criar testes funcionais requerem mais que apenas os desenvolvedores estarem envolvidos em produzir o software - uma outra exigência é a testabilidade - deve-se ser capaz de criar unidades automatizadas e testes funcionais - enquanto algumas coisas serão desqualificadas por esta exigência, você ficará surpreso com quantas não serão - é necessário aplicar pequenos testes ingênuos em algumas coisas - pode ser que seja necessário mudar o desenho do sistema para facilitar o teste - lembre-se que onde há vontade, há um caminho para teste - a última coisa na lista é produtividade - projetos XP unanimemente relatam maior produtividade de programação quando comparados a outros projetos com o mesmo ambiente corporativo - mas este nunca será o objetivo a metodologia XP - o objetivo real sempre foi entregar o software necessário quando necessário - se isto é o importante para o projeto, então pode ser a hora de utilizar XP * Necessidade de uma Outra Metodologia - muitas vezes o software parece uma oficina cujas ferramentas estão todas desordenadas e o trabalho não pode ser feito porque não é possível começar nada - XP foi baseada em observações do que faz um programa de computador mais rápido ou mais devagar - XP é uma nova metodologia importante por dois motivos - o primeiro e mais importante é a re-examinação das práticas de desenvolvimento de software que se tornaram procedimentos de operação padrão - o segundo é que esta é uma de diversas novas metodologias de software leve (com poucas regras, práticas e documentos) - XP tem poucas regras e um modesto número de práticas, todas fáceis de seguir - XP é um ambiente de desenvolvimento limpo e conciso, observando o que faz o desenvolvimento de software ir mais rápido ou mais devagar - este é um ambiente em que os programadores sentem-se livres para serem criativos e produtivos mas cotinuem organizados e focados * O Cliente Está Sempre Disponível - um dos poucos requisitos da XP é ter o cliente disponível - não apenas para ajudar o time de desenvolvimento, mas para ser parte dele - todas as fases de um projeto XP requerem comunicação com o cliente, de preferência face a face, no local - para o cliente poderá parecer muito tempo e o departamento responsável por liberar o funcionário tentará passar um trainee como um expert - você precisa do expert * Padrões de Codificação - o código deve estar formatado de acordo com o padrão de codificação - padrões de código deixam o código consistente e fácil para todo o time ler e refabricar (refactor) * Codificar o Teste Unit Antes - criar os testes primeiro, antes do código, torna muito mais fácil e rápido criar o código - esta combinação entre criar uma unidade de teste e criar algum código para fazer isto passar é quase o mesmo que codificar direto - mas, se já é possível ter os testes não será necessário criá-los depois, economizando algum tempo agora e muito depois - criar um teste unitário ajuda o desenvolvedor a realmente considerar o que precisa ser feito - as exigências são fixadas firmemente pelos testes - não pode haver qualquer engano em uma especificação escrita em forma de código executável - além disso o feedback é feito imediatamente enquanto se trabalha, o que freqüentemente não está claro quando um desenvolvedor termina toda a funcionalidade necessária - se criamos nossos testes unitários antes então sabemos quando estamos prontos: todos os testes unitários rodaram - há também um benefício para o desenho do sistema - geralmente é muito difícil testar alguns sistemas de software - estes sistemas costumam ser codificados antes e testados depois, freqüentemente por um time completamente diferente - criando testes antes o desenho será influenciado por um desejo de testar tudo de valor para o cliente - o desenho refletirá isto sendo mais fácil de testar - há um ritmo para desenvolver o software de teste unitário antes - você cria um teste para definir algum pequeno aspecto do problema em mãos - então você cria o código mais simples que fará o teste passar - então você cria um segundo teste - agora você adiciona ao código que criou para fazer este novo teste passar, mas não até você ter um terceiro teste ainda - você continua até não haver mais nada para testar * Par de Programadores - todo o código incluído em uma liberação de produção é criado por duas pessoas trabalhando juntas em um único computador - o par de programadores incrementa a qualidade do software sem impactar o prazo de entrega - isto é aparentemente contraditório, mas duas pessoas trabalhando em um único computador adicionará muito mais funcionalidade do que duas trabalhando separadamente, sem contar que possuirá muito mais qualidade - o aumento de qualidade traz grandes economias mais tarde no projeto - a melhor maneira de programar em par é apenas sentarem-se lado a lado em frente do monitor - uma pessoa escreve e pensa taticamente sobre o método sendo criado, enquanto a outra pensa estrategicamente sobre como o método se ajusta na classe - leva tempo para se acostumar com a programação em par, mas não se preocupe se isto parecer ilógico no começo * Integração Seqüencial * Integração Freqüente - os desenvolvedores deveriam estar integrando e liberando código no repositório de códigos a cada poucas horas, sempre que possível - em qualquer caso nunca prenda as mudanças por mais do que um dia - a integração contínua freqüentemente evita divergência ou fragmentação de esforços de desenvolvimento, onde os desenvolvedores não estão comunicando-se sobre o que pode ser reutilizado, ou o que poderia ser compartilhado - todos precisam trabalhar com a versão mais atualizada - as mudanças não deveriam ser feitas em códigos obsoletos causando dores de cabeça na integração - cada par de desenvolvimento é responsável por integrar seu próprio código todas as vezes em que houver um intervalo razoável - isto pode ser quando os testes unitários tiverem sido rodados a 100% ou alguma porção da funcionalidade planejada estiver terminada - apenas um par integra num dado momento e apenas após algumas horas codificando para reduzir o problema potencial para quase nada - integração é uma atividade do tipo "pague-me agora ou pague-me mais depois" * O Código Pertence a Todos - a propriedade coletiva do código encoraja todos a contribuirem com novas idéias em todos os segmentos do projeto - qualquer desenvolvedor pode mudar qualquer linha de código para adicionar funcionalidade, corrigir bugs ou fazer refactor - ninguém se transforma em um obstáculo para mudanças - se o time inteiro já tem alguma responsabilidade pelas decisões de arquitetura, não deveriam receber a autoridade também? - o modo de funcionamento é para cada desenvolvedor criar testes unitários para seu código assim que é desenvolvido - todo o código que é liberado no repositório de código inclui testes unitários - o código que é adicionado, erros como são corrigidos, e antigas funcionalidades como são mudadas serão cobertas pelo teste automático - agora você pode confiar na suíte de testes para checar todo o repositório - antes de qualquer código ser liberado ele deve passar por toda a suíte de testes a 100% - uma vez que o código estiver no lugar qualquer um pode fazer nudanças em qualquer método de qualquer classe e liberar isto no repositório de código conforme necessário - quando combinado com integração freqüente os desenvolvedores raramente anunciam que uma classe foi extendida ou reparada - na prática a propriedade coletiva do código é realmente mais confiável do que colocar uma única pessoa encarregada de cuidar de classes específicas - especialmente porque uma pessoa pode deixar o projeto a qualquer tempo * Otimize Depois - não otimizar até o fim - nunca tente adivinhar o que será o funil do sistema, meça isto - faça o sistema trabalhar, faça isto certo, então faça isto rápido * Não Trabalhar Acima do Tempo Estipulado - trabalhar acima do tempo estipulado suga o espírito e a motivação do time - projetos que requerem tempo extra para serem concluídos no prazo estarão atrasados não importa o que você faça - ao invés disso faça uma reunião de planejamento de liberação (cronograma) para mudar o escopo do projeto ou tempo - aumentar os recursos adicionando mais pessoas também é uma má idéia quando o projeto está atrasado * Testes Unitários - testes unitários são uma das pedras preciosas da XP - mas o estilo de testes XP é um pouco diferente - primeiro você deveria criar ou baixar um framework de teste unitário (unit test framework) para ser capaz de criar suítes de testes automatizadas - depois você deveria testar todas as classes no sistema - os triviais métodos getter e setter são geralmente omitidos - e por último você deveria tentar criar suas próprias suítes de teste, antes do código ----------//----------