Scrum é um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não não claros ou mudam com muita frequência. Em Rugby, Scrum é um time de oito integrantes que trabalham em conjunto para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e o time inteiro focando num único objetivo.

Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele pode ser utilizado em equipes de manutenção de software ou como uma abordagem geral de gerenciamento de projetos/programas.

O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos edesenvolvimento ágil de software. Apesar de a palavra não ser um acrônimo, algumas empresas que implementam o processo a soletram com letras maiúsculas como SCRUM. Isto pode ser devido aos primeiros artigos de Ken Schwaber, que capitalizava SCRUM no título.

Scrum não é um processo prescribente, ou seja, ele não descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer.

O objetivo do Scrum é fornecer um processo conveniente para projetos e desenvolvimento orientado a objetos. A metodologia é baseada em princípios semelhantes aos de XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos, e iterações curtas para promover visibilidade para o desenvolvimento. No entanto, as dimensões em Scrum diferem de XP.

Scrum divide o desenvolvimento em sprints de 30 dias. Equipes pequenas, de até 7 pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidade (os requisitos, em outras palavras) definidas no início de cada sprint. A equipe toda é responsável pelo desenvolvimento desta funcionalidade.

Todo dia, é feita uma reunião de 15 minutos onde o time expõe à gerência o que será feito no próximo dia, e nestas reuniões os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento.

Scrum é interessante porque fornece um mecanismo de informação de status que é atualizado continuamente, e porque utiliza a divisão de tarefas dentro da equipe de forma explicita. Scrum e XP são complementares pois Scrum provê práticas ágeis de gerenciamento enquanto XP provê práticas integradas de engenharia de software.

Características

Scrum é um esqueleto de processo que contém grupos de práticas e papéis pré-definidos. Os principais papéis são:

1. o ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto)
2. o Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio
3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto, implementação, teste etc.

Sprint (corrida)

Um sprint é a unidade básica de desenvolvimento em Scrum. Sprints tendem a durar entre uma semana e um mês, e são um esforço dentro de uma “caixa de tempo” (ou seja, restrito a uma duração específica) de um comprimento constante.

• Cada sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
• Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI e por conhecer as necessidades do cliente);
• Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints;
• Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião).
• Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
• Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

Papéis principais

Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum – são os que produzem o produto (objetivo do projeto).

Product Owner (dono do produto)
O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.

Equipe (Development Team)
A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe.

Scrum Master
Scrum é facilitado por um Scrum Master, também escrito como Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva.

Papéis auxiliares

Os papéis auxiliares em equipes Scrum são aqueles com nenhum papel formal e envolvimento frequente no processo de Scrum, mas, ainda assim, devem ser levados em conta.

Partes interessadas (clientes, fornecedores)

Estas são as pessoas que permitem o projeto e para quem o projeto vai produzir o acordado benefício, que justifica a sua produção. Eles só estão diretamente envolvidos no processo durante as revisões sprint.

Gerentes (incluindo gerentes de projeto)
Pessoas que irão configurar o ambiente para desenvolvimento de produtos.

Artefatos

Product Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste.

Sprint backlog
O Sprint backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team.

Planejamento de sprint
Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Reuniões
Daily Scrum
Cada dia durante o sprint, uma reunião de status do projeto ocorre. Isso é chamado de “scrum diário”, ou “de pé o dia”. Esta reunião tem diretrizes específicas:

• A reunião começa precisamente no horário marcado.
• Todos são bem-vindos, mas apenas “poucos” podem falar.
• O encontro tem duração determinada (Time-Box) e dura 15 minutos.
• A reunião deve acontecer no mesmo local e mesma hora todos os dias
• Durante a reunião, cada membro da equipe responde a três perguntas:
• O que você tem feito desde ontem?
• O que você está planejando fazer hoje?
• Você tem algum problema impedindo você de realizar seu objetivo?

É papel do Scrum Master para facilitar a resolução desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a reunião possa durar menos de 15 minutos.

Reunião de Planejamento da Sprint (Sprint Planning Meeting)
No início do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting é realizado.

• Selecione o trabalho que está a ser feito.
• Prepare o Sprint Backlog que detalha o tempo que levará para fazer esse trabalho, com toda a equipe.
• Identificar e comunicar o quanto o trabalho é susceptível de ser feito durante o sprint atual.
• Dividida em duas partes:
• Parte 1 (Primeiras quatro horas): Team Product Owner: diálogo para priorizar o Product Backlog.
• Parte 2 (Próximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando na Sprint Backlog.

No final de um ciclo de sprint, são realizadas duas reuniões: a “Sprint Review” e do “Sprint Retrospective”.

Reunião de Revisão da Sprint (Sprint Review)

• Rever o trabalho que foi concluído e não concluído.
• Apresentar o trabalho realizado para os interessados (ou “a demo”). Um trabalho incompleto não pode ser demonstrado.

Retrospectiva da Sprint (Sprint Retrospective)

• Todos os membros da equipe refletem sobre a sprint passada.
• Faça melhorias contínuas de processos.

Duas questões principais são feitas na retrospectiva do sprint: O que correu bem durante a corrida? O que poderia ser melhorado na próxima sprint?

Fonte: Wikipedia / Handbook de TI