Resenha Scrum

5. Scrum

Uma metodologia ágil que apresenta uma comunidade grande de usuários é o Scrum (SCHWABER & BEEDLE, 2002). Seu objetivo é fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto. O Scrum apresenta uma abordagem empírica que aplica algumas ideias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as ideias de flexibilidade, adaptabilidade e produtividade. O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança.

O nome Scrum vem do jogo de rugby, onde é utilizado para reposição da bola, após faltas ou penalidades. Oito jogadores de cada equipe posicionam-se frente a frente, formando um círculo. Um jogador da equipe que não cometeu a infração lança a bola no espaço entre os jogadores alinhados que tentam, com os pés, ganhar a bola. Para isso, a grupo deve trabalhar em conjunto, como se fosse uma unidade. Apesar de muito utilizado no desenvolvimento de software, o Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu em 1995, após a formalização de sua definição, feita por Ken Schwaber (SCHWABER, 1995).

O Scrum pode ser utilizado sempre que um grupo de pessoas precise trabalhar em conjunto para atingir um objetivo comum, desde o gerenciamento de projetos de software até tarefas do cotidiano, como organizar uma festa. Ao contrário de metodologias definidas como o RUP, onde o processo de desenvolvimento é bem definido e repetível, o Scrum é uma metodologia empírica, na qual é defendida a ideia de que problemas fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de controle.

A ideia principal do Scrum é que o desenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O resultado do processo deve ser um software que é realmente útil para o cliente (SCHWABER, 1995).

A metodologia é baseada nos seguinte princípios: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento. No Scrum existem reuniões de acompanhamento diárias. Nessas reuniões, que são preferencialmente de curta duração, são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (gargalos ou bottlenecks) são identificados e resolvidos.

A Figura 1 exibe uma visão geral do Scrum:

Figura 1: Visão geral do Scrum

Fonte: Adaptado de Mallmann (2010)

5.1 Envolvidos

Scrum Team: é a equipe de desenvolvimento de um Sprint. Deve ser pequena (normalmente de 5 a 9 pessoas), multi-disciplinar e trabalhar em conjunto, como uma unidade. Não há papéis definidos na equipe, embora membros da equipe possam ser especialistas em determinadas áreas ou assuntos. O cliente é parte da equipe de desenvolvimento, tendo participação ativa no processo de desenvolvimento. É comum incluir um usuário na equipe de desenvolvimento para representar o cliente. A equipe tem total autonomia para gerir seu trabalho, incluindo distribuir e decidir como serão realizadas as tarefas do Sprint Backlog. Isso pode parecer desorganização à primeira vista, mas essa liberdade é compensada pela responsabilidade, que é da equipe como um todo, distribuída igualmente entre todos os seus membros. A equipe deve sempre manter o foco, trabalhando para atingir um objetivo comum, bem definido e conhecido por todos. A comunicação entre a equipe deve ser constante, para que ela possa trabalhar em conjunto e atingir seu objetivo.

Scrum Master: elemento da equipe responsável pela gestão do projeto e liderança das reuniões Scrum. São normalmente engenheiros de software ou da área de sistemas. O Scrum Master é responsável por remover obstáculos ao trabalho, resolver conflitos e assegurar que a equipe esteja seguindo as práticas de Scrum, sendo às vezes visto como guia da equipe; sua principal função é garantir que a equipe tenha as melhores condições de para atingir o objetivo do Sprint. Apesar de ser gestor, não tem propriamente autoridade sobre os demais membros da equipa, visto que no Scrum é incentivada a autogestão.

Product Owner: é considerado o dono do Projeto e representa a visão do negócio no projeto, sendo responsável pela definição e priorização do Product Backlog. Na maioria das vezes este papel é atribuído ao próprio cliente, podendo também ser representado por um analista de negócios ou sistemas, ou outra pessoa que conheça bem o domínio do produto e as prioridades do negócio.

5.2 Fluxo de Processo

Segundo FONSECA (2009), o Scrum divide um projeto em interações chamadas de Sprints, períodos não superiores a 30 dias, onde o projeto, ou apenas algumas funcionalidades, é desenvolvido. No início de um Sprint, durante o Sprint Planning Meeting (reunião de planejamento do Sprint), são definidas as funcionalidades do Product Backlog que serão tratadas na interação de acordo com a prioridade atribuída pelo Product Owner. Durante o Sprint, a equipe implementa estas funcionalidades disponibilizando-as já prontas para uso no fim da iteração. Um Sprint termina com um Sprint Review Meeting, uma reunião em que as funcionalidades implementadas são demonstradas para os usuários.

A Figura 2 apresenta uma visão do processo Scrum.

Figura 2: Fluxo de Processo Scrum

Fonte: Adaptado de The Scrum Development Process

5.3 Ciclo de