O Sprint e os Artefatos do Scrum

No Scrum existem vários Time-Boxes que são utilizados para gerar regularidade. Os Time-Boxes mais importantes no Scrum são: a sprint planing meeting(planejamento de versão), o sprint, a reunião diária, a revisão do sprint e a retrospectiva do sprint. O coração do scrum para Schwaber (2010) é o sprint, que é uma iteração de um mês ou menos dentro da qual é feito um esforço de desenvolvimento. Ao final de cada sprint tem se como resultado um pequeno incremento de software que é potencialmente entregável após isto a equipe pode iniciar um novo sprint.

O Scrum utiliza quatro artefatos principais. O backlog de produto que é uma lista priorizada de tudo que pode ser necessário desenvolver em  um software. O backlog de sprint que é uma lista de tarefas  priorizadas no backlog de produto  e que ao final de uma sprint, resultará em um incremento. Um burndown que é um gráfico através do qual é medido a velocidade do time. Um burndown  de release que mede o product backlog restante ao longo do tempo de um plano de release. E um burndown de sprint mede os itens do backlog de sprint restantes ao longo do tempo de um sprint (SHWABER, 2010).

Agile: O Ciclo de vida do Scrum

Figura 4 – O Ciclo de Vida da Metodologia Scrum

Adaptado de: 3MONTHS, 2011

A Figura 4 representa o ciclo de vida desenvolvimento de software utilizando a metodologia Scrum. Nela pode-se observar que o product owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja o backlog de produto. Este por sua vez é dividido em pequenas “histórias” menores, pela equipe e pelo product owner. Posteriormente o product owner escolhe então quais dessas histórias serão priorizadas para o sprint originando assim um backlog de sprint.

Após definir-se o backlog do sprint a equipe realiza uma reunião na qual estabelece as suas metas durante o sprint; trata-se da sprint plane meeting (reunião de planejamento do sprint) onde estabelece suas metas durante o sprint. O próximo passo da espiral representa o incremento produzido durante o sprint. É nessa etapa que ocorre o desenvolvimento do produto. Uma vez que o novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz uma revisão do sprint nela a equipe apresenta o que foi realizado durante o sprint e demonstra as novas funcionalidades incorporadas. O product ownwer testa, para verificar se o item atende suas expectativas e determina se a meta do sprint foi ou não atingida.

O próximo passo é a retrospectiva do sprint, nela são levantados o que aconteceu de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria contínua ao trabalho da equipe. Feito isso o backlog de produto é atualizado e o ciclo é reiniciado. Acima do circulo maior, que representa o sprint, tem se outro circulo menor que representa a iteração diária onde são cumpridas as metas diárias que compõem o Sprint. Durante o sprint diário, os membros do time fazem uma pequena reunião de 15 minutos (reunião scrum diária), sempre de pé, no mesmo horário e local. Nela cada membro conta o que fez desde a última reunião o que pretende fazer e se está tendo algum problema.

De acordo com Kniberg (2007) o Scrum fornece bases para a gestão do processo de desenvolvimento, mas não se preocupa com como será feito o desenvolvimento. O XP por sua vez sugere as práticas a serem seguidas para o desenvolvimento de um projeto e não se preocupa com a gestão. Sendo assim muitas equipes ágeis utilizam XP e Scrum juntos, onde um fornece boas práticas de desenvolvimento e o outro, boas práticas de gestão. Devido a essa extensibilidade os autores agilistas tendem a adotar o termo framework e não metodologia quando se referem a elas.

Novas metodologias surgem o tempo todo e as vezes pode parecer dificil escolher uma “correta”. Nesse sentido, Henrajani (2007) afirma que todo projeto deve ter alguma estrutura de processo básico que precisa seguir. Não ter nenhum processo é ruim, mas o excesso deles é igualmente ruim. Sendo assim cabe a equipe encontrar o equilibrio correto, considerando as necessidades do cliente, o tamanho do projeto e as metas da equipe.

Treinamentos relacionados com essa postagem







Referências:

SCHWABER, Ken. Guia do Scrum. Scrum Alliance, 2010. Disponível em: < http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf >  acesso em 04 abr. 2011.

3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wp-content/uploads/2010/01/project_lifecycle_v1cc.png > acesso em: 04 abr. de 2011.

HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São Paulo: Pearson Prentice Hall, 2007.

KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum. InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches > Acesso em 14 nov. 2010.

KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos. InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acesso em 14 nov. 2010.

Leandro Costa

Sou desenvolvedor de software a desde 2008, além de programar gosto de esportes de aventura como rapel, tirolesa, trilhas de bike, apreciador de cervejas, baladas, motos e do bom e velho Rock’n Roll também gosto de história, ficção científica e de tecnologia. Atualmente sou consultor de Agile Software Delivery na Erudio Training e instrutor na Udemy.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *