O boom do Scrum

Em 2012 eu decidi que queria estudar Scrum e me matriculei em um curso. Escolhi o CSPO, ou seja, uma certificação para atuar como product owner, um dos papeis do Scrum. Na época, eu era gerente de produtos em uma empresa que adotava uma metodologia tradicional e enxerguei semelhanças na função em relação ao papel de Product Owner. O curso me levou à certificação e também a ser um membro da Scrum Alliance.

Naquela época eu pude liderar um grande projeto de uma instituição pública. Fiz diversas viagens para ouvir o cliente, escrevi documentos extensos, preparei mockups, elicitei requisitos, orcei o desenvolvimento com o engenheiro e a equipe, colhi assinaturas do cliente para garantir que ele havia concordado. Mas comecei a me frustar quando percebi que não estava funcionando e que a cada nova reunião o cliente mudava tudo e o software não progredia.

Apesar de enxergar no ágil uma opção, eu simplesmente não podia mudar a metodologia da empresa toda, fortemente ligada ao tradicional e repleta de gerentes de projetos certificados. Então decidi encaixar no meu dia a dia ao menos um pouco da essência do ágil: passei a envolver equipes apenas no momento certo, a oferecer a eles uma visão de produto mais fiel e já priorizada, entre outros.

No meu mestrado eu decidi encaixar o Scrum em minha dissertação, na qual eu trabalhei o planejamento de uma rede social voltada para um nicho. Como o Scrum não é prescribente, ou seja, não lhe diz tudo o que fazer (por isso é um framework), precisei associar duas outras técnicas para chegar à visão de produto, ao modelo de negócios e à um roadmap, que me permitiram a partir dai elaborar um product backlog, ou seja, uma lista de requisitos inicialmente não ordenada, que seria destrinchada e priorizada à medida em que o desenvolvimento do software ocorresse.

A essência Scrum pode ser aplicada em outras áreas. Já experimentei aplicar numa equipe de marketing e foi bem interessante. O ágil de forma geral é sempre interessante.

No momento sou professora de três cursos de pós-graduação relacionados à TI e ministro a disciplina de métodos ágeis. Estou orientando trabalhos científicos de alguns alunos que também estão trabalhando com Scrum. Uma das alunas, inclusive, está trabalhando com as semelhanças entre PMBOK e Scrum. Sim, elas existem!

Em um outro trabalho, a aluna aplicou um questionário para entender como se deu o uso de Scrum em uma empresa de desenvolvimento. Ela entrevistou 38 pessoas que trabalharam com Scrum, mas que acabaram migrando para outra opção e obteve essas respostas:

Estaria o Scrum sendo uma opção ruim? Por que em alguns casos ele não funciona? Se eu adaptar o Scrum ele deixa de ser Scrum? Em minhas pesquisas e palestras respondo a algumas destas questões por meio de dados e pesquisas de grandes instituições. Mas posso resumir que as principais falhas do ágil estão na cultura da empresa e na tentativa de implementar, não no modelo em sí.

Mas como chegamos ao cenário ágil, tão disseminado na atualidade?

Em 1971 o cientista da computação holandês Dijkstra usou pela primeira vez o termo “crise do software”, referindo-se ao fato de existir, em grande parte, uma desorientação em relação ao planejamento e condução dos processos de desenvolvimento de software e de muitos desenvolvedores não utilizarem um processo adequado para tal. Dijkstra avaliou que a rapidez com que o hardware progredia e as demandas por sistemas mais elaborados eram fatores que contribuíam para uma desorientação dos desenvolvedores, em uma época na qual a Engenharia de Software era pouco disseminada.

Os problemas relacionados à administração, nesse sentido, ainda são praticamente os mesmos, girando em torno de prazos não cumpridos, custos altos, sistemas complexos, demandas frequentes de manutenção e adificuldade de encontrar profissionais.

Pressman (2010) cita que as metodologias ágeis foram desenvolvidas com o objetivo de vencer as fraquezas percebidas e as reais da Engenharia de Software, e que com elas é possível adaptar o processo para ter certeza de que ele não
atrapalha a agilidade, que acomoda as necessidades da equipe, que produz apenas os produtos que permitem entregar um incremento planejado, que se avalie continuamente a qualidade do trabalho, e que permita acomodar mudanças que possam impactar no cronograma e método de trabalho.

Em 2001, foi assinado o Manifesto do Desenvolvimento Ágil de Software, por Kent Beck e outros desenvolvedores e consultores de software, que formavam a Aliança Ágil, na qual foram levantados pontos que seriam valorizados. Dentre eles:

• indivíduos e interações MAIS que processos e ferramentas;
• software funcionando MAIS QUE e uma documentação muito abrangente;
• colaboração do cliente MAIS QUE negociação de contratos;
• resposta a modificações MAIS QUE seguir um plano.

A partir dai, surgiram os 12 princípios do manifesto ágil, que direcionaram as metodologias que nasceram a partir dele.

Se quiser saber um pouco mais, veja esse artigo que escrevi "10 artigos sobre Scrum que valem por um curso"

Referências:

PRESSMAN, R. S. Engenharia de Software. Mc Graw Hill, 6 ed, Porto Alegre, 2010.

WAZLAWICK, R. D. Engenharia de Software - Conceitos e Práticas, Campus, 2013.