Scrum funciona sem XP?

Fui ouvir falar de Scrum bem depois de já ter batido muita cabeça tentando convencer as pessoas a usarem XP. Parece que de uma hora pra outra todos os mesmos conceitos que causavam pânico a qualquer gestor derrepente se tornaram moda. É como se o diabo tivesse sido promovido a arcanjo da noite pro dia, só porque mudou de nome (e de roupa). Não tenho dúvidas, Scrum é muito mais "vendável" que XP. Agora, cá pra nós, dá pra aplicar gerenciamento ágil com segurança sem usar práticas de desenvolvimento que o suportem?

Mesmo que se afirme que o Scrum tenha sido criado antes do XP, não foi assim que vi as coisas acontecerem aqui no Brasil. De um jeito ou de outro, não é esse o ponto central nesse post. Também não quero entrar no mérito sobre o Scrum tratar-se de uma disciplina mais âmpla, aplicável a outras áreas, além do desenvolvimento de software. Pretendo menos ainda atiçar uma disputa entre os dois ou dizer que "XP é melhor do que Scrum" ou outros maniqueísmos babacas (com o perdão da(s) palavra(s)).

Então a relação mais simples a se delinear entre esses dois, sob o ponto de vista de seus conteúdos, me parece ser:


E sob esse ponto de vista XP seria mais âmplo que Scrum. Mesmo porque as práticas de planejamento do XP são, em sua essência, Scurm - puro e escarrado. A menos de certos detalhes (ao meu ver) irrelevantes, não há o que tirar nem pôr.

Agora, falando especificamente sobre desenvolvimento de software, me parece arriscadíssimo aplicar o gerenciamento ágil sem técnicas como desenvolvimento orientado a testes, integração contínua, refactoring, etc.

Como posso me dar ao luxo de deixar o cliente escolher a ordem em que as funcionalidades serão desenvolvidas, ou permitir que a equipe levante os detalhes do sistema just-in-time, na hora de codificar?

Não há como implementar um software dessa forma sem se deparar volta e meia com algum detalhe que não havia sido pensado, suposições erradas a respeito do negócio, modelagens incoerente e outros mal entendidos. Aprendizado é uma palavra-chave aqui, certo?

Trabalhar dessa forma, portanto, pressupõe que o design do código volta e meia terá que passar por algumas "reformulações" (como se traduz refactoring mesmo?). Mas como pode uma equipe (de seres humanos) mexer na estrutura de um sistema poucos dias antes de uma entrega de um produto que deve estar "em qualidade de produção", relativamente sem bugs?

Alguém se arriscaria a mudar o modelo relacional do banco de dados de uma aplicação crítica, que já está em produção, e deve permanecer lá, sem erros, depois do upgrade daqui a duas semanas? Ou melhor: alguém se arriscaria a uma coisa dessas sem ter uma bela suite de testes automáticos pra dar segurança?

Costumo dizer que programar sem testes automáticos é o mesmo que um eletricista mexer em um painel de disjuntores sem ter as emendas dos cabos isoladas com fita. Vc botaria a mão ali?


Sinceramente, não me parece seguro aplicar Scrum a um projeto de software sem testes automáticos, integração contínua, design incremental, refactoring, e programação em par.

Na verdade, não me parece seguro aplicar coisa alguma sem isso! Não é privilégio do Scrum, claro.

Meu objetivo não é "falar mal" do Scrum. Como li n'alguma coisa do ViniciusTelles (não lembro onde), "não tenho nada contra Scrum. Adoro Scrum! Tanto que o uso como metodologia de planejamento em meus projetos XP" (ou alguma coisa parecida com isso).

O que me deixa "encafifado", simplesmente, é que é muito comum as pessoas se apaixonarem por Scrum e morrerem de preconceitos de XP. Como pode?

(Veja também minha opnião sobre Agile x PMBok & cia)