As metodologias que conhecemos hoje em dia como “metodologias ágeis” se baseiam nos mesmos princípios e no manifesto ágil. Talvez seja por isso que muitas práticas dessas metodologias são muito parecidas ou até mesmo iguais, só mudando seu nome.
Estou falando mais especificamente de Scrum e eXtreme Programming (XP). O Scrum, particularmente, é um framework focado principalmente em planejamento e gerência. Já o XP é mais focado em práticas de desenvolvimento. Mesmo assim, várias práticas são coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game, e por aí vai.
A principal diferença que vejo entre as duas é que Scrum não te diz nada sobre práticas de desenvolvimento de software ágil, até porque você pode usar Scrum não só para fazer sistemas, como também para fazer carros, aviões ou bolos.
Minha visão é que as práticas de XP complementam o Scrum. Certas práticas de desenvolvimento, que vejo como essenciais para o bom andamento de um projeto de software, não fazem parte do escopo do Scrum mas fazem parte do XP, como desenvolvimento guiado por testes, integração contínua, build de 10 minutos, design incremental, metáforas, código coletivo, programação em par, refatoração e por aí vai. Por isso, não só acho que é bom fazer essa combinação, como acho que é bastante recomendável.
Mas para fazer isso não seria melhor usar XP puro ou invés de Scrum? Não vejo dessa forma. Scrum tem algumas diferenças que acho interessantes, como a retrospectiva fazendo parte do processo, uma grande ênfase na gerência do backlog (e em quem é o “responsável” por cada backlog: o P.O. pelo backlog do produto e o time pelo Sprint backlog) e a forma de planejamento e acompanhamento dos Sprints.
10 replies on “XP complementa o Scrum”
Na minha humilde opinião, melhor do que se focar em qualquer metodologia específica é conhecer o que há de bom em várias metodologias e adotar boas práticas que julguemos que façam sentido em nosso contexto.
Quero dizer, em vez de simplesmente tomar Scrum como uma solução definitiva para qualquer ambiente, conhecer as boas práticas de Scrum, XP, UP, Evo, etc e então analisar o contexto no qual nos encontramos e julgar o que vale a pena usar. É claro que precisamos começar a usar as práticas para conhecer melhor o que se adapta bem ou não.
A iniciativa de usar Scrum é muito boa, pois ele traz várias boas práticas. Da mesma forma, XP também agrega coisas interessantes. Para mim, o mais importante dessas metodologias são as idéias que elas trazem. Simplesmente adotar Scrum não garante nada, mas provavelmente se você pegar as boas idéias de Scrum e XP, terá uma boa metodologia de trabalho.
Não existe bala de prata, mas talvez uma bala de (prata + ouro + bronze + platina + cobre) seja o ideal para o seu contexto 😉 A experiência irá nos dizer o que realmente funciona, e experimentar coisas distintas certamente faz parte do aprendizado.
Realmente podemos complementar o processo do Scrum com outras práticas ágeis, como o pair programming, tendo resultados muito bons, principalmente no desenvolvimento de pontos críticos da aplicação. Nestes moldes, o Scrum estrutura o processo enquanto as outras práticas agilizam pontos específicos. Entretanto, também não dá pra ficar misturando demais, senão o próprio framework de desenvolvimento fica comprometido.
Guilherme,
O livro do Kent Beck não está aqui agora, mas a partir da segunda edição XP incluia retrospectiva como parte do processo. Sobre a gerência do backlog, acho que XP não cobre isso mesmo.
valeuz…
Nem precisa olhar o livro, Marcos. O XP realmente inclui a prática da “Reflexão” no processo, mas mesmo assim é diferente. No Scrum tem aquela história dos itens da retrospectiva virarem impedimentos do time e empresa, que é uma coisa muito legal. Os problemas efetivamente são endereçados e resolvidos dessa forma.
@Bruno
Concordo em parte.
Concordo porque uma das premissas das metodologias é “inspect and adapt”, ou seja, avalie constantemente o processo e adapte-o para as suas necessidades. Porém, muitas pessoas não conhecem o processo ou não entendem a fundo as motivações das práticas, e fazem mudanças completamente esdrúxulas, como desenvolver em waterfall ou não ter daily meetings 🙂
Por isso é extremamente recomendável que, ao iniciar a prática de uma metodologia ágil, você siga a risca todas as regras durante um tempo e entenda-as muito bem. Só depois disso que você deve começar as mudanças, e mesmo assim com muito cuidade para não “desbalancear” o processo.
[ ]s, gc
Fair enough, I couldn’t agree more 🙂
Guilherme,
concordo totalmente com o seu post.
E o mais incrivel eh que muita gente ainda acha que XP e Scrum sao essencialmente diferentes, e ate pode-se incluir Lean nessa lista.
Abraco,
Francisco
http://franktrindade.wordpress.com
[…] Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem. […]
[…] coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a […]
[…] na Globo.com By nelsonhochman Scrum, XP, TDD, BDD entre outras….. Sopa de letras que tentam arduamente criar meios de se […]