Introdução ao Scrum: Eventos e regras

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (5)  (0)

Veja neste artigo uma introdução ao Scrum e aos seus principais elementos, framework que tem como principal característica adotar uma estratégia interativa e incremental, como é feito em diversos processos de software como XP, Lean, entre outros.

O Scrum é um framework criado no inicio dos anos 90 e muito utilizado hoje para o desenvolvimento de software. O Scrum é dito como sendo um framework, pois ele não prescreve nada, não é um processo e nem mesmo uma técnica e é perfeitamente adaptável. No Scrum podemos incluir diversas técnicas utilizadas em outros processos, dessa forma podemos sempre melhora-lo.

Este framework tem como principal característica adotar uma estratégia iterativa e incremental como é feito em diversos processos de software como Extreme Programming, Lean, entre outros. Esse tipo de abordagem é a melhor alternativa para que possamos aperfeiçoar a previsão de quando o produto será entregue e controlar os riscos do software sendo desenvolvido.

O Scrum é considerado leve, simples de entender, mas extremamente difícil de dominá-lo.

No restante do artigo veremos quais são os participantes, eventos, papéis, artefatos e as regras do Scrum.

Participantes do Scrum

O Scrum é composto por um time que consiste do Product Owner, da Equipe de Desenvolvimento e do Scrum Master. Esse time é auto organizável, ou seja o próprio time escolhe as melhores formas para completarem o trabalho sem precisar serem dirigidos por outras pessoas, e multifuncional, ou seja possuem as habilidades necessárias para realizar o trabalho sem depender de outros que não são parte da equipe. Todas essas características ajudam o time Scrum a ganhar mais em produtividade, criatividade e flexibilidade.

Explicando de forma mais objetiva os participantes do time Scrum temos primeiramente o Product Owner que é o responsável por gerenciar o Backlog do Produto, que será melhor visto posteriormente. Dessa forma, o Product Owner expressa para a equipe os itens do Backlog do Produto, ordena os itens, garante o valor o trabalho que foi realizado pelo time de desenvolvimento, garante a visibilidade do Backlog do produto e garante que a equipe de desenvolvimento entenda os itens do Backlog do Produto. Como pode ser verificado, o Product Owen é uma pessoa que está perto do cliente e entende o que o cliente quer e o que ele acha prioritário.

A equipe de desenvolvimento é composta por todos aqueles que têm a responsabilidade de realizar o trabalho de entregar uma versão “usável” que incrementa o produto ao final de cada Sprint. Portanto, essa equipe é composta pelos profissionais técnicos que sabem como fazer o produto que o cliente vai usar. Essa equipe é estruturada e autorizada pela organização para organizar e gerenciar seu próprio trabalho. Isso impulsiona a equipe a ter uma maior eficiência e eficácia. A Equipe de Desenvolvimento tem como características a auto-organização onde eles sabem como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis pelos clientes. A equipe de desenvolvimento também possuem características multifuncionais onde eles possuem habilidades necessárias para criar o incremento do produto e não possuem especialidades, ou seja, não são totalmente dedicados a domínios específicos como teste ou análise de negócio.

O Scrum Master tem como responsabilidade garantir que o Time Scrum entenda toda a teoria, prática e regras do Scrum e que tudo seja aplicado nos projetos. O Scrum Master também ajuda o Product Owner encontrando técnicas para gerenciar de forma efetiva o Backlog do Produto, a comunicar a visão, objetivo e itens do Backlog do Produto, ensinar ao TimeScrum como criar itens de Backlog do Produto que sejam claros e concisos, a compreender o planejamento do produto como um todo, a compreender e praticar a agilidade e ajuda a praticar os eventos do Scrum, que serão vistos posteriormente. Além de ajudar o Product Owner o Scrum Master também ajuda a Equipe de Desenvolvimento treinando a equipe em autogerenciamento e interdisciplinaridade, ensina e lidera a equipe de desenvolvimento na criação de produtos de alto valor, e remove eventuais impedimentos que a equipe venha a possuir. O Scrum Master também pode servir à organização liderando e treinando a organização na adoção do Scrum, ajudando funcionários de outros projetos e outras equipes a compreender e aplicar o Scrum, e em diversas outras situações onde o Scrum Master possa atuar e ajudar.

Eventos do Scrum

O SCRUM também possui alguns eventos que são utilizados para criar uma rotina e também minimizar qualquer outra reunião que não sejam as definidas pelo SCRUM. Todos os eventos do SCRUM possuem uma duração máxima. Além disso, todos os eventos devem ser realizados, isso garante transparência e inspeção criteriosa.

Todo projeto realizado com SCRUM possui uma Sprint, que tem duração de um mês ou menos, onde se cria o produto que será utilizado pelo cliente. Essas Sprints são compostas por uma reunião de planejamento, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.

Nas Sprints tem-se a definição do que é para ser construído, um plano bem projetado e flexível que será responsável por guiar a construção, o trabalho e o resultado do produto.

O primeiro evento da Sprint é a reunião de planejamento que é onde planejamos a Sprint. Todo o time Scrum participa desta reunião. A duração máxima para este evento é de oito horas para uma Sprint de um mês, se a Sprint for menor o tempo do evento também deverá ser menor. Por exemplo, uma Sprint de duas semanas terá uma reunião de planejamento de quatro horas.

Essa reunião é composta por duas partes onde normalmente respondemos as perguntas abaixo em cada metade do tempo:

  • O que será entregue como resultado do incremento da próxima Sprint?
  • Como o trabalho necessário para entregar o incremento será realizado?

Na primeira pergunta nos concentramos em respondê-la na primeira parte da reunião de planejamento. Nesta parte a equipe de desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. Para isso o Product Owner apresenta os itens do Backlog do Produto ordenados para a Equipe de Desenvolvimento e todo o Time Scrum colabora com o entendimento do trabalho da Sprint.

Dessa forma, a reunião de planejamento possui como entrada o Backlog do Produto, o mais recente incremento do Produto, a capacidade projetada da Equipe de Desenvolvimento e o desempenho passado de outras Sprints. A equipe de desenvolvimento seleciona o número de itens do Backlog do produto para a Sprint, somente a equipe de desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint.

A segunda parte da reunião é responsável por responder a pergunta "Como o trabalho necessário para entregar o incremento será realizado?". Agora que o trabalho foi selecionado, a Equipe de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento do Produto. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint. Com o trabalho planejado pela Equipe de Desenvolvimento para os primeiros dias da Sprint, este é decomposto em unidades de um dia de duração ou menos até o final desta reunião. A Equipe de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante a reunião de planejamento da Sprint quanto no que for necessário durante a Sprint. Nessa segunda parte da reunião pode ser interessante chamar o Product Owner ou então especialistas para ajudar a determina o trabalho suficiente para finalizar os itens da Sprint.

Outro evento utilizado no SCRUM é a Reunião Diária que tem um tempo definido de 15 minutos. Essa reunião é utilizada para que a equipe de desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.

Nesta reunião inspeciona-se o trabalho desde a última reunião diária (ocorrida na manhã anterior), e prevê o trabalho que será feito antes da próxima reunião diária (na manhã seguinte).

O ideal é que a reunião diária ocorra todos os dias e sempre no mesmo horário e no mesmo local. Durante esta reunião cada integrante da equipe de desenvolvimento responde as seguintes perguntas:

  • O que foi completado desde a última reunião?
  • O que será feito até a próxima reunião?
  • Quais os obstáculos que estão no caminho?

Esta reunião é bastante importante para avaliar o progresso em direção ao objetivo da Sprint. A reunião diária aumenta significativamente o objetivo da Sprint. O Scrum Master é responsável por assegurar que a equipe de desenvolvimento tenha a reunião, e a equipe de desenvolvimento é responsável por conduzir a reunião diária. O Scrum Master também ensina a equipe de desenvolvimento a manter a reunião diária dentro dos 15 minutos permitidos.

Entre as vantagens da reunião diária temos uma melhoria nas comunicações, eliminação de outras reuniões, identificação e remoção de impedimentos para o desenvolvimento, e melhoria no nível de conhecimento da Equipe de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.

A Revisão da Sprint por sua vez é um evento executado ao final da Sprint para inspeção de como foi a Sprint e se é necessário uma adaptação do Backlog do Produto. Durante esta reunião o Time Scrum e as partes interessadas trocam ideias sobre o que foi feito na Sprint. Esta reunião é informal e a demonstração do que foi feito na Sprint motiva a obtenção de comentários e promove a colaboração. A reunião da Sprint não pode ultrapassar 4 horas de duração para uma Sprint de um mês, devendo diminuir o tempo para Sprints menores.

Portanto, na Revisão da Sprint temos os seguintes elementos:

  • O Product Owner identifica o que foi feito e o que não foi feito na Sprint.
  • A Equipe de desenvolvimento discute o que foi bem e quais problemas ocorreram e como foram resolvidos dentro da Sprint.
  • A Equipe de desenvolvimento demonstra o trabalho que está feito e responde quaisquer questões relativas ao incremento.
  • O Product Owner discute como o Backlog do Produto está atualmente e projeta as datas de conclusão baseando-se no progresso até agora.
  • Todo o grupo discute sobre o que fazer na próxima Sprint. Com isso a reunião de revisão também fornece entradas para a Reunião de Planejamento.

Assim sendo, a reunião de revisão é um Backlog do Produto revisado e define também o provável Backlog do Produto para a próxima Sprint. Nada impede também do Backlog do Produto ser ajustado para atender as novas oportunidades.

Por fim, o último evento que temos é a Retrospectiva da Sprint que é onde o Time Scrum inspeciona a si próprio e cria um plano para melhorias a serem aplicadas nas próximas Sprints. Esta reunião de retrospectiva sempre ocorre antes da reunião de planejamento da próxima Sprint. O tempo estimado para a reunião de retrospectiva é de três horas para uma Sprint de um mês, podendo ser menor se a Sprint for menor.

O propósito da Reunião de Retrospectiva da Sprint é:

  • Inspecionar como foi a última Sprint em relação às pessoas, relações, processos e ferramentas.
  • Identificar e ordenar os principais itens que foram bem e possíveis melhorias.
  • Criar um plano para que sejam implementadas melhorias no modo que o Time Scrum faz o seu trabalho.

Essa reunião de retrospectiva ajuda o Time Scrum a melhorar, melhorar o processo de desenvolvimento e as práticas. Além disso, o Time Scrum planeja formas para aumentar a qualidade do produto.

Artefatos do Scrum

Os artefatos do Scrum são projetados para fornecerem a transparência das informações necessárias para assegurar que o Time Scrum tenha sucesso na entrega do produto.

O primeiro artefato do Scrum é o Backlog do Produto que se trata de uma lista ordenada de tudo que deve ser necessário para o produto. O responsável pelo Backlog do Produto é o Product Owner, e isso inclui o conteúdo do Backlog do Produto, a disponibilidade e a ordenação. O Backlog do Produto nunca está completo. No inicio o Backlog do Produto tem apenas os requisitos inicialmente conhecidos e melhor entendidos, após isso o Backlog do Produto vai evoluindo tanto quando o produto e o ambiente na qual ele será utilizado. Portanto, o Backlog do Produto é dinâmico, mudando sempre para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. Enquanto o produto existir o Backlog do produto também existirá, sempre se adequando quando for necessário.

No Backlog do Produto temos as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Todos os itens do Backlog do Produto possuem os atributos da descrição, ordem e estimativa. O Backlog do Produto é ordenado por valor, risco, prioridade e necessidade. Todos os itens que estão no topo do Backlog do Produto determinam as atividades de desenvolvimento mais prioritárias. Quanto maior a ordem de um item mais o item deve ser considerado e, portanto mais claros e mais detalhados esses itens devem ser em relação aos itens de ordem mais baixa.

É sempre bom ressaltar que mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto. Assim, o Backlog do Produto é usado para descrever o trabalho previsto para o produto. A equipe de desenvolvimento em conjunto com o Product Owner colaboram nos detalhes dos itens do Backlog do Produto adicionando detalhes, estimativas e ordem aos itens no Backlog do Produto. Porém os itens do Backlog do Produto também podem ser atualizados a qualquer momento pelo Product Owner. De uma forma geral a Equipe de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.

Outro artefato muito importante no Scrum é o Backlog da Sprint que se trata de um conjunto de itens do Backlog do Produto selecionados para a Sprint. No Backlog da Sprint temos uma previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará na próxima versão que será entregue ao cliente. O Backlog do Produto torna visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint, além disso, o Backlog da Sprint também pode ser modificado pela equipe de desenvolvimento ao longo da Sprint na medida em que se tem mais conhecimento do que deve ser feito. Somente a Equipe de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. Portanto, podemos concluir que o Backlog da Sprint é altamente visível, esse Backlog é como uma imagem em tempo real do trabalho que a Equipe de Desenvolvimento planeja completar durante a Sprint. O Backlog da Sprint pertence exclusivamente à Equipe de Desenvolvimento.

Com isso, neste artigo vimos o que é o Scrum e quais são seus papéis, eventos, regras, etc. Também verificamos que o Scrum funciona como um framework para que sejam agregadas outras técnicas, metodologias e práticas.

Bibliografia

[1] Mike Cohns: Succeding with Agile. Disponível em http://www.mountaingoatsoftware.com/blog/

[2] Ken Schwaber e Jeff Sutherland. Scrum Guide. Disponível em http://www.scrum.org

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?