Tutorial SCRUM – Parte 3

Scrum

O Scrum Process Framework pode ser visualizado por meio de uma sequência de eventos e os artefatos correspondentes. Os eventos Scrum são eventos com datas e horas. Isso significa que, em um projeto, todo evento scrum tem uma duração máxima predefinida. Esses eventos permitem transparência no progresso do projeto para todos os envolvidos no projeto. Os eventos vitais do scrum são-

  • O Sprint
  • Planejamento do Sprint
  • Reuniões diárias de Scrum
  • Revisão do Sprint
  • Retrospectiva do Sprint

Sprint

Durante um Sprint, um Incremento de produto funcional é desenvolvido. É geralmente de duração de duas semanas ou um mês, e esta duração permanece constante para todos os sprints do projeto. Não podemos ter durações variáveis ​​para os diferentes sprints de um projeto. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

O Sprint Goal é um objetivo definido para o Sprint. Ele fornece orientação para a equipe sobre por que está construindo o Incremento. É criado durante a reunião de Planejamento do Sprint. O escopo do sprint é esclarecido e renegociado entre o Product Owner e a Equipe, à medida que os requisitos são aprendidos. Assim, cada Sprint está associado a ele, uma definição do que deve ser construído, um design e o plano flexível que guiará a construção, o trabalho de desenvolvimento e o incremento de produto resultante.

Um Sprint deve ser cancelado se o objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se a organização mudar de direção ou se as condições de mercado ou tecnologia mudarem. Um sprint pode ser cancelado apenas pelo Product Owner, embora outros tenham influência sobre o mesmo.

Devido à natureza de curta duração dos Sprints, o cancelamento durante um sprint raramente faz sentido. Como os cancelamentos de sprint consomem recursos, para serem reorganizados em outro Sprint, eles são muito incomuns.

Se um Sprint for cancelado e parte do trabalho produzido durante o sprint for potencialmente liberado, o Product Owner normalmente o aceita. Todos os itens incompletos do Backlog do Sprint são colocados de volta no Backlog do Produto.

Planejando o Sprint

O trabalho a ser executado na Sprint está planejado na Reunião de Planejamento do Sprint. A Reunião de Planejamento do Sprint tem duração máxima de quatro horas para sprints de duas semanas e oito horas para Sprints de um mês. É responsabilidade do Scrum Master garantir que a reunião ocorra e que todos os participantes necessários estejam presentes e compreendam o objetivo da reunião agendada. O Scrum Master modera a reunião para monitorar o sustento da discussão e encerramento no prazo.

O Planejamento do Sprint se concentra nas duas perguntas a seguir:

  • O que precisa ser e pode ser entregue no Incremento do Sprint?
  • Como será o trabalho necessário para a execução do Sprint?

A Revisão do Sprint inclui os seguintes aspectos:

  • Os participantes incluem o Time Scrum e os principais interessados, conforme convidados pelo Product Owner.
  • O Product Owner explica quais itens do Backlog do Produto foram concluídos durante o sprint e o que não foi concluído.
  • O Product Owner explica quais itens do Backlog do Produto foram concluídos durante o sprint e o que não foi concluído.
  • A equipe discute o que deu certo durante o Sprint, que problemas enfrentou e como esses problemas foram resolvidos.
  • A Equipe demonstra o trabalho que foi concluído e responde a perguntas, se houver, sobre o Incremento.
  • O grupo inteiro discute o que fazer a seguir. Assim, a Revisão do Sprint fornece uma entrada valiosa para o Planejamento do Sprint do Sprint subsequente.
  • O Time Scrum então revisa o cronograma, o orçamento, as capacidades potenciais e o mercado para a próxima liberação antecipada do incremento do produto.
  • O resultado da Revisão do Sprint é um Backlog do Produto atualizado, que define os itens prováveis do Backlog do Produto para a próxima Sprint.

Retrospectiva

A Retrospectiva do Sprint ocorre após a Revisão do Sprint e antes do próximo Planejamento do Sprint. Isso geralmente é uma reunião de uma hora para sprints de duração de duas semanas e uma reunião de três horas para Sprints de duração de um mês.

O objetivo da Retrospectiva do Sprint é:

  • Combine os aprendizados do último Sprint, com relação a pessoas, relacionamentos, processos e ferramentas.
  • Identifique os principais itens que correram bem e possíveis melhorias.
  • Criação de um plano para implementar melhorias para aumentar a qualidade do produto.

A Retrospectiva do Sprint é uma oportunidade para o Time Scrum se introspectar e melhorar dentro da estrutura do processo Scrum, de modo a tornar o próximo resultado do Sprint mais efetivo.

Artefatos

Os Artefatos do Scrum fornecem informações importantes que o Time Scrum e os stakeholders precisam conhecer para entender o produto em desenvolvimento, as atividades realizadas e as atividades que estão sendo planejadas no projeto. Os seguintes artefatos são definidos no Scrum Process Framework –

  • Backlog do Produto
  • Backlog do Sprint
  • Carta Burn-Down
  • Incremento

Esses são os artefatos mínimos necessários em um projeto scrum e os artefatos do projeto não são limitados por eles.

Backlog de Produto

O Backlog do Produto é uma lista ordenada de recursos que são necessários como parte do produto final e é a única fonte de requisitos para quaisquer alterações a serem feitas no produto.

O Backlog do Produto lista todos os recursos, funções, requisitos, aprimoramentos e correções que constituem as alterações a serem feitas no produto em versões futuras. Os itens do Backlog do Produto têm os atributos de uma descrição, pedido, estimativa e valor. Esses itens são normalmente denominados como Histórias de Usuário. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e pedido.

Um v é um artefato em evolução. A versão mais antiga pode conter apenas os requisitos inicialmente conhecidos e mais bem compreendidos. O Backlog do Produto é desenvolvido conforme o produto e o ambiente no qual ele será usado, progresso. O backlog muda constantemente para incorporar o que é necessário para torná-lo efetivo. Desde que exista um produto, o backlog também existe.

À medida que o produto sendo construído é usado e ganha valor, o backlog se torna uma lista maior e mais exaustiva. Alterações nos requisitos de negócios, condições de mercado ou tecnologia causam alterações no backlog do Produto, tornando-o um artefato ativo.

O refinamento do Backlog do Produto significa adicionar detalhes, estimativas e ordem de prioridade aos itens do Backlog do Produto. Este é um processo contínuo realizado pelo Product Owner e pela equipe. O Time Scrum decide como e quando o refinamento deve ser feito.

Os itens do backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do proprietário do produto.

Os itens do Backlog do Produto ordenados mais altos geralmente são mais claros e mais detalhados do que os pedidos com pedidos inferiores. Estimativas mais precisas são feitas com base na maior clareza e maior detalhe. Quanto menor a ordem, menor é o detalhe.

Os itens do Backlog do Produto que podem ser os requisitos candidatos para o próximo Sprint são refinados para que esses itens possam ser desenvolvidos durante o Sprint. Os itens do backlog que podem ser desenvolvidos pela Equipe em uma Sprint são considerados prontos para seleção em uma reunião de planejamento do Sprint.

Backlog do Sprint

O Backlog do Sprint é o conjunto de itens do Backlog do Produto selecionado para o Sprint, além de um plano para entregar o Incremento do produto e realizar o Objetivo do Sprint.

O Backlog do Sprint é uma previsão da equipe sobre qual funcionalidade será disponibilizada no próximo Incremento e o trabalho necessário para fornecer essa funcionalidade como um Incremento de produto funcional.

O Backlog do Sprint é um plano com detalhes suficientes que podem ser entendidos, mas a equipe deve acompanhar no Daily Scrum. A equipe modifica o Backlog do Sprint em todo o Sprint, e o Backlog do Sprint surge durante o Sprint. Esse surgimento ocorre quando a equipe trabalha com o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.

Como um novo trabalho é necessário, a equipe o adiciona ao Backlog do Sprint. Conforme o trabalho é executado ou concluído, o trabalho restante estimado é atualizado. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente a equipe pode alterar seu Backlog do Sprint durante um Sprint. O Backlog do Sprint é um quadro altamente visível e em tempo real do trabalho que a equipe pretende realizar durante o Sprint, e pertence exclusivamente à equipe.

Incremento

O Incremento é a soma de todos os itens do Backlog do Produto concluídos durante um Sprint combinados com os incrementos de todos os Sprints anteriores. No final de um Sprint, o novo Incremento deve ser um produto funcional, o que significa que deve estar em condições de uso. Ele deve estar em condições de funcionamento, independentemente de o Product Owner decidir realmente liberá-lo.

O Time Scrum precisa ter consenso sobre o que é considerado um Incremento. Isso varia significativamente de acordo com o Time Scrum, mas os membros da equipe devem ter uma compreensão compartilhada do que significa o trabalho ser completo. Isso é usado para avaliar quando o trabalho é concluído no Incremento do produto.

O mesmo entendimento orienta a Equipe em saber quantos itens do Backlog do Produto ele pode selecionar durante um Planejamento da Sprint. O objetivo de cada Sprint é entregar Incrementos de funcionalidade potencialmente liberável.

As equipes entregam um incremento da funcionalidade do produto a cada Sprint. Esse Incremento é utilizável, portanto, um Product Owner pode optar por liberá-lo imediatamente. Se a compreensão de um incremento fizer parte das convenções, padrões ou diretrizes da organização de desenvolvimento, todos os Times Scrum devem segui-lo no mínimo. Se não for uma convenção da organização de desenvolvimento, o Time Scrum deve definir uma definição de Incremento apropriada para o produto.

Cada Incremento é aditivo a todos os Incrementos anteriores e totalmente testado, garantindo que todos os Incrementos trabalhem juntos.

À medida que as equipes de Scrum amadurecem, espera-se que suas definições de Incrementos se expandam para incluir critérios mais rigorosos para maior qualidade. Qualquer produto deve ter uma definição de Incremento que seja um padrão para qualquer trabalho feito nele.

No próximo post finalizaremos a série deste tutorial.

*** A OctalMind é uma empresa especializada no desenvolvimento de sistemas de alta tecnologia.