Extreme Programming XP

Extreme Programming XP

1. Geral

   • Metodologia Ágil
     • Criador
       • Objetivo
         • Adaptar-se a Mudanças
           • Foco em Testes Frequentes
             • Ajustes Rápidos
               • Qualidade do Software
       • Kent Beck (1996)
       • Manifesto Ágil
       • Diverge do Modelo Cascata (Waterfall)

2. 5 Valores Fundamentais

   • O Alicerce do Extreme Programming
   • Comunicação
     • Aberta e frequente entre equipe e stakeholders.
   • Feedback
     • Contínuo de clientes e colegas para ajustes rápidos no software.
   • Simplicidade
     • Priorizar soluções mais simples (Princípio KISS - Keep It Simple, Stupid).
   • Coragem
     • Incentivar a tomada de decisões difíceis e a busca constante por melhorias.
   • Respeito
     • Promover uma cultura de colaboração e diversidade.

3. Princípios

   • Diretrizes para a Tomada de Decisão
   • Feedback Rápido
     • Troca de informações constante para identificação e correção imediatas de problemas.
   • Assumir a Simplicidade
     • Resolver problemas da forma mais simples no momento, confiando na capacidade da equipe para lidar com complexidades futuras.
   • Mudança Incremental
     • Realizar melhorias e mudanças de forma gradual, em vez de grandes transformações.
   • Abraçar Mudanças
     • Valorizar a inclusão de novos requisitos em qualquer estágio do projeto.
   • Trabalho de Qualidade
     • A qualidade é obrigatória (atender aos requisitos, passar em todos os testes e agregar valor).

4. Práticas Essenciais

   • Planejamento/Cliente
     • Cliente Presente
       • O cliente participa ativamente do desenvolvimento para garantir comunicação clara e resolver dúvidas rapidamente
     • Jogo do Planejamento (User Stories)
       • Cliente define prioridades com base em User Stories (custo/tempo). O cliente escreve funcionalidades em User Stories, que são avaliadas pela equipe quanto a tempo e custo, permitindo ao cliente priorizar
     • Relises e Iterações
       • Releases (versões pequenas com funcionalidades completas) são colocadas em produção rapidamente. São divididas em iterações de, geralmente, duas semanas
   • Qualidade/Código
     • Testes de Unidade
       • TDD - Test Driven Development (Desenvolvimento guiado por teste) Testes automatizados escritos antes da codificação para guiar o desenvolvimento.
     • Refactoring
       • Reorganizar o código constantemente para melhorar a qualidade interna, leitura e manutenção, sem alterar o comportamento externo
     • Código Coletivo
       • Qualquer membro pode trabalhar em qualquer parte do sistema.
     • Código Padronizado
       • Estabelecer um padrão de codificação para homogeneidade e compreensibilidade.
     • Integração Contínua
       • Construir o software várias vezes ao dia, mantendo a sincronia e executando todos os testes para rápida detecção e correção de defeitos
   • Trabalho/Equipe
     • Pair Programming
       • Dois desenvolvedores trabalham juntos no mesmo computador, com um revisando o código do outro. Isso promove revisão constante e disseminação do conhecimento
     • Reuniões Diárias
       • Reuniões de, no máximo, 10 minutos para que cada desenvolvedor comente o que realizou e priorize as atividades do dia 
     • Ritmo Sustentável
       • Trabalhar dentro dos limites físicos e mentais (máximo de 8 horas diárias/40 semanais) para manter a criatividade e qualidade
     • Metáforas
       • Usar vocabulário familiar ao cliente para transmitir ideias complexas e criar uma visão comum do projeto

5. Ciclo de vida

   • Histórias dos Usuários
     • Requisitos são transformados em User Stories.
     • Espiga Arquitetônica
       • Estabelecimento da arquitetura básica do sistema.
       • Planejamento de Lançamento
         • Priorização e organização das histórias para as iterações.
         • Iteração
           • Implementação e testes contínuos das funcionalidades.
           • Testes de Aceitação
             •  Validação das histórias dos usuários para garantir que atendam aos requisitos.
             • Pequenas Versões (Releases)
               • Lançamento regular de versões incrementais do software, permitindo feedback.

6. Gestão e Papéis

   • A gestão é descentralizada
   • Treinador (Coach)
     • Foca na execução técnica, comunicação, conhecimento e suporte à equipe.
   • Rastreador (Tracker)
     • Coleta e compara métricas (Tempo estimado vs. gasto) e monitora o progresso.
   • Programadores
     • Analisam, projetam, testam, codificam e integram o sistema.
   • Clientes
     • Definem prioridades e colaboram na definição dos testes funcionais.

7. Quando não usar

   • Equipes Grandes
     • Geralmente com mais de 12 programadores, onde a comunicação é dificultada.
   • Clientes Ausentes
     • Se os clientes não estão dispostos a participar ativamente.
   • Tecnologias Incompatíveis
     • Tecnologias que não suportam mudanças ou não permitem a escrita fácil de testes.
   • Cultura Tradicional
     • Organizações com cultura tradicional (muita documentação e ênfase em análise prévia) terão dificuldade na transição.