Metodologias Ágeis. SCRUM

UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS – UNIPAC

Fundação Presidente Antônio Carlos – FUPAC.

Engenharia de Software

Nomes:

TEÓFILO – OTONI

Novembro - 2011

Metodologias Ágeis

SCRUM

Sabendo que desenvolver softwares não é uma tarefa das mais simples. Uma ampla gama de variáveis influencia no modo como uma aplicação será construída, somando-se ainda a isto influências como a pressão pela entrega do produto em um prazo muito curto, mudanças motivadas por alterações na legislação vigente, dificuldades dos usuários que solicitam um sistema em descrever de forma clara e concisa aquilo que realmente necessitam (com prováveis pedidos de modificações ao longo do projeto), dentre outros aspectos.

Em um cenário de transformações constantes, a escolha pelo paradigma de desenvolvimento mais adequado a um determinado contexto é, sem sombra de dúvidas, um fator crucial para o sucesso do projeto.

O que é Scrum?

Scrum é uma metodologia ágil voltada ao desenvolvimento de software. Surgido ainda na década de 1990, este modelo é resultado dos esforços conjuntos de especialistas da área de sistemas.

assim como outros métodos com um enfoque similar, a proposta do Scrum é fornecer subsídios para o gerenciamento de atividades muitas vezes complexas, porém de uma forma flexível e que facilite a adaptação do projeto diante das inevitáveis mudanças.

Como outros métodos ágeis, Scrum é uma metodologia que prima pelo desenvolvimento iterativo e incremental de software. Em termos práticos, isto significa que ciclos contendo um conjunto de específico de atividades são repetidos continuamente ao longo de um projeto; por incremental, deve-se ter em mente a idéia de sucessivas entregas de funcionalidade, acrescentando aquilo que se espera do software em intervalos constantes de tempo.

Um conjunto de papéis bem definidos determina, através de atribuições, como será a atuação dos diversos profissionais que participarão de um projeto baseado na metodologia Scrum:

Product Owner: representante da área cliente/solicitante;

Scrum Master: o líder que gerenciará o projeto;

Equipe de Desenvolvimento/Time: os profissionais responsáveis pela criação do produto esperado.

O Product Owner é o ponto que centraliza a interação com a área/grupo de usuários que solicitou a execução de um projeto. A partir do mesmo são definidas prioridades, o que deverá ou não ser implementado e a validação dos diferentes resultados ao longo do processo de desenvolvimento.

Já o Scrum Master corresponde ao papel do Gerente de Projetos tradicional. Além de ser um facilitador removendo impedimentos e um mediador em prováveis conflitos, este profissional garante que a equipe sob sua supervisão siga de maneira adequada as práticas de Scrum.

Por fim a Equipe de Desenvolvimento (ou Time) elabora estimativas, estipula tarefas, implementa o produto dentro de níveis de qualidade pré-estipulados e cuida da apresentação do mesmo ao cliente/solicitante.

Eventos possíveis em Scrum

Por mais que como uma metodologia ágil Scrum priorize a entrega do software em detrimento de uma extensa e trabalhosa documentação, a elaboração e a conseqüente manipulação de alguns artefatos neste modelo é de fundamental importância para o controle das atividades rotineiras. A seguir estão listados tais documentos:

Backlog do Produto (ou em inglês “Product Backlog”);

User Story;

Sprint Backlog;

Gráfico de Burn Down.

O Product Backlog é uma listagem que contempla todas as funcionalidades desejadas para o software que se está implementando. Além disso, as informações contidas neste tipo de controle podem conter ainda uma ordem de prioridade, sendo incumbência do Product Owner criar e controlar o status dos diferentes elementos do Backlog.

Uma User History é uma pequena história que descreve as características esperadas para uma funcionalidade constante no Backlog do Produto. Constam no documento que representa tal história um título, uma descrição clara do que se necessita, bem como é possível se indicar ainda uma prioridade para execução da tarefa.

A Sprint Backlog é uma relação de tarefas elaborada pelo Time de Desenvolvimento durante a segunda etapa da Reunião de Planejamento da Sprint. Trata-se de algo que está em conformidade com o conceito de equipes auto-gerenciáveis, uma vez que os profissionais responsáveis por isto planejam como será o dia-a-dia de desenvolvimento a partir das prioridades apontadas pelo Product Owner.

O Gráfico de Burn Down é uma ferramenta de gerenciamento. Este artefato costuma ser atualizado diariamente, servindo de base para a comparação entre o que foi planejado e aquilo que realmente se realizou. Pode ser considerado um instrumento para tomada de decisão, uma vez que fornece embasamento para ações em prol de uma maior produtividade ou ainda, a fim de atenuar riscos