Scrum e programação extrema (XP) são definitivamente muito alinhadas. Na verdade, se você entrou em uma equipe fazendo um desses processos você pode ter dificuldade em decidir rapidamente se você entrou em uma equipe Scrum ou uma equipe XP. As diferenças são muitas vezes bastante sutis, mas são importantes. Eu acho que existem quatro diferenças principais entre Scrum e XP:
- Scrum equipes normalmente trabalham em iterações (chamadas sprints) que são de duas semanas a um mês de duração., As equipas XP normalmente trabalham em iterações com uma ou duas semanas de duração.
- as equipas Scrum não permitem alterações nas suas sprints. Uma vez concluída a reunião de planeamento sprint e assumido o compromisso de entregar um conjunto de itens de backlog de produtos, esse conjunto de itens permanece inalterado até o final da sprint. As equipas XP são muito mais receptivas a mudar dentro das suas iterações. Desde que a equipe não tenha começado a trabalhar em uma característica particular, uma nova característica de tamanho equivalente pode ser trocada para a iteração da equipe XP em troca do recurso não iniciado.,as equipas de programação extrema trabalham numa ordem de prioridade estrita. Os recursos a serem desenvolvidos são priorizados pelo cliente (proprietário do Produto do Scrum) e a equipe é obrigada a trabalhar neles nessa ordem. Em contraste, o proprietário do produto Scrum prioriza o backlog do produto, mas a equipe determina a sequência em que eles irão desenvolver os itens backlog. Nunca vi uma equipa Scrum não escolher trabalhar no item de prioridade máxima. E uma equipa de Scrum irá muito provavelmente escolher trabalhar na segunda mais importante., No entanto, em algum momento um dos itens de alta prioridade pode não ser um bom ajuste para o sprint que está sendo planejado—talvez uma pessoa chave que deve trabalhar nele será inundada pelo trabalho em itens de alta prioridade. Ou talvez faça sentido trabalhar em um item de prioridade um pouco menor (digamos #10 no Backlog do produto em vez de #6) porque a equipe estará trabalhando no código onde #10 seria implementado.
- Scrum não prescreve quaisquer práticas de engenharia; XP prescreve., Eu amo as práticas de engenharia XP, particularmente coisas como o desenvolvimento orientado a testes, o foco em testes automatizados, programação de pares, design simples, refactoring, e assim por diante. No entanto, eu acho que é um erro dizer à equipe ” você está se auto-organizando, nós confiamos em você, mas você deve fazer essas práticas de engenharia específicas….”Isso envia uma mensagem mista para a equipe que causa confusão. Eu amo as práticas XP, mas não gosto de mandatá-los. Quero que as equipas descubram o valor sozinhos.
estas são pequenas e muitas vezes sutis diferenças entre Scrum e XP., No entanto, eles podem ter um impacto profundo na equipe. O meu conselho típico para as equipas é: “começa com o Scrum e depois inventa a tua própria versão do XP.”As práticas do XP são maravilhosas, mas eles trabalham melhor e as equipes se comprometem com eles da forma mais estridente, se eles próprios os descobrirem, em vez de mandatá-los. Eu ajudo as equipes a fazer isso em meu treinamento, fazendo perguntas como: “este bug teria acontecido se estivéssemos fazendo desenvolvimento de teste?”e” teríamos cometido esse erro se estivéssemos juntos?”Acho que o verdadeiro XP é um pequeno alvo à distância., Se uma equipa pode apontar para isso e acertar no alvo, maravilhoso. Se não, no entanto, eles são prováveis hacking (por exemplo, refactoring sem qualquer teste automatizado ou TDD). Scrum é um grande olho de boi que por si só traz grandes melhorias simplesmente através do foco adicional e as iterações de timeboxed. Esse é um bom ponto de partida para, em seguida, adicionar as práticas XP.