XP + Kanban

XP originalmente usava iterações—uma ou duas semanas de trabalho planejado, depois uma demo e sessão de planejamento. Kanban usa fluxo contínuo: itens de trabalho se movem pelo sistema um de cada vez, sem lotes fixos.

Eles não são incompatíveis. As práticas centrais de XP funcionam com qualquer sistema de fluxo.

O que muda:

• Sem planejamento de iteração (você planeja just-in-time)
• Sem demos de iteração (você faz demo conforme as funcionalidades são concluídas)
• Sem velocity no sentido Scrum (você mede lead time e throughput)

O que permanece igual:

• TDD (ainda escreve testes primeiro)
• Programação em par (ainda colabora no código)
• Refatoração (ainda mantém o design limpo)
• CI (ainda integra continuamente)
• Releases pequenos (Kanban encoraja isso ainda mais)
• Envolvimento do cliente (ainda precisa de alguém para priorizar e aceitar)

As práticas técnicas são independentes de como você organiza o trabalho.

A prática característica do Kanban são os limites de WIP: restringir quanto trabalho está em progresso de uma vez.

Isso se alinha com os princípios de XP:

Foco: Limites de WIP evitam troca de contexto. XP valoriza foco (ritmo sustentável, pareamento para trabalho profundo).

Fluxo: Limitar WIP cria fluxo. Os releases pequenos e CI de XP também criam fluxo.

Qualidade: Menos WIP significa menos pressa. O foco em qualidade de XP se beneficia da pressão reduzida.

Termine o que você começou: Tanto Kanban quanto XP favorecem terminar em vez de começar. Não comece trabalho novo quando o trabalho existente pode ser concluído.

Pareamento e WIP: Se você programa em par, o WIP é naturalmente limitado. Duas pessoas em um item significa menos itens em andamento.

A sinergia é forte. As restrições do Kanban complementam o foco de XP em qualidade e conclusão.

Kanban empurra em direção à entrega contínua: cada item concluído é potencialmente liberável. As práticas de XP tornam isso possível.

Por que XP habilita entrega contínua:

• Testes: Cada funcionalidade é verificada automaticamente
• CI: O código está sempre integrado e compilável
• Design simples: Sem coordenação complexa de release
• Refatoração: O código permanece limpo e implantável
• Releases pequenos: Já é uma prática central de XP

Kanban sem práticas de XP luta para alcançar entrega contínua. Sem testes, você não pode ter confiança de que as coisas funcionam. Sem CI, a integração é incerta. Sem design simples, os releases são complexos.

Juntos: Kanban diz "entregue continuamente." XP diz "aqui está como."

ScrumBan combina Scrum, Kanban e (frequentemente implicitamente) XP:

Do Scrum:

• Ritmos regulares de planejamento (embora não necessariamente presos a sprints)
• Retrospectivas para melhoria
• Papel de Product Owner para priorização

Do Kanban:

• Quadro visual com limites de WIP
• Métricas de fluxo (lead time, throughput)
• Trabalho baseado em pull (pega o próximo item quando pronto)

Do XP:

• Práticas de engenharia (TDD, pareamento, etc.)
• Foco em qualidade
• Ritmo sustentável

Esse híbrido funciona bem para equipes que querem estrutura (Scrum) com fluxo (Kanban) e qualidade (XP).

O rótulo importa menos que as práticas. Use o que funciona; descarte o que não funciona.

Quando usar XP com iterações (estilo Scrum):

• Stakeholders querem incrementos de planejamento previsíveis
• A equipe se beneficia de ritmo e reflexão regulares
• O trabalho naturalmente se agrupa em entregas
• A organização pensa em sprints

Quando usar XP com fluxo (estilo Kanban):

• O trabalho chega de forma imprevisível (suporte, operações)
• Implantação contínua é o objetivo
• Limites de iteração parecem artificiais
• A equipe é madura o suficiente para se autogerenciar sem ritmo imposto

Qualquer abordagem funciona com práticas de XP. As práticas permanecem; o invólucro organizacional muda.

Muitas equipes evoluem do Scrum em direção ao Kanban conforme amadurecem. Iterações fornecem rodinhas de treinamento. Fluxo é o nível avançado. Mas não há nada de errado em ficar com iterações se elas funcionam para você.