XP no “underground” – Scrum no “mainstream”

Rodrigo Yoshima (Yosha) enviou a seguinte mensagem para algumas listas de discussão de agilidade:

Tracei um gráfico hoje no Google Insight que mostra bem o cenário Agile no BR:

http://bit.ly/scrum_vs_xp

O gráfico desde 2004 mostra uma queda vertiginosa nas buscas por Extreme Programming e um crescimento por Scrum.

Qual é o comentário de vocês?

Para quem acompanha os pensamentos do Yosha, sabe que por trás dessa mensagem há algo que ele vem falando há algum tempo: o que matou o RUP vai matar a agilidade. É um pândego, mesmo. Quer ver o circo pegar fogo. Concordo plenamente. Obs.: vocês vão entender o que esse parágrafo tem a ver com o assunto quando lerem o último.

Por que Scrum passou de XP?

Por que é natural. Para mim, isso não foi surpresa. Na verdade, até foi, mas depois de refletir um pouco, entendi que essa é a configuração natural. A situação atípica era a que acontecia antes, com XP sendo o mais procurado. A pergunta então seria: “Por que antes XP era mais procurado que Scrum?” Acho que era pela capacidade de mobilização da comunidade (se não me engano o Fowler já falou disso) e pelo suporte teórico promovido por Beck, Fowler, Jeffries, Cunningham, etc., pela quebra de paradigma promovida por XP, pelas práticas polêmicas como programação em par, TDD e código coletivo, pela crítica mordaz a documentação inútil, etc. Uma grande massa de desenvolvedores teve um estalo: “Meus deus! É isso…!” Scrum não conseguiria esse efeito inicial exatamente por tratar apenas de gestão. Faltariam respostas.

Nesse meio tempo, agilidade começou a se tornar sedutora. Os modelos tradicionais não estavam surtindo o efeito desejado, e empresas-modelo como Google, Yahoo!, Toyota, Nokia, 3M, etc. se anunciavam ágeis. Naturalmente os olhares começaram a se virar para a agilidade, que passou a interessar não somente aos “meros” desenvolvedores, mas também aos gerentes e dirigentes das empresas. Só que em geral gerente não entende de engenharia. As práticas técnicas do XP funcionavam como vetor de opacidade para essa turma. Naturalmente procuraram algo mais palatável, e também mais ligados a eles, algo que tratasse apenas de gestão. Bingo: Scrum. Vou contar um caso que aconteceu comigo (e olhe que tenho embasamento técnico). Certa vez, há alguns anos, um colega daqui me falou sobre testes unitários, me explicou superficialmente o conceito, e pediu minha opinião. Eu disse que achava que isso não funcionava, pois teria de se programar dois sistemas, ao invés de apenas um. Olha a bobagem… Não lembro exatamente o que me atraiu para o XP, mas suspeito que tenha sido algum texto do Vinícius.

Além disso, gestão é o ponto de partida canônico para melhoria em organizações de desenvolvimento de software. O primeiro nível do CMMI, por exemplo, é quase todo voltado para gestão. A lógica é mais ou menos a seguinte: “Vamos primeiro organizar um pouco essa bagunça. Depois a gente melhora a engenharia.” E essa abordagem me agrada. Pois bem, se se vai começar por gestão, nada melhor que Scrum. Apesar de XP contê-lo quase todo, mais adequado começar por algo específico.

Falei em “organizar a bagunça”. Mas há empresas que já estão “organizadas”, com processos bem definidos, mas que estão buscando a agilidade. Essas são aquelas que normalmente costumamos chamar de tradicionais (guidas por documentação, papéis, processos e fases rígidas, iterações longas). Intuitivamente entendo que é mais complicado implantar Scrum nessas empresas. Iterações de um mês nesse cenário é muito complicado. Dá tempo rodar todas as fases numa iteração? Nas idas e vindas entre cada fase, dá tempo de atualizar toda a documentação dentro de uma iteração? Aí vêm os diversos sabores de Scrumbut. Desde iterações individuais para especificação, design, programação e testes (ouço o Yosha gritar “RUPbut”) até pipelines para cada uma dessas fases. Curiosamente neste caso, dos pipelines, se potencializado à forma extrema, esse cenário se aproximaria muito do Kanban Development, ainda que sejam necessárias brutais adaptações e que seja fundado em valores diferentes. Um aparte: fazendo uma analogia, são essas brutais adaptações que me fazem crer que o RUP não é verdadeiramente ágil.

Além disso tudo, há todo o aspecto de marketing envolvendo o Scrum. Isso já foi perfeitamente explicado pelo Vinícius e pela Improve It em seu antológico post sobre seus novos rumos. Quem não quiser ler o enorme texto do Vinícius, um brevíssimo resumo: há uma organização por trás do Scrum (Scrum Alliance), seu vocabulário é mais “adequado” (“Scrum”, “Product Owner”, “Scrum Master”, “Product Backlog”, “Daily Scrum”, etc.) que o do XP (“Extreme”?! “Programming”?!) e há as tão “necessárias” certificações.

Mas é preciso entender que quase todas as empresas que realmente implantarem Scrum vão acabar no futuro avançando para XP, ou pelo menos para práticas como design incremental, refatoração, testes automatizados e integração contínua. E espero que isso realmente aconteça, para o bem de nossa indústria, sob o risco de vermos equipes pregando cartões na parede, fazendo rabiscos, negligenciando documentação, brincando de planning poker, e toda a sorte do besteirol ágil, mas continuando entregando porcaria e se dizendo praticantes de Scrum.