Impossível falarmos de Scrum sem falar primeiro do Manifesto Ágil que nasceu em fevereiro de 2001 em Utah nos EUA.
O Manifesto Ágil
O Manifesto Ágil fez uma revolução, documentando e cravando na indústria de software os princípios e valores do ágil.
Na época, os Lightweight Methods e o Extreme Programming eram os métodos de desenvolvimento que mais cresciam. Eles entraram em alguns consensos e concluíram que os métodos leves não eram mais uma opção e que era preciso um novo formato.
É o início do que conhecemos como Agile.
Leia mais: Scrum e Kanban: entenda as diferenças e qual escolher
Entendendo a Metodologia Scrum
Dentro do desenvolvimento ágil surgiram diversas soluções que implementam os conceitos de iterações contínuas nos projetos de software.
O Scrum não é em si uma metodologia de desenvolvimento, mas um framework no qual pessoas buscam dividir e priorizar o backlog em problemas menos complexos para entregar produtos com um alto valor agregado (com grande fit com o cliente) e em prazos reduzidos.
No Scrum, os projetos são divididos 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 e incrementais, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints, no caso do Scrum.
Quais os papéis da Equipe Scrum
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.
Ele escreve tarefas centradas nos itens do cliente (histórias 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 Scrum Master.
Scrum Master
Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo da sprint/entregas.
Esse profissional 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. Ele é o responsável pela aplicação das regras.
Uma parte fundamental do seu papel é proteger a equipe e mantê-la focada nas tarefas em mãos.
Development Team (Equipe de desenvolvimento)
A equipe de desenvolvimento é responsável pela entrega do produto. A equipe é tipicamente composta de 5 a 9 pessoas com habilidades multifuncionais que fazem o trabalho de: 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 trabalhe com alguma forma de projeto ou gestão de equipe.
Os artefatos oficiais do Scrum
Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. Este artefato é a principal fonte de informação para o Planejamento de sprint (Sprint Planning).
No decorrer da Sprint, o Product Owner, o Scrum Master e a Equipe de desenvolvimento decidem no que a equipe irá trabalhar. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto e o que pode ser repriorizado durante o planejamento da 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 da sprint.
Product Backlog
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 a próxima sprint para implementar tais itens selecionados.
É uma representação em tempo real do trabalho que o DevelopmentTeam planeja concluir na sprint corrente, e ele pertence unicamente ao DevelopmentTeam.
Eventos Scrum
Daily Scrum Meeting
Cada dia durante a Sprint, uma reunião de status do projeto ocorre. Isso é chamado de “scrum diário”, “daily scrum” ou “Stand up meeting” (reunião em pé). Esta reunião tem diretrizes específicas.
São elas:
- A reunião começa precisamente no horário marcado.
- Todos são bem-vindos, mas apenas “poucos” falam.
- O encontro tem duração determinada (Time-Box) de no máximo 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:
1. O que você tem feito desde ontem em direção à meta?
2. O que você está planejando fazer hoje em direção à meta?
3. Você tem algum problema impedindo você de realizar seu objetivo em direção à meta?
É papel do Scrum Master 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 de Sprint (Sprint Planning Meeting)
No início do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting é realizado para:
- Selecionar o trabalho que deve ser feito na Sprint.
- Preparar o Sprint Backlog que detalha o tempo que levará para fazer esse trabalho, junto com toda a equipe.
Geralmente, essa cerimônia é 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): Only Team: planejamento da Sprint, resultando na Sprint Backlog.
No final de um ciclo de sprint, são realizadas duas reuniões: a “Sprint Review” e o “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 stakeholders (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.
- É o momento de fazer melhorias contínuas de processos.
Duas questões principais são levantadas na retrospectiva da sprint:
- O que correu bem durante a Sprint?
- O que poderia ser melhorado na próxima Sprint?
Resumindo
- Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível.
- Isto permite a rápida e contínua inspeção do software em produção (em intervalos de duas a quatro semanas).
- As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade.
- Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”.
Ainda tem alguma dúvida sobre o assunto? Conta pra gente nos comentários!
Aproveite e assine aqui nossa newsletter para receber por e-mail toda semana conteúdos novos sobre tecnologia, inovação, metodologias ágeis e muito mais.
Referências usadas para escrever o artigo:
- Ensinar Scrum na prática
- Scrum certification Preparation (Udemy)
- Scrum Guide (PDF)
- Essential Scrum: A Practical Guide to the Most Popular Agile Process
by Kenneth S. Rubin - Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
by Ilan Goldstein
