Xp Comdex
Upcoming SlideShare
Loading in...5
×
 

Xp Comdex

on

  • 1,256 views

 

Statistics

Views

Total Views
1,256
Slideshare-icon Views on SlideShare
1,256
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Xp Comdex Xp Comdex Presentation Transcript

    • Extreme Programming Ricardo L. A. Bánffy Hiperlógica
    • Motivações
      • Requerimentos mutáveis
          • Não é mais possível projetar um sistema ao longo de 6 meses, implementá-lo ao longo de um ano, colocá-lo em produção e esperar que ele ainda resolva algum problema real
      • Limitação da complexidade
          • Custo de manutenção de um sistema aumenta com o tempo se a complexidade não for limitada
      • Agilidade
          • Releases frequentes garantem que problemas mais críticos são resolvidos mais cedo
          • Internet-time e vantagens de first-to-market
    • 12 práticas
    • 12 práticas
      • Processo de Planejamento (“Planning Game”)
      • Releases Frequentes
      • Metáfora do Sistema
      • O Mais Simples que Possa Funcionar
      • Testar Antes
      • Refactoring
      • Pair-Programming
      • Propriedade Coletiva do Código
      • Integração Contínua
      • Semanas de 40 Horas
      • Cliente Sempre Presente
      • Padrões de Codificação
    • Planning Game
      • Equipe de negócios (Cliente) escreve estórias (curtas) sobre funcionalidades do sistema, usualmente em cartões
      • Equipe técnica (Programadores) estima o custo das estórias
      • Cliente decide qual a duração do próximo ciclo
      • Cliente escolhe, com base nas estimativas dos programadores, quais estórias serão atendidas nesse ciclo e quais ficarão nos próximos ciclos
      • Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento
    • Releases Frequentes
      • Minimizam a quantidade de recursos investida em cada release
      • Ciclos curtos, na ordem de dias ou semanas, permitem retorno rápido sobre o investimento – funcionalidades importantes entrarão em funcionamento mais cedo
      • Todo o código pronto (que passa em todos os testes unitários) deve ser integrado e o sistema todo testado após a integração
    • Metáfora do Sistema
      • Comunica de forma clara o que se espera de um produto
      • Unifica a nomenclatura e estabelece uma linguagem cumum entre negócios e tecnologia
      • Ajuda os programadores a compreender o domínio do problema
    • O Mais Simples que Possa Funcionar
      • Menor complexidade diminui riscos – A complexidade é o inimigo
      • Software tende naturalmente a crescer e se tornar mais complexo (mais interações entre componentes distintos aumentam o risco de quebras em alterações)
      • Software é alterado durante sua vida útil – requerimentos mudam e o software pode se tornar mais complexo que os requerimentos necessitem
      • Garante que não serão gastos recursos em estórias que alguém “acha” que serão um dia necessárias
    • Testar Antes
      • Testes devem ser escritos ANTES de se codificar a funcionalidade do produto
      • Testes funcionam como documentação (embora não a substituam)
      • Escrever os testes obriga a pensar na forma como o componente será usado ANTES de codificá-lo
      • Um componente só está pronto se todas as formas com que ele for usado passarem nos testes correspondentes
    • Unit-testing (apêndice)
      • Testes devem ser automatizados para serem executados sempre que possível
      • Testes de difícil execução serão eventualmente abandonados
      • Tuda a funcionalidade que não estiver sendo testada ou deveria estar sendo testado ou não é necessária e deveria ser removida
      • Framework de testes (xUnit)
    • Refactoring
      • Código tende a se deteriorar ao longo do tempo
      • Soluções brilhantes de um dia parecem estúpidas depois de uma semana
      • Refactoring não deve acrescentar funcionalidade – apenas “limpar” a funcionalidade existente
      • É sempre recomendável fazer refactoring antes de acrescentar alguma funcionalidade
    • Pair-Programming
      • Duas cabeças pensam melhor do que uma
      • Uma cabeça obriga a outra a pensar no problema
      • Se um colega não entende o código ele não está suficientemente claro e não será entendido depois
      • Para promover o entendimento da solução, é desejável que as duplas sejam formadas por programadores com níveis diferentes de experiência
      • Funciona como um code-review em tempo real
      • Menos distrações (ICQ, Slashdot, e-mail)
    • Propriedade Coletiva do Código
      • Se algo está quebrado, complexo demais ou poderia ser melhorado, isso seve ser corrigido
      • Todos os programadores devem ser capazes de consertar qualquer código do sistema – não pode haver especialistas numa única parte
      • Evita dependência de profissionais
      • Promove o entendimento global da solução (sem caixas-pretas de funcionalidade)
    • Integração Contínua
      • A versão “oficial”, passando em todos os testes unitários e funcionais deve estar sempre disponível
      • Todo o novo desenvolvimento deve partir dessa versão
      • Todo código pronto (que passa em todos os testes) deve ser incorporado a essa versão assim que possível
    • Semanas de 40 horas
      • Horas extras e viradas de noite produzem código de baixa qualidade
      • Programadores devem ter uma vida própria para se manterem felizes, saudáveis e produtivos
      • Horas extras são um sinal de alarme para a equipe
      • Quando o programador acha que um prazo foi superestimado, vai deixar tarefas para depois e vai ter que virar noites no fim do período, pois é ele nunca vai lembrar que é extremamente raro superestimar prazos
    • Cliente Sempre Presente
      • Responde dúvidas melhor e mais rapidamente
      • Comunicação pessoal é mais eficiente do que por escrito
      • Programadores não devem tomar decisões para as quais não estão preparados (e pelas quais serão responsabilizados)
    • Padrões de Codificação
      • Se todos os programadores devem editar qualquer parte do código, eles precisam ser capazes de entendê-lo
      • Código deve ser mantido legivel para a “posteridade”, limitando o aumento de custo de manutenção ao longo do tempo
      • Os padrões não precisam ser arbitrários ou impostos com uso de violência – é desejável que sejam consensuais
    • Dificuldades
      • Cliente ausente
          • Procure um substituto para representar o cliente: um gerente de conta ou gerente de produto (quando o cliente for algo como “mercado”)
      • Mais de um cliente
          • Procure obter um único representante que tenha poder de decidir pelos vários interesses do cliente. Os clientes devem poder se reunir entre si antes de se reunir com a equipe técnica
      • Privacidade, ambiente hostil, ferramentas estranhas
          • Quando desenvolvedores resistem ao pair-programming, procure criar um espaço para pair-programming – máquinas dedicadas a isso com editores e OSs que os programadores prefiram
    • Dificuldades
      • Custos do pair-programming
          • Pair-programming é caro à primeira vista. Argumente que os programadores vão se dispersar menos e que o código será de melhor qualidade do que se estivessem trabalhando sozinhos
          • Às vezes pair-design é mais interessante. Algumas duplas planejam uma solução juntas e programam separadamente. Isso funciona às vezes
      • Algumas duplas não funcionam
          • Rearrange sempre as duplas. Algumas combinações vão funcionar melhor que outras. Fatores técnicos ou culturais podem influir
    • Dificuldades
      • Sistemas legados
          • É mais fácil começar o projeto em XP do que mudá-lo para XP durante sua execução. Procure fazer a transição em algum momento de descontinuidade (entrega de funcionalidade)
      • Propriedade do código
          • Programadores não podem ter “ciúmes” de suas criações
          • Encoraje o uso das mesmas linguagens e bibliotecas por toda a aplicação
    • Dificuldades
      • Dificuldades para testar
          • Sempre testar componentes quanto à funcionalidade.
          • Separação entre conteúdo e apresentação ajuda
          • Componentes de interface podem ser testados separadamente
          • Alguns componentes dependem de funcionalidade externa – testing frameworks podem ter que ser desenvolvidos para a sua plataforma (ex: zUnit)
          • Componentes devem ser construídos de forma a facilitar os testes
    • Dificuldades
      • Internet-Time
          • Pressões nos induzem a reverter a práticas menos adequadas (com as quais crescemos e que as gerências entendem melhor)
          • Ciclos podem se tornar curtos demais para funcionar
          • Tendência a abandonar testes acreditando que sacrificar qualidade poupe tempo (pode poupar, mas afeta a qualidade e a vida útil do software)
    • Para saber mais
      • www.extremeprogramming.org
      • www.xprogramming.com
      • www.xpdeveloper.com
      • www.hiper.com.br
      [email_address] Hiperlógica, sites automáticos Av. Brig. Faria Lima, 628 cj. 61 São Paulo • SP • 05426-000 (55 11) 3816 8067 www.hiper.com.br