Quick Eng: Scrum

Olá pessoal!

Continuando a série rápida sobre engenharia de software, neste post falo um pouco sobre o Scrum. O objetivo desta série, como mencionado no post anterior, é traçar um paralelo entre os processos de desenvolvimento de sistemas mais populares: RUP e o Scrum. Caso você não tenha lido o post anterior, onde falei sobre o RUP, clique aqui.

Assim como o RUP, o Scrum também é um processo de desenvolvimento de sistemas iterativo e incremental, porém, é voltado ao que se chama de desenvolvimento ágil de software, que por sua vez é fundamentado pelo manifesto ágil. O manifesto ágil foi concebido por dezessete pessoas de extrema influência na área de engenharia de software, sendo que dentre eles destacam-se: Martin Fowler, Alistair Cockburne Kent Beck. Quatro valores fundamentais formam a base do manifesto ágil:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;
• O funcionamento do software acima de documentação abrangente;
• A colaboração dos clientes acima da negociação de contratos;
• A capacidade de resposta à mudanças acima de um plano pré-estabelecido;

Percebe-se então uma grande diferença entre os valores que formam a base do RUP e os do Scrum, sendo que uma das principais é o fato de que as documentações permeiam o RUP de ponta a ponta enquanto que no Scrum, em sua essência, pouca ou nenhuma documentação é produzida. Além disso, outra grande diferença, como bem lembrado pelo colega Alessandro Brito em uma discussão, é que o Scrum não define o que fazer em cada situação, o que o classifica como um processo não prescribente.

Vamos então a alguns detalhes. No Scrum, todo o conjunto de requisitos do usuário é conhecido como Product Backlog. Nele há a introdução do conceito de Sprint, que se refere a uma iteração de implementação completa de um ou mais itens do Product Backlog, que são entregues e validados pelo cliente ao seu término. O conjunto de itens selecionados para implementação em uma sprint é denominado Sprint Backlog. As sprints normalmente têm duração de duas a quatro semanas, de forma que o cliente tenha contato com as primeiras funcionalidades do sistema logo no inicio do seu desenvolvimento – o que é bem característico de processos iterativos e incrementais, assim como o RUP. Veja na figura a seguir a ilustração do processo descrito.

No Scrum também é empregado o que se chama de Daily Mettings, onde todos os participantes do time de desenvolvimento do projeto participam de uma breve reunião, apontando os seus progressos e/ou seus impeditivos, de forma que os riscos possam ser mitigados logo no momento em que surgem. Além disso, são também realizadas reuniões de planejamento das próximas sprints e de retrospectivas das sprints finalizadas, onde são verificadas as lições aprendidas, de forma que eventuais problemas não se repitam ao longo do projeto.

Situados ambos os processos, surgem algumas questões, como por exemplo: qual processo é mais adequado para a minha empresa ou para o meu time de desenvolvimento e quais são as tendências atuais? Estas são questões que abordarei no próximo post, onde finalizarei esta pequena série. Até lá!