XP + Scrum
Usando a estrutura do Scrum com as práticas de engenharia do XP—o híbrido comum.
1Por Que Funcionam Juntos
O Scrum fornece estrutura organizacional. O XP fornece práticas de engenharia. Juntos, eles abordam lacunas diferentes:
O Scrum oferece:
- Papéis definidos (Product Owner, Scrum Master, Desenvolvedores)
- Ritmo (Sprints, eventos de Sprint)
- Artefatos (Product Backlog, Sprint Backlog, Incremento)
- Estruturas de responsabilidade
O XP oferece:
- Como escrever código bem (TDD, refatoração, design simples)
- Como colaborar no código (programação em par, propriedade coletiva)
- Como entregar de forma confiável (CI, pequenas entregas)
- Práticas de saúde da equipe (ritmo sustentável, padrões de código)
O Scrum é silencioso sobre como os desenvolvedores devem realmente codificar. O XP preenche essa lacuna.
A maioria das "equipes Scrum" bem-sucedidas está realmente fazendo Scrum + práticas de engenharia XP, quer chamem assim ou não.
Scrum sem práticas de engenharia se degrada com o tempo—a velocidade cai, bugs se acumulam, o moral sofre. As práticas XP previnem essa deterioração.
2Como Eles Se Mapeiam
Sprints = Iterações O sprint do Scrum é a iteração do XP. Com tempo limitado, focado, entregando software funcionando.
Product Backlog = Plano de Release O planejamento de release do XP cria o trabalho; o Product Backlog do Scrum o organiza.
Sprint Planning = Planejamento de Iteração Mesma atividade: decidir o que construir nesta iteração, dividir em tarefas.
Daily Scrum = Standup Diário Mesma intenção: sincronizar a equipe, expor bloqueios.
Retrospectiva de Sprint = Retrospectiva O XP não prescreve retrospectivas tão rigidamente, mas a prática é a mesma.
User Stories Funcionam em ambas as abordagens. O Scrum não prescreve o formato; o formato de história do XP funciona bem.
Sprint Review = Demo As demos de iteração do XP são essencialmente Sprint Reviews.
A terminologia difere; as práticas se alinham.
3O Que o XP Adiciona ao Scrum
Equipes Scrum que adotam práticas XP normalmente veem:
Melhor qualidade de código: TDD detecta bugs cedo. Refatoração mantém o design limpo. Propriedade coletiva espalha conhecimento.
Velocidade mais previsível: Quando a qualidade é alta, a velocidade se estabiliza. Sem desacelerações surpresa por correção de bugs.
Ritmo sustentável: O XP explicitamente nomeia e protege isso. O Scrum pode se tornar um "sprint" no sentido errado—sempre pressionando.
Colaboração aprimorada: Programação em par constrói relacionamentos. Propriedade coletiva quebra silos.
Melhoria contínua: O princípio de melhoria do XP mais as retrospectivas do Scrum criam uma combinação poderosa.
Padrão comum: Equipes começam com Scrum porque é organizacional. Elas adicionam práticas XP conforme amadurecem. A combinação é mais poderosa do que qualquer uma sozinha.
Uma equipe usa sprints de duas semanas (Scrum), TDD e programação em par (XP), e realiza retrospectivas para melhorar continuamente. O Product Owner define prioridades; desenvolvedores são donos de como o trabalho é feito. A qualidade é alta; a entrega é previsível.
Uma equipe tem sprints, standups e um Product Owner. Mas eles não testam efetivamente, nunca refatoram, e a qualidade do código declina. Cada sprint parece mais difícil que o anterior. 'Ágil não está funcionando.'
4Tensões Potenciais
Embora XP e Scrum funcionem bem juntos, algumas tensões existem:
Scrum Master vs. Auto-Organização do XP O XP assume que a equipe se auto-organiza profundamente. O Scrum adiciona um papel (Scrum Master) para facilitar. Estes podem coexistir, mas se o Scrum Master se tornar uma estrutura de comando, a auto-organização do XP sofre.
Compromisso de Sprint vs. Flexibilidade do XP O Scrum enfatiza o compromisso de sprint. O XP enfatiza responder à mudança. Se o compromisso se tornar rígido, a adaptabilidade do XP é perdida.
Definição de Pronto vs. Qualidade Contínua A "Definição de Pronto" do Scrum pode se tornar uma lista de verificação. As práticas de qualidade do XP são contínuas. Garanta que a DoD reflita a qualidade XP, não apenas "testes passam."
Velocidade como Métrica O Scrum frequentemente rastreia velocidade. O XP alerta contra velocidade como meta (ela é manipulada). Use velocidade para planejamento, não medição de desempenho.
Essas tensões são gerenciáveis. A chave é manter os princípios do XP vivos enquanto usa a estrutura do Scrum.
Risco de Culto de Carga
Algumas equipes 'fazem Scrum' (as cerimônias) sem adotar práticas XP. Elas têm sprints mas não TDD, standups mas não programação em par. Isso é forma sem substância—e não entrega benefícios ágeis.
5Fazendo Funcionar
Para combinar Scrum e XP efetivamente:
Use a estrutura do Scrum:
- Sprints para ritmo
- Product Owner para prioridades
- Scrum Master para facilitação
- Eventos de Sprint para cadência
Adicione as práticas do XP:
- TDD para todo código de produção
- Programação em par (pelo menos para trabalho complexo)
- Propriedade coletiva (sem silos de código)
- Integração contínua (várias vezes ao dia)
- Refatoração (como parte de cada história)
- Ritmo sustentável (sem horas extras)
Mantenha os princípios do XP:
- Qualidade é inegociável
- Comece onde você está e melhore
- Abrace a mudança
- Feedback em todas as escalas
Muitas equipes descobrem essa combinação naturalmente. Elas começam com Scrum, percebem que precisam de práticas de engenharia, e adicionam XP. O resultado é frequentemente chamado de "ágil bem feito."
- Scrum fornece estrutura organizacional; XP fornece práticas de engenharia
- A maioria das equipes Scrum bem-sucedidas usa práticas XP, explicitamente ou não
- Sprints = iterações, Sprint Review = demo, Retrospectiva de Sprint = retro
- XP adiciona qualidade, previsibilidade e sustentabilidade ao Scrum
- Fique atento a tensões em torno de compromisso, velocidade e auto-organização
- •Fazer cerimônias Scrum sem práticas XP (forma sem substância)
- •Usar velocidade como métrica de desempenho (ela é manipulada)
- •Tornar o compromisso de sprint rígido em vez de flexível
- •Deixar o Scrum Master se tornar um gerente