Ascenção e Queda de Scrum

Bom, para os que não sabem ainda, eu trabalho como Analista de TI na Universidade Federal do ABC. Ano passado (2009), tive a difícil missão de criar uma divisão de desenvolvimento de sistemas, de forma que ela atendesse um monte de demandas. Além disso, o TI já tinha 3 anos de existência e nunca tinha-se sequer rascunhado uma divisão de desenvolvimento, porque as primeiras chefias do Núcleo de TI tinham a idéia de que não haveria desenvolvimento de software dentro da UFABC. Enfim, problemas à parte…

Estudos foram feitos. Já havia uma série de scripts escritos todos em Ruby para facilitar um número de tarefas, e também já existiam dois projetos de Rails publicados, então parecia no mínimo estranho usar uma linguagem ágil, com um framework ágil (que inclusive possui geradores de código) e adotar uma metodologia tradicional. Artigos também com o do professor Xexéo, da UFRJ, auxiliaram a mostrar que existe uma frente acadêmica que abraça mudanças (já escrevi em posts anteriores que o Brasil é um país que valoriza mais do que deveria os diplomas e títulos). Anyway, aos fatos:

Muitos problemas que outras universidades tinham, a UFABC nunca teve, e em parte isso se deu por causa da implantação de Scrum (os detalhes da implantação estão num artigo que enviei para o Agile Brazil. Assim que eu tiver uma posição se ele foi aprovado ou não, faço upload do arquivo para cá). Mas claro que muitos problemas surgiram: auto-organização é uma idéia meio nova para algumas pessoas, além da aparente falta de controle do processo de desenvolvimento que as metodologias ágeis promovem (quem estudou um pouco sobre Scrum ou XP sabe que isso não é verdade – mas, infelizmente, parece que as pessoas gostam de gráficos de estimativa de prazo, etc). Muitos também não gostaram da idéia de “vou falar com a equipe para ver se este prazo/esta funcionalidade pode ser atendida” – às vezes, as pessoas gostam de respostas rápidas, “na lata”, mesmo que você não atenda. Aliás, outra coisa estranha: se estimávamos o prazo para quarenta dias, por exemplo, muitos “pechinchavam”, e percebi que muitas vezes esse comportamento se dava porque, em nenhum outro lugar, os prazos eram atendidos – então, pediam um prazo menor “imaginando” um atraso de, digamos, dez dias.

Para os que conhecem Scrum, sabem que é difícil ter a idéia de product owner dessa forma. Mas, conforme os projetos iam passando e as demandas iam sendo atendidas no prazo, a confiança foi aumentando, foram surgindo naturalmente product owners melhores, naturalmente a implantação do Scrum se aproximava de algo mais sério, regras iam emergindo naturalmente, e embora cometemos muitos erros no início da implantação, fizemos uma coisa muito certa (sem querer, eu assumo) que provavelmente foi o motivo das coisas terem evoluído tão bem e tão rápido: mantemo-nos fiéis às idéias do manifesto ágil. Mantemos o foco nas pessoas, nas comunicações, em fazer apenas aquilo que era pedido, em não inventar demandas e tarefas, em não montar o “Big Design Up Front“, mas principalmente o fator decisivo foi pensar nos processos quando eles se faziam necessários, ao invés de já montar uma estrutura pré-definida. Além, claro, da adoção de Test-Driven Development (bem no início).

Uma coisa me assustava, entretanto: usar Scrum, Ruby e Rails era muito produtivo, administrativamente ninguém questionava, porém no meio acadêmico, eu não tinha conhecimento de professores que ensinassem Ruby ou metodologias ágeis. Na minha faculdade, minha introdução sobre metodologias ágeis foi tão fraca que eu praticamente a considero inexistente (é incrível quando você fala que usa metodologia ágil, as pessoas falam: “puxa, vc faz então pair programming”? A idéia é maior que isso, pessoas!) e aparentemente na UFABC sequer existia uma menção ao assunto. Era complicado, numa universidade pública, implantar algo que não possuía apoio acadêmico (bastava só olhar para o edital do concurso público daqui, comparado ao de outros lugares – conhecimentos em linguagens dinâmicas Ruby, Python, Perl… em outros lugares, pediam Java, .NET, C/C++ quando muito).

Por fim, finalmente, o primeiro reitor eleito entrou em exercício. E, como de costume, todas as chefias mudaram, inclusive a do TI. Entrou uma pessoa que é da área de engenharia de software, e sua primeira atividade na nossa divisão foi deixar claro que não concordava nem com Ruby nem com “essas metodologias novas”. Tentativas de argumentação foram todas para o lixo, até o ponto atual – sabemos que, um dia, tudo terá que ser portado para Java. Sabemos também que a metodologia adotada será algo semelhante à cascata. Ou seja, o trabalho de um ano será jogado no lixo para ser portado para Java/Cascata, sem nenhum motivo aparente.

Aonde eu quero chegar? Simples: mudar uma metodologia tradicional para uma metodologia ágil não é simplesmente portar um sistema. Não é simplesmente traduzir um texto. É uma mudança muito mais profunda, uma mudança de paradigma, e mudanças de paradigma não podem ser feitas baseadas em fatos históricos – como justificar, então, que hoje aceitemos tão publicamente colocar, para o mundo inteiro ver, o que estamos fazendo (numa rede social, twitter, etc), se ha vinte anos atrás ninguém saía colando cartazes nos muros dizendo que está viajando, que estará num congresso XYZ, etc? Como justificar o sucesso do twitter, quando todos nós odiamos Spam (tá, não é a mesma coisa… mas comparar Scrum com outras metodologias é quase comparar Twitter com E-mail).

Culturalmente, as coisas não mudam tão fácil assim. Cargos públicos e instituições de ensino, conforme cita claramente Fábio Akita, abraçaram a idéia de fábrica de software, com todos os defeitos e qualidades que isso possa significar. E, pelo visto, mudar isso é mais difícil do que eu imaginei.

Pior é que, vide meu post anterior, aparentemente nem há embasamento científico por trás disso… é simplesmente, cultura.