Extreme Programming

Manifesto do Desenvolvimento Ágil www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP. Indivíduos e interações mais que processos e ferramentas. Trabalhar no software mais que documentação abrangente. Colaboração do cliente mais que negociação contratual. Responder às mudanças mais que seguir um plano.

O que é XP? Processo de desenvolvimento de software Projetos com requisitos muito voláteis Equipes pequenas (até ~10 pessoas) Desenvolvimento incremental

O que é um projeto de sucesso? Cumpre o orçamento Cumpre o prazo Cliente fica feliz Equipe fica feliz

Premissas do desenvolvimento Cliente é capaz de especificar um software antes de iniciar o desenvolvimento Equipe de desenvolvimento é capaz de quantificar o esforço Equipe é capaz de criar o software imaginado pelo cliente Cliente ficará feliz

Resumo Divisão nítida entre “produção” e “consumo” Cliente produz uma especificação que é consumida pela equipe de desenvolvimento Equipe de desenvolvimento produz o software que é consumido pelo cliente

Motivação: custo de uma alteração Tempo de Projeto Custo $ 1 Requisitos $ 10 Análise $ 100 Design $ 1.000 Implem. $ 10.000 Testes

Premissas Básicas do Modelo Tradicional É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

Por que software falha?

Problemas desta premissa Premissa é irreal em vários casos O cliente não é capaz de especificar o software previamente Grande problema: DETALHE

Premissa do desenvolvimento ágil APRENDIZADO FEEDBACK DESENVOLVIMENTO ITERATIVO

Aprendizado O cliente aprende durante o desenvolvimento Descobre novas possibilidades Muda as prioridades

Trabalho intelectual Retrabalho é uma característica do trabalho intelectual Experimentação Criação Revisão Experimentação ...

Premissa: custo de uma alteração Tempo de Projeto Custo Mudanças nas últimas 3 décadas: Computadores 1000 vezes mais rápidos Computadores 1000 vezes mais baratos Ciclo de compilação e testes baixou de dias para segundos DBMS CM Tools CASE Tools Sobretudo OO

E se essa fosse a realidade? A atitude dos desenvolvedores de software seria completamente diferente: Tomaríamos as grandes decisões o mais tarde possível. Implementaríamos agora somente o que precisamos agora. Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

E essa é a nova realidade ! (pelo menos em muitos casos) Orientação a Objetos facilita e cria oportunidades para mudanças Técnicas de Refatoramento possibilita melhorar continuamente a implementação aumentando constantemente a qualidade do código produzido Testes automatizados nos dão segurança quando fazemos mudanças Prática / cultura de mudanças aprendemos técnicas e adquirimos experiência em lidar com código mutante

As 4 Variáveis do Desenvolvimento de Software Tempo Custo Qualidade Escopo (foco principal de XP)

Valores Feedback Comunicação Simplicidade Coragem

User Stories Funcionalidades são informadas através de user stories Estórias devem ser simples Desenvolvedores estimam tempo

Planejamento De posse das estimativas, é possível priorizar Cliente entrega as estórias priorizadas para serem implementadas Desenvolvedores respeitam as prioridades dos clientes Projeto é dividido em partes: releases e iterações

Priorização Cliente deve priorizar as estórias Para obter o máximo de valor rapidamente Se baseia nas suas necessidades e nas estimativas dos desenvolvedores

Release e Iteração Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4 No início do projeto, deve-se determinar o número máximo de estórias e estimá-las. A estimativa é sempre feita pelos programadores. Ao mostrar os releases, dizer que no início de cada um se faz o release planning. Nele, o cliente indica as estórias que devem ser feitas. Esta estórias podem mudar ao longo do release, de acordo com as priridades do cliente. No início de cada iteração, ocorre o iteration planning. O cliente decide o que será feito na iteração. Ao contrário do release planning, o cliente não pode alterar as estórias que serão executadas em uma iteração. Elas ficam completamente congeladas. No início de cada semana, a equipe planeja as tarefas que serão executadas ao longo da semana. No início de cada manhã, a equipe faz um stand up meeting. 1 Sem. S1 S2

Release Planning Cliente recebe um “orçamento” dos desenvolvedores 8 Sem. Cliente recebe um “orçamento” dos desenvolvedores Seleciona as estórias prioritárias que possam ser implementadas dentro do orçamento Pode trocar estórias durante o release

Iteration Planning Cliente recebe um “orçamento” 2 Sem. Cliente recebe um “orçamento” Não pode haver troca de funcionalidades durante uma iteração Velocidade: quantidade de estórias que a equipe consegue implementar em uma iteração

Stand-up meeting Reunião rápida Diária Usada para atualização da equipe

Desenvolvimento: orientação a objetos Sistema é composto por pequenas peças Peças têm objetivos específicos Facilita construção Facilita evolução

Buscando bugs Sistemas podem ter defeitos É difícil descobrir qual é a peça defeituosa É mais fácil se o problema for detectado logo após a adoção da peça

Test Driven Design No XP, primeiro se especifica o teste Depois se constrói a peça

Unit Test Nome dado à verificação feita sobre cada peça Cada peça possui um unit test associado a ela Testes são automatizados Quando uma nova peça entra no sistema, todos os testes são executados

Acceptance Test Cliente deve especificar testes de aceitação para cada funcionalidade de uma iteração Sistema deve passar nestes testes ao término da iteração

Pair Programming Todo código é escrito em par Duas pessoas trabalham em um único computador Uma digita, enquanto a outra revisa, corrige e sugere

Collective code ownership Todos são responsáveis por todas as partes do sistema Código tem que estar sempre “limpo” Todos são capazes de modificá-lo

Refactoring Uma [pequena] modificação no sistema que não altera o seu comportamento funcional mas que melhora alguma qualidade não-funcional: simplicidade flexibilidade clareza desempenho

Exemplos de Refactoring Mudança do nome de variáveis Mudanças nas interfaces dos objetos Pequenas mudanças arquiteturais Encapsular código repetido em um novo método Generalização de métodos raizQuadrada(float x) raiz(float x, int n)

Desenvolvimento em equipe Como conciliar diversos desenvolvedores? Estrutura de diretórios Atualização do código por várias pessoas diferentes

CVS – Repositório de fontes Check out Add Commit Update Conflict Remove

CVS

40 hour week Desenvolvimento de software é um trabalho intelectual intenso Não é produtivo trabalhar além do limite

Customer onsite Fator mais importante no XP: Comunicação Feedback Viabiliza a simplicidade da metodologia War room c / quadro branco

Feedback constante Permite que pequenas mudanças sejam feitas Evita a necessidade de mudanças bruscas Mantém o projeto em curso

Integração contínua Máquina destacada para a integração Integração ocorre diversas vezes ao dia Os testes são executados em cada integração Correções são feitas imediatamente

Ambientes para deployment Como lidar com diferentes ambientes? Exemplo: Desenvolvimento Aceitação Produção

Ambientes para deployment Desenvolvimento Aceitação Produção

Problemas de ter vários ambientes Possíveis erros devido a tarefas manuais repetitivas Gasto de tempo

Automatização do deployment Agiliza as integrações Evita erros

Ant

Exemplo simples <project name="projeto" default="desenvolvimento"> <target name="desenvolvimento"> <mkdir dir="build"/> <javac srcdir="src" destdir="build"/> <junit> <test name="test.SystemTester"/> </junit> </target> </project> tasks target

Ambiente de Desenvolvimento Desejável que tenha: Code completion Validação on-line Suporte à depuração Suporte a Refactoring Integração com jUnit Integração com CVS Integração com Ant

Exemplos

Importância da IDE para o XP Ganho de tempo Automação Facilidade de uso Verificação permanente do código

Importância da IDE para o XP

Steering Pequenas mudanças Ajustes simples ao longo do tempo X

Segredo do sucesso O conjunto é o que faz a diferença A ausência de uma prática mostra a deficiência de outras Metáfora do time de futebol

XP e RUP XP RUP Foco nas práticas da equipe Foco nos artefatos Comportamental Prescritivo Projetos de determinados tamanhos Qualquer projeto

Negociação Venda técnica Venda focada em negócio Duas propostas: Escopo fechado Escopo variável

Resistências Dificuldades com a área de TI Grande resistência dos desenvolvedores Pouca resistência na área usuária do cliente Estratégia: pedido de tempo

Ambiente de desenvolvimento Sala dedicada unicamente ao projeto Mural Quadros brancos Mesas que suportam programação em par Equipamentos com bom desempenho

XP no Brasil 2000: algumas práticas começam a ser usadas em projetos no Sul Dez/2002: primeiro XP Brasil Jan/2003: fundação do XP Rio Fev/2003: primeiro projeto full-XP em uma grande empresa brasileira (em andamento) Nov/2003: lançamento previsto do primeiro livro brasileiro sobre XP

Referências Site Xispê http://www.xispe.com.br XP Rio http://www.yahoogroups.com/groups/xprio Lista Xpers http://www.yahoogroups.com/groups/xpers