Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.
No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.
A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.
É 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 ScrumMaster e equipe de desenvolvimento e deve estar disponível para responder às perguntas tão logo estas são feitas.
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 ScrumMaster 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.
No Scrum é definido o papel do Time de Desenvolvimento, que é simplesmente a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.
A idéia principal é que a equipe de desenvolvimento se auto-organiza para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.
- Um time de desenvolvimento tem tipicamente entre 5 e 9 pessoas; e seus membros devem ter coletivamente todas as habilidades necessárias para produzir, com qualidade, software 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 9 ou menos pessoas.
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.
Figura 1: Funcionamento do Modelo SCRUM
Fonte: MINDMASTER (2014).
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 Grooming, 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.
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.
Figura 2: Funcionamento da Atividade Product Backlog
Fonte: MINDMASTER (2014).
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 Product backlog é um 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 Grooming.
- 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. O Scrum não especifica como você deve medir o tamanho dos itens do backlog. Na prática, muitas equipes usam uma medida de tamanho relativo, como Story Point ou dias ideais.
Essa questão sobre estimativas é um capítulo a parte e cabe um post depois para explicar somente isso.
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.
Figura 3: Funcionamento da Atividade Sprint.
Fonte: MINDMASTER (2014).
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 é a reunião do Scrum, onde acontece o planejamento de um Sprint. Estão presentes o Product Owner, o Scrum Master e o Time. Outras pessoas interessadas ou responsáveis pelo projetos também podem ser convidadas, mesmo isso não sendo uma prática comum.
O Sprint Planning normalmente é divido em duas partes, onde na primeira parte é apresentado o que vai ser desenvolvido e na segunda parte é definido o como vai ser feito.
Durante a primeira parte do Sprint Planning, o Product Owner apresenta com uma visão de negocio os itens do Product Backlog com maior prioridade. O Time faz perguntas para entender e já rascunhar algumas possíveis soluções técnicas. Uma vez que os itens apresentados irão formar o Sprint Backlog.
Em conjunto o Scrum Team e o Product Owner irão definir uma meta para o Sprint. Uma boa meta do Sprint é descrita em um ou duas frases no máximo. Ela deve descrever o que o time deve alcançar durante o Sprint.
Alguns exemplos de Sprint Goal:
-
Implementar um carrinho de compras básico, incluindo adicionar, atualizar e remover quantidades.
-
Desenvolver o cadastro de clientes, podendo criar mais de uma conta.
Logo após a Sprint Planning parte 01, o Time deve se reunir para realizar o planejamento técnico dos itens do Sprint Backlog. Nessa etapa é onde vai acontecer a quebra técnica dos itens em tarefas. Também é nesse momento que o Time estima os itens e tarefas do Sprint Backlog.
Importante ressaltar que é o Time que define a quantidade de trabalho que vai ser desenvolvido durante o Sprint.
Ao finalizar a Sprint Planning teremos dois artefatos prontos: Meta do Sprint e o Sprint Backlog. A revisão e validação do sucesso ou não da planning irá acontecer no Sprint Review, que acontece ao final do Sprint.
No Scrum, as reuniões são constantes. A Daily Scrum acontece diariamente no mesmo local e horário. Nela, os integrantes ficam em pé para facilitar a circulação no ambiente, bem como para reduzir os riscos de ultrapassar o limite de quinze minutos.
Na Daily Scrum a equipe responde a três perguntas:
- O que fiz ontem?
- O que farei hoje?
- Existe impedimento?
Um exemplo de Daily Scrum é apresentado na Figura 4, onde se tem os integrantes dispostos em pé em frente ao Sprint Backlog do projeto.
Figura 3: Funcionamento da Atividade Daily Scrum.
Fonte: es-it.blogspot.com (2014).
Para saber quando, e como, uma parte do produto ou funcionalidade 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 integrantes 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.
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. Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.
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.
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.
-
DESENVOLVIMENTO ÁGIL, SCRUM [2013-2018]. Disponível em: <https://www.desenvolvimentoagil.com.br/scrum/>. Acesso em: 20 nov. 2018.
-
MINDMASTER: EDUCAÇÃO PROFISSIONAL, Scrum: A Metodologia Ágil Explicada de forma Definitiva. jun.14. 2018. Disponível em: <https://www.desenvolvimentoagil.com.br/scrum/>. Acesso em: 20 nov. 2018.
-
MÉTODO ÁGIL, Sprint Planning: Planejando o Sucesso no Review. [2017-2018]. Disponível em: <https://www.desenvolvimentoagil.com.br/scrum/>. Acesso em: 20 nov. 2018.
-
FERREIRA, C. Implantando práticas do Scrum e do XP em um projeto de software. 09 nov. 2016. Disponível em: <https://www.devmedia.com.br/implantando-praticas-do-scrum-e-do-xp-em-um-projeto-de-software/37280>. Acesso em: 20 nov. 2018.