Extreme Programming Régis Simão e Ciro Coelho

Agenda Introdução Valores Ciclo de Vida Práticas Documentação Equipe Quando não usar XP Como implantar Bibliografia

Introdução Livros

Introdução Livros – The XP Series

Introdução Outras Referências Site: Grupos: www.improveit.com.br/xp http://tech.groups.yahoo.com/group/xprio http://br.groups.yahoo.com/group/xprecife http://tech.groups.yahoo.com/group/xp-rs http://br.groups.yahoo.com/group/xpnorte http://tech.groups.yahoo.com/group/xpsc http://tech.groups.yahoo.com/group/xpbh http://tech.groups.yahoo.com/group/xpsp

Introdução Extreme Programming (XP) é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento de sistemas orientados a objetos; Equipes pequenas, preferencialmente até 12 desenvolvedores; Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. Fonte: Livro Extreme Programming. Autor Vinícius Manhães Teles

Valores Feedback Comunicação Simplicidade Coragem

Valores Feedback Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, gerando feedback para a equipe de desenvolvimento. É o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente. Garante que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.

Valores Comunicação O XP busca aproximar todos os envolvidos do projeto Permite que o cliente compartilhe o seu aprendizado com a equipe Promover a comunicação face-a-face ou da forma mais rica que for viável. A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem.

Valores Feedback e Comunicação

Valores Simplicidade Temos que implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. Ao codificar, deve-se preocupar apenas com os problemas de hoje. Deve-se deixar os problemas do futuro para o futuro. As generalizações devem ser feitas quando elas vierem na forma de uma necessidade específica e não como uma especulação.

Valores Coragem “A equipe precisa ser corajosa e acreditar que, utilizando as práticas e valores do XP, será capaz de fazer o software evoluir com segurança e agilidade.” “Em muitos casos, a equipe alterará algo que vinha funcionando corretamente, o que leva ao risco de gerar falhas no sistema.” TELES, Vinícius M. Extreme Programming. Novatec Editora, 2006

Ciclo de Vida Desenvolvimento Tradicional Desenvolvimento Ágil Ciclo Semanal

Ciclo de Vida Desenvolvimento Tradicional Ciclo de Vida em Cascata Forte influência da Revolução Industrial Software construído linearmente, seguindo uma seqüência de fases Definição de Requisitos Projeto de Software Implementação e teste de unidade Integração e teste de sistema Operação e Manutenção

Ciclo de Vida Desenvolvimento Tradicional Ciclo de Vida em Cascata Base de vários processos de software Interpretação errada do ciclo de vida do Rational Unified Process (RUP)

Ciclo de Vida Desenvolvimento Tradicional Características do Ciclo de Vida em Cascata Linearidade Determinístico Especialização Foco na execução

Ciclo de Vida Desenvolvimento Ágil Categorias de Trabalhadores (Drucker, 1999. In: Teles, 2006) Trabalhador Manual Habilidades Manuais Fácil de Automatizar Determinístico Repetitivo Trabalhador do Conhecimento Uso intensivo de conhecimento e criatividade O XP vê o desenvolvimento de software como um processo de uso intensivo de conhecimento e criatividade

Ciclo de Vida Desenvolvimento Ágil Ciclo de Vida Incremental Definir esboço dos requisitos Atribuir requisitos aos incrementos Projetar arquitetura do sistema Desenvolver incremento do sistema Validar incremento Integrar incremento Validar sistema Sistema incompleto Sistema final

Ciclo de Vida Desenvolvimento Ágil Ciclo de Vida em Espiral

Ciclo de Vida Desenvolvimento Ágil Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

Ciclo de Vida Ciclo Semanal Validação parcial com o cliente Definição com o cliente Teste Desenvolvimento Avaliação pelo cliente Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

Ciclo de Vida Ciclo Semanal Feedback e Aprendizagem Fonte: Palestra Extreme Programming, abraçando a mudança. Autor Helder da Rocha

Práticas Jogo do Planejamento Cliente Presente Stand Up Meeting Desenvolvimento guiado pelos Testes Programação por Pares Refactoring Código Coletivo Código Padronizado Design Simples Ritmo Sustentável Integração Contínua Releases Curtos Metáfora

Práticas Jogo do Planejamento É uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração. Visa assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente a cada dia de trabalho. O projeto é dividido em Releases e Iterações. Cliente e a equipe podem revisar o planejamento constatemente. As funcionalidades são descritas em pequenos cartões e são chamadas de Estórias.

Práticas Jogo do Planejamento Exemplos de Estórias (Teles, 2006): Apresente ao cliente as dez tarifas mais baratas para uma determinada rota (Beck, 2001). Para cada conta, computar o saldo fazendo a adição de todos os depósitos e a subtração de todas as deduções (Jeffries, 2001). Produzir um extrato para cada conta, mostrando a data, o número, o beneficiário e a quantia da transação. Segue um extrato de exemplo em anexo – faça o relatório parecer com o exemplo (Jeffries, 2001). A tela de login deve permitir que o usuário pule o login. Neste caso, o usuário entrará no sistema como guest (Newkirk, 2001). O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, último nome e filiação). Dois campos de senha para confirmação (Newkirk, 2001).

Práticas Jogo do Planejamento Estórias São sempre escritas pelo próprio cliente. Criam um vínculo com o cliente. Formalizam o pensamento do cliente. Não têm formato de escrita. Devem ser limitadas pelo tamanho do cartão, simplicidade. Podem ser dividas em tarefas, quando muito complexas. Dão a noção de custo. Cada desenvolvedor seleciona uma estória ou tarefa a ser feita em um determinado prazo.

Práticas Jogo do Planejamento Estimativas Estimativa baseada no conceito de Dia Ideal de Desenvolvimento (só para implementação). Estima-se cada estória com a unidade Ponto (dia ideal de desenvolvimento). No canto superior esquerdo do cartão, colocam-se os pontos estimados. No canto superior direito do cartão, ficam os pontos realmente consumidos. A estimativa deve ser por comparação. A estimativa deve ser feita em equipe. O cliente deve sempre participar. Velocidade é a quantidade de pontos que uma equipe implementou na iteração anterior.

Práticas Jogo do Planejamento Exemplo de Planejamento de uma Iteração de 2 semanas: 2 semanas = 10 dias úteis 1 dia útil para a reunião de planejamento da iteração 1 dia útil para a reunião de encerramento da iteração Dias úteis disponíveis para o desenvolvimento = 10 – 2 = 8 Números de desenvolvedores = 6 = 3 x 2 = 3 pares 1 par / dia = 1 ponto 1 par em 8 dias = 1 x 8 = 8 pontos 3 pares em 8 dias = 3 x 8 = 24 pontos

Práticas Jogo do Planejamento Não iniciado Em andamento Finalizado Acompanhamento Visual Não iniciado Em andamento Finalizado Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

Práticas Cliente Presente O cliente deve estar presente durante o desenvolvimento. Presente em: Reuniões de Planejamento das Releases e das Iterações Reuniões de Encerramento das Releases e das Iterações Alguns momentos do desenvolvimento para tirar dúvidas e validar algumas informações. O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema. A presença do cliente simplifica a comunicação.

Práticas Stand Up Meeting Reunião rápida que a equipe de desenvolvimento faz a cada manhã para avaliar o trabalho do dia anterior e priorizar aquilo que será implementado no dia. Três perguntas devem ser respondidas por cada desenvolvedor: O que foi feito no dia anterior? O que vai ser feito hoje? Tem algo atrapalhando ou necessário para o trabalho a ser realizado? Os problemas relatados devem ser tratados fora da reunião!

Práticas Desenvolvimento Guiado pelos Testes Os desenvolvedores escrevem testes para cada funcionalidade antes de implementá-las. Benefícios: melhoram o entendimento sobre as necessidades do cliente, projetam melhor as interfaces externas dos métodos e classes e limitam até onde codificar cada funcionalidades. Tipos de Testes: Testes de Unidade sobre cada classe, criado e executado pelo Desenvolvedor Testes de Aceitação sobre funcionalidade ou estórias, escrito pelo cliente e pelo Analista de Testes, executado principalmente pelo cliente

Práticas Desenvolvimento Guiado pelos Testes Exemplo de um Teste de Unidade Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).

Práticas Desenvolvimento Guiado pelos Testes Exemplo de um Teste de Unidade Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).

Práticas Desenvolvimento Guiado pelos Testes Exemplo de um Teste de Aceitação Fonte: Livro Extreme Programming, Autor: Vinícius Manhães Teles

Práticas Programação em Pares A implementação é sempre feita por duas pessoas. Enquanto uma pessoa implementa, a outra avalia o código que está sendo feito, realizando uma revisão constante. A cada 15 minutos, a pessoa que está implementado passa a fazer a avaliação e a outra implementa. A cada turno as duplas trocam.

Práticas Programação em Pares Benefícios: Desafios: Aumenta a produtividade Melhora a solução Dissemina conhecimento de negócio Nivela habilidades Desafios: Organização do escritório Visão gerencial Relacionamento humano Competição

Práticas Refactoring O refactoring é a técnica de alterar o código sem alterar a funcionalidade. O objetivo é fazer o código ficar mais simples de ser manipulado. Anda de mãos dadas com o código coletivo e testes de unidades. Existem livros específicos sobre técnicas de refactoring.

Práticas Código Coletivo Procura evitar “ilhas de conhecimento”. Quando só uma pessoa conhece uma solução, pode ser um gargalho no desenvolvimento. Com a programação em pares, os desenvolvedores passam a ser conhecedores de todas as funcionalidades. Eles têm acesso a todas as funcionalidades, podendo alterá-las sem necessitar de autorização, inclusive fazendo refactoring.

Práticas Código Padronizado A equipe deve estabelecer padrões de implementação que devem ser seguidos por todos. Isto agiliza as manutenções e torna o código mais homogêneo. Exemplo: Code Conventions for the Java Programming Language da SUN Writting Robust Java Code de Scott Ambler Características de um padrão: Indentação Letras maiúsculas e minúsculas Comentários Nome

Práticas Código Padronizado Quando alguém encontra algo fora do padrão deve-se: Alertar a equipe o que está fora do padrão e forma correta de fazer. Fazer refactoring do código, colocando-o no padrão. Dificuldades Ter um padrão. Se não tiver, utilize um pronto! Mudança de hábito.

Práticas Design Simples Para ser ágil, a equipe deve optar por um código que seja suficiente para atender as necessidades atuais do cliente. Necessidades futuras serão atendidas quando elas forem requisitadas, fazendo-se uso do refactoring e testes, por exemplo. A única coisa constante em um projeto de software é a mudança (Beck, 2000. In: Teles, 2006): Os requisitos mudam O design muda A tecnologia muda A equipe muda Os membros da equipe mudam

Práticas Design Simples Estratégia do XP para um código simples (Teles, 2006): Comece escrevendo um teste para funcionalidade a ser desenvolvida. Faça o design e implemente apenas o suficiente para passar nos testes. Repita os passos 1 e 2 quantas vezes forem necessárias. Se você identificar a oportunidade de tornar o design mais simples, faça-o.

Práticas Design Simples Ferramentas: Utilize as ferramentas mais simples. Se desejar gerar documentações e diagramas, lembre que tem que mantê-las atualizadas. A documentação sempre tem que refletir o código, senão não serve pra nada! Documente as decisões importantes.

Práticas Ritmo Sustentável Os desenvolvedores devem trabalhar apenas 8 horas por dia. As horas-extras devem ser evitadas. Isto para permitir que os desenvolvedores se mantenham atentos, criativos e dispostos a solucionar os problemas. Sugestão: 08:00 às 08:30  Ler e-mails 08:30 às 09:00  Stand Up Meeting 09:00 às 12:00  Programação em Pares 14:00 às 17:00  Programação em Pares 17:00 às 17:30  Ler e-mails 17:30 às 18:00  Estudo para refactoring

Práticas Integração Contínua Consiste da equipe integrarem seus códigos com o restante do sistema várias vezes ao dia. Para garantir que o sistema esteja funcionando corretamente após uma integração, é necessário realizar todos os testes (testes de regressão). Código avança através de três fases: local, candidato à liberação e disponibilizado no repositório Utilize uma máquina em separado para a integração: backup e “ritual”.

Práticas Integração Contínua Ferramentas: Ferramenta de build Sistema de controle de versão O processo de integração é feito corretamente quando: Deve ser fácil e rápido obter o código fonte do qual você necessita; Deve ser fácil e rápido armazenar as suas mudanças; O repositório deve detectar conflitos e é importante que seja simples resolvê-los; Não deve haver espera, isto é, se um par precisa editar alguma coisa, ele deve seguir adiante sem que nada o impeça.

Práticas Releases Curtos A equipe deve produzir um conjunto pequeno de funcionalidades (release) Colocar a release em produção rapidamente para que o cliente possa fazer uso das funcionalidades o mais cedo possível. Durante o projeto, a equipe colocará diversas versões do sistema em produção, gerando um fluxo contínuo de valor para o cliente. Aumenta Feedback Aumenta o Retorno do Investimento

Práticas Releases Curtos Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

Práticas Metáfora A equipe de desenvolvimento transmite idéias complexas de forma simples através de metáforas. A metáfora do time de futebol para entender a utilização das práticas de futebol

Documentação Por que documentar? Até que ponto documentar? Permitir que rapidamente um desenvolvedor possa criar ou manter um código. Até que ponto documentar? O suficiente para apoiar o código: testes de unidade, testes de aceitação e outras documentações. Quando documentar? Próximo da implementação (antes ou depois), para que o negócio não mude enquanto se documenta. Dentro da mesma iteração.

Documentação Sugestão de Documentação Estórias Testes de Aceitação Testes de Unidade Javadoc Modelo de Classes Modelo de Dados Processo de Negócio Manual do Usuário Acompanhamento Diário Acompanhamento do Projeto Fotos

Equipe Gerente de Projeto Coach Analista de Teste Redator Técnico Desenvolvedor

Equipe Gerente de Projeto Coach Analista de Teste É responsável pelos assuntos administrativos do projetos. Libera a equipe de questões não ligadas ao desenvolvimento. Administra o relacionamento com o cliente, assegurando que o mesmo participe ativamente do desenvolvimento. Coach É o responsável técnico pelo projeto. Orienta a equipe nas boas práticas do XP. Pode atuar na implementação, mas a sua função principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente. Analista de Teste É responsável por ajudar o cliente a escrever os testes de aceitação. Quando o teste não é automático, ele deve executar os testes diversas vezes ao longo das iterações.

Equipe Redator Técnico Desenvolvedor Ajuda a equipe a documentar o sistema. A equipe pode fazer documentação, mas a preocupação principal deve ser o código. O redator é quem faz a maior parte do trabalho de documentação. Desenvolvedor É a pessoa que analisa, projeta e codifica. Não existe distinção entre analista, projetista e programadores. O desenvolvedor faz estes diferentes papéis em diversos momentos do projeto.

Quando não usar XP Sistemas de premiação individuais Contratos de escopo fechado Clientes que fazem questão de um grande número de artefatos Empresas onde os layouts de escritórios são fixos Quando não se tem apoio das pessoas que decidem Equipes grandes e espalhadas geograficamente Situações onde não se tem controle sobre o código (sistemas legados) Situações onde o feedback é demorado

Como implantar Uma prática de cada vez Dificuldades culturais Enfatize o problema mais importante Dificuldades culturais Deixar alguém mexer no seu código Trabalhar em pares Dificuldades devido a mudança de hábitos Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível") Jogar fora código desnecessário Escrever testes antes de codificar Refatorar com freqüência (vencer o medo)

Bibliografia TELES, Vinícius M. Extreme Programming. Novatec Editora, 2006. TELES, Vinícius M. Workshop sobre Desenvolvimento Ágil. 2007. DA ROCHA, Helder. Palestra sobre Extreme Programming: abraçando a mudança. 2002.

FIM!!!