Scrum: A Metodologia Ágil Explicada de forma Definitiva

O que é Scrum Afinal?

Scrum é basicamente uma forma de organizar (e executar) todo o trabalho a ser feito.

E por mais que atualmente existam muitos materiais gratuitos na internet, e muitos livros escritos sobre assunto, eu ainda recebo muitas dúvidas básicas.

Ou, se preferir, também pode assistir a este vídeo onde explico o Scrum em apenas 9 minutos:

Visão Geral da Metodologia Ágil Scrum

Em primeiro lugar, Scrum não é uma metodologia.

Eu chamei de “Metodologia Ágil Scrum” no título de forma proposital, pois a maioria das pessoas o chamam assim.

Mas o Scrum não é um processo padronizado onde metodicamente você segue uma série de etapas sequenciais e que vão garantir que você produza, no prazo e no orçamento, um produto de alta qualidade e que encanta os seus clientes.

Em vez disso, o Scrum é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software.

O framework Scrum é um conjunto de valores, princípios e  práticas que fornecem a base para que a sua organização adicione suas práticas particulares de gestão e que sejam relevantes para a realidade da sua empresa.

O resultado será uma versão de Scrum que é exclusivamente sua.

Para melhor entender este conceito, imagine que o framework seja como a fundação e as paredes de um edifício.

Os valores do Scrum, princípios e práticas  seriam os principais componentes estruturais.

Você não pode ignorar ou mudar fundamentalmente um valor, princípio ou prática sem o risco de colapso.

O que você pode fazer, porém, é personalizar o interior da estrutura do Scrum, acrescentando artefatos e recursos até que você tenha e um processo que funciona para sua empresa.

O 3-5-3 do Scrum

A base fundamental do Scrum é representada na figura abaixo:

Os Papéis do Scrum

Uma equipe Scrum é composta basicamente de  três papéis:

• Product Owner,
• Scrum Master e
• Developers;

O Product Owner

Product Owner é o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.

É responsabilidade dele manter e comunicar a todos os outros participantes uma visão clara do que a equipe Scrum está buscando alcançar no projeto. Como tal, ele é responsável pelo sucesso global da solução.

Para garantir que a equipe construa rapidamente o que o Product Owner precisa, ele deve colaborar ativamente com o Scrum Master com e os Developers, e deve estar disponível para responder às perguntas tão logo estas são feitas.

O Scrum Master

O Scrum Master é responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum.

Ela age como um Coach, executando a liderança do processo e ajudando a equipe Scrum (e o resto da organização) a desenvolver sua própria abordagem do Scrum, que tenha a melhor performance, respeitando as particularidades da organização.

O Scrum Master também tem um papel de facilitador. Ele deve ajudar a equipe a resolver problemas e fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe contra interferências externas e assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade.

Normalmente o ScrumMaster não tem autoridade para exercer o controle sobre a equipe, de modo que este papel não é o mesmo que o papel tradicional do Gerente de Projeto ou Gerente de Desenvolvimento. O ScrumMaster age como um líder, não como um gerente.

Developers

E dado o nome de Developers para todas as pessoas que fazem parte da equipe que realmente executa o trabalho. Normalmente é uma equipe multidisciplinar, responsável por entregar algo pronto e funcionando ao final de cada Sprint.

A idéia principal é que a equipe de desenvolvimento se autogerencia para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.

A equipe de developers devem ter coletivamente todas as habilidades necessárias para produzir, com qualidade, algo funcionando.

Claro, scrum pode também ser usado em projetos que exigem equipes muito maiores.

No entanto, ao invés de ter uma equipe Scrum com, digamos, 30 pessoas, seria melhor ter entre 3 ou mais times scrum, cada um com um time de até 10 pessoas.

Atividades e Artefatos Principais

Abaixo eu apresento um outro tipo de imagem que é também muito utilizada para representar as interações entre as atividades no processo.

Deixa eu explicar um pouco como interpretar esta imagem.

O Product Owner tem uma visão do que ele quer criar (o grande cubo). Como o o cubo pode ser grande, por meio de uma atividade chamada Refinamento do Backlog (ou refinement), ele é dividido em um conjunto de funcionalidades que são compilados em uma única lista priorizada chamado de Product Backlog.

Então é feito a primeira reunião de Planejamento de Sprint, para definir o Sprint Backlog, que contém todo o trabalho que será executado durante o Sprint.

O Sprint tem duração média de 2 a 4 semanas e são feitas reuniões diárias de acompanhamento (Daily Scrum) do trabalho.

Product Backlog

No Scrum, sempre fazemos o trabalho mais importante primeiro.

O Product Owner, com ajuda do resto da equipe Scrum e as partes interessadas, é o responsável por determinar e gerir a seqüência deste trabalho e comunicando-o na forma de uma lista de prioridades conhecida como o Product Backlog

O Product Owner,  em conjunto com as demais partes interessadas no produto, definem os itens do Product Backlog.

Em seguida, ele garante que os itens do Backlog são colocadas na seqüência correta (usando fatores como valor, custo, conhecimento e risco), de modo que os itens de alto valor, aparecerá no topo do backlog do produto e os itens de menor valor aparecer em direção ao fundo.

O Backlog é uma lista (documento) que está constantemente evoluindo. Os itens podem ser adicionados, excluídos e revisto pelo Product Owner por conta de mudanças nas condições de negócios, ou conforme a compreensão da equipe Scrum sobre o produto aumenta.

Em geral a atividade de criar e de refinar os itens do product backlog, estimando o tamanho e esforço de cada item, é chamada de Refinamento.

Antes de finalizar a priorização,  ou refinamento do produto backlog, é preciso saber o tamanho de cada item. É importante que o Product Owner saiba o custo de cada item para que possa determinar a sua prioridade de forma adequada.

Sprints

No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calendário chamado de Sprints.

O trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente ou usuário. Sprints são timeboxed (duração fixa) para que tenham sempre um início e fim data fixa, e, geralmente, todos eles devem estar com a mesma duração.

Um novo Sprint segue imediatamente a conclusão do Sprint anterior e, via de regra, não devemos permitir nenhuma alteração de escopo ou pessoal durante um Sprint (mas por experiência própria posso afirmar que esta regra é quase sempre quebrada devido à algumas necessidades de negócio)

Sprint Planning

O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais do que pode ser concluído em um único e curto sprint.

Para determinar quais os subconjuntos de itens do Product Backlog mais importantes para construir no próximo sprint, o product owner, junto com os developers e ScrumMaster, devem realizar o Sprint Planning (planejamento de sprint ).

Além disso, durante o planejamento do sprint, a equipe de desenvolvimento e o product owner devem chegar a um acordo sobre qual o Objetivo do Sprint.

Com este objetivo em mãos, eles determinam quais os itens do backlog devem ser priorizados para serem executados neste Sprint.

A maioria das equipes Scrum que estão realizando Sprints de duas semanas a um mês de duração tentam completar o planejamento do sprint em cerca de 4 a 8 horas.

Um sprint de um mês não deve tomar mais do que 8 horas para planejar.

Daily Scrum

No Scrum existe uma reunião diária que idealmente é no mesmo horário, entre os membros da equipe com tempo definido (15 minutos ou menos), chamada Daily Scrum.

A ideia da Daily Scrum é ver como o time está em relação à direção da Meta da Sprint e produzir um plano de ação para o próximo dia de trabalho.

Isso cria foco e melhora o autogerenciamento.

Definition of Done (Definição de Pronto)

No Scrum nós consideramos como resultado do Sprint uma entrega concluída.

Para saber quando, e como, uma parte do produto ou serviço deve ser considerada concluída nós utilizamos um documento chamado Definition of Done.

Embora, isso varie significativamente de um extremo ao outro para cada time Scrum, os membros do time devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.

Sprint Review (Revisão do Sprint)

No final do Sprint, existem duas atividades adicionais que são fundamentais. Uma delas é chamada Sprint Review.

O objetivo desta atividade é verificar e adaptar o produto que está sendo construído.

Recolher um conjunto de requisitos que serão incrementais para manter o projeto de forma saudável e produtiva.

Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.

Sprint Retrospective (Retrospectiva do Sprint)

Enquanto o objetivo do Sprint Review é verificar necessidades de adaptações no produto, o Sprint Retrospective tem como objetivo verificar necessidades de adaptações no processo de trabalho.

Nesse momento a equipe irá refletir sobre como as coisas foram feitas.

A Retrospectiva do Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês.

Conclusão

Este post descreveu as principais práticas do núcleo do Scrum, com foco em uma descrição end-to-end dos papéis do framework Scrum, atividades e artefatos.