05_4C-XP-1

Prévia do material em texto

Tema da Aula
..
..
Modelo Ágil – XP
Extreme Programming
Engenharia 
de
Software
eXtreme Programming
Criado por Kent Beck, Ron Jeffries e Ward Cunningham.
Disciplina de desenvolvimento de SW, voltada para equipes pequenas e médias e projetos com requisitos vagos ou que mudam freqüentemente.
Principal tarefa é a codificação.
Aborda: TDD, participação do cliente como membro da equipe, revisão permanente do código, refactoring, integração contínua, refinamento contínuo da arquitetura e planejamento.
Engenharia 
de
Software
XP
Engenharia 
de
Software
XP
Comunicação
	Práticas valorizam a comunicação, não limitada a procedimentos formais
Simplicidade
	Incentiva ao extremo práticas que reduzam a complexidade
Feedback
	Práticas garantem um rápido feedback sobre várias partes do projeto
Coragem
	Práticas aumentam a confiança dos desenvolvedores e do próprio cliente
Engenharia 
de
Software
Ciclo de Vida XP
Engenharia 
de
Software
Ciclo de Vida XP
Define escopo
Engenharia 
de
Software
Visão Geral XP
http://www.extremeprogramming.org/map/iteration.html
Engenharia 
de
Software
Práticas XP
Engenharia 
de
Software
Práticas XP
Whole Team (time coeso)
 Clientes faz parte da equipe
 Desenvolvedores devem ter múltiplas habilidades e competências
Engenharia 
de
Software
Práticas XP
Planning Games (jogos de planejamento)
Reunião no início da semana para priorizar as funcionalidades
Clientes apontam as prioridades, para a semana 
Uma semana = uma iteração
Desenvolvedores estimam tempo, esforço e custo
Envolvimento do cliente é imperativo
A cada iteração sabe que funcionalidades ser-lhe-ão entregues no final da semana
Escopo do projeto é revisto e atualizado semanalmente
Projeto deve ser regido por um contrato do tipo negociável
Engenharia 
de
Software
Práticas XP
Small Releases (pequenas entregas)
Disponibiliza a cada iteração SW 100% funcional
Versão disponibilizada imediatamente
Redução de riscos (se o projeto terminar, parte existe e funciona)
Detecção prévia de problemas
Comunicação entre cliente e desenvolvedor
Cada entrega possui funcionalidades prioritárias para a iteração
Release pode ser destinado a
usuário/cliente (testa, avalia e oferece feedback)
usuário/final (sempre que possível)
Engenharia 
de
Software
Práticas XP
Customer Tests (testes de aceitação)
São elaborados pelo cliente em conjunto com analistas e testadores
São automatizados
Quando rodarem com sucesso, funcionalidade foi implementada
Devem ser rodados a cada iteração
Ótimo feedback para o cliente
Pode se saber, a qualquer momento, o percentual de implementação do SW e quanto falta para concluir
Engenharia 
de
Software
Práticas XP
Collective Ownership (propriedade coletiva)
O código tem um único dono: a equipe
Qualquer par de programadores pode melhorar o código
Revisão constante do código
Aumenta a comunicação
Aumenta a qualidade (menos duplicação, maior coesão) e diminui os riscos de dependência de indivíduos
 Todos compartilham a responsabilidade pelas alterações
 Ideal que se troque os pares periodicamente
“Todos conhecem tudo”
Testes e integração contínua são essenciais e dão segurança
Engenharia 
de
Software
Práticas XP
Coding Standards (padrões para codificação)
Os padrões de codificação são definidos pela equipe
Organização de código
Nomenclaturas
Código com aspecto de escrito por um único desenvolvedor
Práticas e valores favorecidos
Posse coletiva
Comunicação
Programação em Pares
Refactoring
Projeto Simples
Engenharia 
de
Software
Práticas XP
Sustainable Pace (ritmo saudável)
Projetos vampiros não são projetos XP
Semanas de 40 horas
Código ruim, relaxamento da disciplina, stress da equipe
Tempo ganho será perdido depois
São aceitáveis eventuais horas extras quando a produtividade é maximizada
Engenharia 
de
Software
Práticas XP
Metaphor (metáfora)
Equipes XP mantém uma visão compartilhada do sistema
Analogia com outros sistemas (natural, computacional, abstrato)
Ótima fonte de comunicação entre a equipe, facilitando inclusive as estimativas
Pattern de alto nível
Corresponde ao “design arquitetural” nos demais modelos
Engenharia 
de
Software
Práticas XP
Continuous Integration (integração contínua)
XP mantém o SW integrado o tempo todo
Realizada pelo menos uma vez por dia
Para integrar, deve-se realizar os testes primeiro
“Reduz o tempo passado no inferno da integração” (Martin Fowler)
Benefícios
Expõe o estado atual de desenvolvimento
Oferece feedback
Estimula agilidade e versões freqüentes do SW
Engenharia 
de
Software
Práticas XP
Test-driven Development (Desenv. dirigido por Testes)
 XP valoriza o desenvolvimento dirigido por testes
São automatizados e executados o tempo todo
 Testes “puxam” o desenvolvimento
Cada unidade de código só tem valor se o teste funcionar 100%
 Testes dão coragem para mudar
De que adianta a OO isolar a interface da implementação se o desenvolvedor tem medo de mudar a implementação?
Engenharia 
de
Software
Práticas XP
Refactoring (refinamento do código)
 Design é melhorado continuamente por refinamento
Mudança proposital no código que está funcionando
Melhorar sua estrutura interna sem alterar a funcionalidade
Visa simplificar o código, remover o código duplicado
Principal referência é o catálogo de refactorings de Martin Fowler
Existência prévia de testes é fundamental para utilização desta prática (elimina o medo dos desenvolvedores de adotar a mudança)
Engenharia 
de
Software
Práticas XP
Simple Design (projeto simples)
Projeto está presente em todas as etapas XP
Projeto começa simples e se mantém assim através de testes e refinamento de código (refactoring)
Em XP, é levado ao extremo
Não é permitido implementar qualquer funcionalidade adicional que não será usada na iteração atual
Implementação ideal é aquela que
Passa por todos os testes
Expressa todas as idéias definidas no planejamento
Não contém código duplicado ou que “cheire”
Prever o futuro é impossível e é “anti-XP”
Engenharia 
de
Software
Práticas XP
Pair Programming (programação em pares)
SW é desenvolvido em pares
Duas cabeças juntas são melhores que duas separadas
1 piloto e 1 co-piloto
Papéis são alternados freqüentemente
Benefícios
Melhor qualidade de código (refactoring, testes)
Revisão constante do código
Nivelamento da equipe
Maior comunicação
“Um” pelo preço de “Dois”??
Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos.
Engenharia 
de
Software
Práticas XP
Test-driven Development (Desenv. dirigido por Testes)
Engenharia 
de
Software
XP
Metáforas ou histórias é escrita pelo cliente e colocada num cartão de indexação. O cliente atribui um valor para a história (priorizar) com base no valor de negócio global daquela função. Membros da equipe avaliam a história e lhe atribuem um custo, medido em semanas de desenvolvimento (Planning Poker).
	Se a história precisar de mais de 3 semanas de desenvolvimento, pede-se ao cliente para dividir a história em histórias menores e repete-se o processo.
Engenharia 
de
Software
XP
XP Projeto:
Segue o princípio “KIS” (Keep it simple).
Sugere a criação de “soluções de ponta” (spike solutions) como um protótipo operacional do projeto.
 Encoraja Refatoração (refinamento iterativo do projeto do programa).
Engenharia 
de
Software
XP
XP Codificação:
Recomenda a construção de uma unidade de teste antes de iniciar a codificação (protótipo).
Encoraja Programação Pareada
Engenharia 
de
Software
XP
XP Teste:
Todas as unidades de teste são executadas diariamente (casos).
Testes de Aceitação são realizados com o cliente para validar os releasesdo produto.
Engenharia 
de
Software
Papéis
Cliente:
Responsável por escrever “histórias” (story cards).
Muitas vezes é um programador ou é representado por um programador do grupo.
Trabalha no mesmo espaço físico do grupo.
Novas versões são enviadas para produção todo mês (ou toda semana).
Feedback do cliente é essencial.
Requisitos mudam (e isso não é mau).
Engenharia 
de
Software
Papéis
Treinador (Coacher):
Em geral, o mais experiente do grupo.
Identifica quem é bom no que.
Lembra a todos as regras do jogo (XP).
Eventualmente faz programação pareada.
Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias.
Seu papel diminui à medida em que o time fica mais maduro.
Engenharia 
de
Software
Papéis
Acompanhador (Tracker):
A “consciência” do time.
Coleta estatísticas sobre o andamento do projeto. Alguns exemplos:
Número de historias definidas e implementadas.
Número de testes unitários.
Número de testes funcionais definidos e funcionando.
Número de classes, métodos, linhas de código
Mantém histórico do progresso.
Faz estimativas para o futuro.
Engenharia 
de
Software
Adotando e Escalando XP
 Adote as práticas em doses homeopáticas
Não seja afobado, saboreie a mudança
Enfatize o problema mais importante
 Dificuldades culturais
Deixar alguém mexer no seu código
Pedir ajuda
Ânsia de tentar prever o futuro
Escrever testes antes de codificar
Refatorar com freqüência (superar o medo)
 Situações difíceis de aplicar XP
Equipes grandes e distribuídas geograficamente
Perda do controle sobre código
Feedback demorado
Engenharia 
de
Software
Adotando e Escalando XP
XP e os processos ágeis valorizam as pessoas
Bons desenvolvedores criam bons SWs
Processos ágeis são suplementos aos outros métodos
São atitudes
São efetivos
Não é um ataque à documentação e sim a criação de documentos que tem valor
Não são para todos
O segredo está na sinergia de suas práticas
Menos formalidade, mais diversão
Engenharia 
de
Software
Adotando e Escalando XP
Não provê documentação necessária
Dificuldades “após o projeto”
Funciona apenas para equipes experientes
Práticas disciplinadas e rigorosas
Pouca atenção ao projeto de software (arquitetura)
Em geral, a arquitetura é definida “de baixo pra cima”
Requer uma grande mudança cultural na organização para ser adotado
Ex.1: necessidade do cliente fazer parte da equipe
Ex.2: Patrocinadores do projeto querem saber exatamente o que será feito e quando
Engenharia 
de
Software
Quando usar o quê?
Engenharia 
de
Software
Notas sobre XP
XP não é para todo mundo, mas todo mundo pode aprender com ele.
Deixa o bom programador livre para fazer o que ele faria se não houvesse regras.
Força o [mau] programador a se comportar de uma forma similar ao bom programador.
Engenharia 
de
Software
Notas sobre XP
Engenharia 
de
Software
Notas sobre XP
http://agilemanifesto.org
http://www.agilemodeling.com
http://www.extremeprogramming.org
http://www.xprogramming.com
http://www.pairprogramming.com
http://www.martinfowler.com
http://wwwobjectmentor.com
http://www.c2.com
http://www.xispe.com.br