Quando comecei a ouvir sobre “métodos” (não concordo com o termo metodologia dentro do contexto de desenvolvimento de software, metodologia é a ciência que estuda o método, método é o que usamos propriamente dito) ágeis de desenvolvimento de software, procurei artigos que abordassem estudos de caso em cenários que realmente refletissem a realidade da maioria das pessoas que se envolvem em processos de desenvolvimento de software.

Pessoas como primeiramente o cliente, aquele que tem uma necessidade a ser atendida por meio de uma ferramenta de software que precisa ser desenvolvida dentro de um contexto de custo e prazo com qualidade e condições de continuidade e manutenção dentro da vida útil desta ferramenta, o desenvolvedor que precisa entender essa necessidade do cliente dentro de contextos funcionais, identificar os demais requisitos não funcionais para então escolhendo uma ferramenta de desenvolvimento, desenvolver esta solução para o cliente, e por fim existe alguém no meio do caminho (um gestor de projetos ou um SCRUM Master como caracteria o método SCRUM) que trabalha para gerenciar a espectativa do cliente, a produção do desenvolvedor com o objetivo de chegar a conclusão do projeto com uma ferramenta de software entregue dentro das especificações/necessidades do cliente.

Em meio a tudo isso, falando específicamente da proposta do SCRUM, temos a promessa de que por meio de um modelo de gestão ágil, o cliente terá aos poucos (a cada sprint) um elemento de software paupável, capaz de ser avaliado e se aprovado, devidamente publicado em produção, isso em um processo cíclico, contínuo até a conclusão do projeto, ou seja o cliente tem sempre algo pra ver, testar, mudar se quiser e com isso a dinâmica do projeto muda, a visão dos envolvidos muda, a realidade de desenvolvimento do projeto muda, muito mais foco no que é necessário, muito mais foco no que é utilizável, muito menos foco no que é burocrático.

Bom, parece um sonho perfeito, mas se é tão bom assim, o que falta para vingar de vez? o que falta para vermos o papel SCRUM MASTER presente cada vez mais nas fábricas de software e núcleos de desenvolvimento? o que falta para vermos SCRUM como parte do conteúdo das matérias relacionadas a “METODOLOGIAS” de desenvolvimento de software nas faculdades? Na minha humilde opinião, falta coragem para testar, para arriscar, para quebrar paradigmas que acomodam as empresas desenvolvedoras de software sob a falsa segurança de poder gerenciar suas entregas e controlar seus desvios de percurso por trás de gigantescos cronogramas em PROJECT onde o cliente só consegue se deparar com elementos entregáveis do projeto depois de meses de trabalho da equipe de software, depois de muito dinheiro gasto e com isso mesmo que ele não esteja muito satizfeito com o que vai receber, vai ser obrigado a se sujeitar a isso para não ter prejuízo…

Ao contrário do que muitos dizem, não vejo SCRUM como um modismo, vejo como uma evolução na forma de se pensar projetos de software, na forma de se desenvolver projetos de software, mas principalmente na forma de se relacionar entre os 3 principais envolvidos no processo de desenvolvimento de software, o desenvolvedor, o gestor e o cliente, pois o SCRUM os colocar em um contexto de colaboração, cumplicidade, e não mais naquela rivalidade do “só vou fazer o que foi especificado lá trás e pronto” ou “se mudar o escopo vai ter que mudar o prazo, e vai ficar mais caro…” como se vê na maioria dos contextos.

SCRUM ajuda a dar a TI a visibilidade de apoiador, viabilizador, aliado, e com isso todos nõs que trabalhamos com desenvolvimento de software porque gostamos disso, teremos além do prazer de ver um produto concluído e entregue, a satizfação do nosso cliente não somente no que ele está recebendo mas também na forma como ele participou também no desenvolvimento deste produto.

Ganha a empresa que vendeu o projeto, ganha o desenvolvedor, ganha o cliente, enfim… ganhamos todos nós!

Eu acredito no SCRUM, e você?