05 setembro 2008

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)

11 comentários:

  1. Parabéns pelo seu artigo, você escreveu exatamente tudo que penso sobre Scrum.
    Espero que as pessoas não levem isso para uma disputa de quem é melhor ou pior.
    Artigos como esse servem para as pessoas entenderem a fronteira e saberem a hora de migrar para algo mais específico da nossa área.

    Parabéns!

    ResponderExcluir
  2. Gostei do seu artigo, compartilho com suas idéias.

    Parabéns!

    ResponderExcluir
  3. Pois é Bruno,
    Acho que independente do "label", temos mesmo é que ser ágeis, quer dizer, seguir os princípios do manifesto.
    O resto não importa.

    Fazer Teste é essencial pra entregar software funcionando. Também acho que Scrum sem isso, pra software, não dá.

    Acho que só rolaria Scrum sem XP em outras áreas, como publicidade, que também tem usado Scrum com sucesso.

    Farô! (daqui do lado! :)

    ResponderExcluir
  4. Talvez o SCRUM seja uma forma de convencer os gestores e stakeholders de que o XP é essencial para o sucesso do planejamento ágil, né? Com o scrum, eles se sentem uma peça importante no processo todo.
    Parabéns, meu velho, o texto tá excelente! Curto e objetivo. :)

    ResponderExcluir
  5. Bruno, dei uma lida no seu post e achei muito interessante, porém, eu
    humildemente discordo do seu ponto de vista quando você diz que XP é
    bem maior que Scrum e quando você diz que não da para se aplicar Scrum
    sem aplicar o XP.

    Na empresa onde eu trabalho, estou implantando o Scrum e não
    utilizamos o XP e temos tido otimos resultados.
    A Rigidez do Scrum em relação a Time-box tem ajudado muito na
    objetividade e conclusão das nossas releases.

    Sobre a questão que você levantou acho que poderia ser melhor
    discutido, digamos que é extremamente aconselhavel a utilização de
    ambos XP+Scrum porém, não é obrigatorio no podemos usar somente o XP
    ou somente o Scrum, ate porque vejo o XP como uma tecnica de
    desenvolvimento de software ágeis e o Scrum como uma metodologia de
    Gerencia de projetos ágeis.

    Meu ponto de vista pessoal é esse e não quero levantar discordias nem
    polemica, mas acho que um não exclui ou inclui o outro, ambos tem suas
    caracteristicas que podem ser aproveitadas.

    Bem, se quiser, podemos conversar mais sobre o tema q é de muito
    interesse para mim, qualquer coisa me manda PVT ou me adiciona no
    gtalk.

    ResponderExcluir
  6. Concordo que é ruim aplicar Scrum sem práticas de desenvolvimento ágil, mas não vejo como essas práticas são exclusivas do XP. As práticas existem muito antes do XP existir e são independentes do XP. Nesse caso, é possível aplicar Scrum com práticas ágeis que diferem do modelo que o XP oferece. Nesse caso, é possível aplicar Scrum com sucesso em projetos de software sem utilizar XP. =)

    ResponderExcluir
  7. Eu (que não sou praticante de métodos ágéis, embora esteja interessado) tenho uma dúvida sobre o relacionamento entre XP e Scrum. Levando sua simplificação em consideração (XP é Scrum mais algumas práticas de desenvolvimento), quem é que escolhe utilizar XP no processo? Que eu entendi das minhas leituras sobre o assunto, a escolha de seguir o método Scrum é principalmente a responsabilidade do gerente to projeto e dos stakeholders (principalmente o Business Owner).

    A opção de utilizar as técnicas do XP, porém, me parece da equipe. No Scrum, é a equipe que escolhe como vai conseguir entregar a próxima "increment" na hora. É a equipe que também faz as estimativas na hora de escolher o que vai ser entregue na próxima iteração.

    As prácticas do XP a princípio existem para garantir a qualidade do software ao longo do processo. Existe o chamado "technical debt" que acumula com tempo se não utilizar as práticas de refactoring, pair programming e tal religiosamente. O preço que paga por isso é maior risco de erros e baixa produtividade.

    Mas lembre-se de que a mesma equipe que possa estar sofrendo essas dificuldades está fazenda as estimativas. Então acho bem razoavel acreditar que mesmo sem essas práticas do XP, a equipe consegue criar um plano e cumprir os objetivos que eles mesmos tenham ajudado a escolher. No pior dos casos, as estimativas começam a ficar tão altas que o business owner começa a perguntar porquê. Como resposta, acho razoavel colocar no product backlog um ítem relacionado a "limpeza" do código. Assim, o business owner entenderá o valor de fazer um projeto técnico e escolher quando deve ser feito.

    Que eu saiba, milhares de projetos foram realizados com Scrum, mas sem o XP. É lógico que as práticas do XP são muito valiosas, mas acho que é a equipe que tem que decidir se vai seguir o XP ou quer fazer de outra forma. De qualquer forma, a equipe tem grandes chances de sucesso.

    ResponderExcluir
  8. Oi Tim,

    Obrigado pelo comentário.

    Respondendo sua pergunta: O gerente e o product owner fazem parte da equipe (ou deveriam). Então a responsabilidade pela decisão devia ser de todos.

    Uma equipe terá grandes dificuldades em "adotar" XP sem apoio. O que vejo acontecer aos montes são equipes que adotam XP "escondido", como se estivessem fazendo alguma coisa errada.

    O cenário que vc traçou é perfeito. Acho que a necessidade pelas práticas de engenharia irá surgir naturalmente. E mais: acho que irá surgir SEMPRE.

    ResponderExcluir
  9. Discordo,
    é complexo sim implantar SCRUM sem uma boa Prática de ENGENHARIA DE SOFTWARE (que é o XP), nisso sim eu concondo.
    Pois o que interessa realmente é ter qualidade, foco no time, refactoring e testes, mas não necessariamente XP, podemos ai adotar FDD, Crystal, dentre outras até o XP, a qual acho muito boa e tem um casamento muito bom com o SCRUM, como todas as outras, pois o SCRUM se propoe a gerenciar projetos de forma ágil e a engenharia se proporia a tomar conta do Sprint para que ele tenha qualidade, produtividade....
    Acho que deve ser explicado para quem está querendo adotar SCRUM ou Processos ágeis em projetos de desenvolvimento do Softwares, para que nao façam confusão de SCRUM com XP.

    ResponderExcluir
  10. Legal Jorge,

    Vc tem toda razão!

    Não precisa ser XP, mas alguma metodologia de engenharia é necessária.

    Apenas peguei o XP como "bode expiatório", mas minha questão original é "dá pra aplicar gerenciamento ágil com segurança sem usar práticas de desenvolvimento que o suportem?"

    ResponderExcluir
  11. http://gc.blog.br/2008/03/31/xp-complementa-o-scrum/

    [ ]s, gc

    ResponderExcluir