Scrumé um framework de gestão de projetos que enfatiza trabalho em equipe, responsabilidade e progresso iterativo em direção a objetivos claramente definidos. Ele começa com uma premissa simples: comece com o que você pode ver ou saber. Em seguida, acompanhe o progresso e ajuste conforme necessário.
Os Três Pilares do Scrum
O Scrum é fundamentado na empiria, que afirma que o conhecimento vem da experiência e que as decisões devem ser baseadas no que é conhecido. Esses três pilares unem o Scrum.
Por que Scrum?
O Scrum entrega funcionalidades de forma incremental, enquanto o Waterfall entrega apenas em fases. O desenvolvimento tradicional Waterfall é um processo sequencial baseado em fases, onde o valor não é entregue até o final do projeto. O Scrum transforma esse modelo ao entregar novas funcionalidades a cada sprint — tipicamente a cada 2 a 4 semanas — em vez de se concentrar em um grande lançamento futuro.
O Scrum divide o trabalho complexo em partes gerenciáveis, divide organizações grandes em pequenas equipes e transforma projetos impactantes em uma série de sprints curtos e com tempo definidosprints.
Por meio do desenvolvimento iterativo e incremental, as empresas podem entregar produtos e serviços que os clientes realmente precisam mais rapidamente e com maior eficiência. Com o Scrum, você pode receber e integrar o feedback dos clientes ao final de cada sprint, o que significa que seus resultados são moldados pelo uso no mundo real, e não por suposições. Isso torna mais fácil manter clientes e partes interessadas-chave ativamente envolvidos.
Ágil vs Scrum
Ágilé uma prática que permite a iteração contínua no desenvolvimento e testes ao longo de todo o ciclo de vida do software. O Ágil divide produtos em componentes menores e gerenciáveis.O Scrum é apenas um dos muitos processos de desenvolvimento de software Ágil iterativos e incrementaisque nos permitem nos concentrar em entregar valor de negócios no menor tempo possível.
O Scrum geralmente lida com requisitos que podem mudar ou são desconhecidos no início de um projeto. O Scrum é caracterizado por:
- Leve
- Fácil de entender
- Difícil de dominar
Benefícios do Scrum
Aqui estão os benefícios que o Scrum traz para organizações, equipes, produtos e indivíduos:
- Melhor Qualidade: Há um framework para alcançar visão ou objetivos. O Scrum fornece feedback contínuo e visibilidade para garantir que a qualidade seja tão alta quanto possível. O Scrum ajuda a garantir a qualidade por meio de práticas como:
- Tempo de Mercado Reduzido: O Scrum provou entregar valor aos usuários finais 30%–40% mais rápido do que os métodos tradicionais.
- Retorno sobre Investimento (ROI) Maior: O tempo de mercado mais curto é uma razão-chave pela qual projetos com Scrum alcançam um ROI maior. A acumulação precoce de receita e benefícios significa retornos totais maiores. Isso se baseia no princípio fundamental dos cálculos de Valor Presente Líquido (VPL).
- Maior Moral da Equipe: Trabalhar com pessoas felizes e engajadas é satisfatório e produtivo. A autogestão coloca decisões normalmente tomadas por gestores ou organizações nas mãos dosEquipe Scrum membros.
- Colaboração Mais Forte da Equipe: Quando as equipes Scrum assumem o projeto e o produto, podem alcançar excelentes resultados. As equipes Scrum colaboram e melhoram a qualidade e o desempenho do projeto por meio de engajamento e comunicação aprimorados.
Framework Scrum
O Scrum é simples. Não é um conjunto de mandatos rígidos e interconectados. O Scrum não é uma metodologia. O Scrum incorpora o método científico do empirismo. Ele substitui abordagens algorítmicas procedurais por métodos heurísticos, respeitando pessoas e a auto-organização para lidar com a imprevisibilidade e resolver problemas complexos. O diagrama abaixo mostra o Scrum em ação, conforme descrito por Ken Schwaber e Jeff Sutherland em seu livro “Scrum: A Arte de Fazer o Dobro do Trabalho em Metade do Tempo”, ilustrando a jornada do planejamento à entrega de software.
Componentes do Processo Scrum
O próprio framework Scrum é simples. Ele define apenas algumas diretrizes gerais, com um pequeno número de regras, papéis, artefatos, e eventos. No entanto, cada um desses componentes é crucial para propósitos específicos e essencial para usar com sucesso o framework.
Os principais componentes do Framework Scrum são:
- Papéis Scrum: Scrum Master, Proprietário do Produto, e a Equipe Scrum
- Artefatos: Backlog de Sprint, Backlog do Produto, Gráfico de Burn Down, logs, etc.
- Eventos Scrum: Planejamento do Sprint, Revisão do Sprint, Reunião Diária do Scrum, Retrospectiva do Sprint, etc.
- Sprints
O diagrama abaixo mostra os principais elementos do framework Scrum. O processo foi visualizado usando o Canvas do Processo Scrum da ferramenta Agile Visual Paradigm.
Papéis do Scrum
Quando uma organização adota o Scrum, a primeira coisa a entender é como os papéis do Scrum diferem dos papéis tradicionais de gestão de projetos. Embora existam apenas três papéis principais no Scrum, eles não se alinham automaticamente com títulos de cargo familiares. Vamos começar com definições breves de cada um:
Proprietário do Produto
O Proprietário do Produto é o papel do Scrum responsável por representar a comunidade de negócios ou usuários. Eles trabalham de perto com os usuários para definir funcionalidades na lista de backlog do produto. As principais responsabilidades incluem:
- Definir a visão e a estratégia do produto, incluindo metas de curto e longo prazo;
- Fornecer ou coletar conhecimento sobre o produto ou serviço;
- Compreender e comunicar as necessidades dos clientes à equipe de desenvolvimento;
- Coletar, priorizar e gerenciar os requisitos do produto ou serviço;
- Assumir a responsabilidade pelo orçamento do produto ou serviço, incluindo lucratividade;
- Definir datas de lançamento do produto ou serviço;
- Responder perguntas e tomar decisões diariamente com a equipe de desenvolvimento;
- Aceitar ou rejeitar o trabalho concluído do Sprint;
- Apresentar os principais entregáveis da equipe ao final de cada Sprint;
- Gerenciar o Backlog do Produto.
Mestre do Scrum
O Mestre do Scrum é o facilitador da equipe de desenvolvimento Ágil. O Scrum permite que as equipes se organizem de forma autônoma e se adaptem rapidamente com base nos princípios Ágeis. O Mestre do Scrum gerencia o fluxo de informações. Principais responsabilidades:
- Atuar como coach para ajudar a equipe a seguir os valores e práticas do Scrum;
- Auxiliar na remoção de impedimentos e proteger a equipe de distrações externas;
- Facilitar uma boa colaboração entre a equipe e os interessados;
- Promover senso comum e transparência dentro da equipe;
- Proteger a equipe de interrupções organizacionais.
Equipe Scrum
A Equipe Scrum (também conhecida como Equipe de Desenvolvimento) é composta por 3 a 9 membros que devem possuir coletivamente todas as habilidades técnicas necessárias para entregar o produto ou serviço. Ela é orientada diretamente pelo Scrum Master, mas não gerenciada no sentido tradicional. Ela deve ser auto-organizada, multifuncional e responsável por concluir todas as tarefas necessárias.
A equipe de desenvolvimento é responsável por entregar um incremento de produto potencialmente entregável ao final de cada Sprint — abrangendo análise, design, desenvolvimento, testes e redação técnica. Características importantes de uma Equipe Scrum incluem:
- Auto-organizada: Todos os membros da equipe gerenciam seu próprio trabalho para concluir as tarefas atribuídas. No Scrum Ágil, não há líder de equipe ou gerente direto. Todos devem se comprometer o suficiente para impulsionar suas próprias atividades e contribuir para o sucesso da equipe. Se alguém falhar, todos falham.
- Multifuncional: Todos os membros da equipe devem possuir todos os conhecimentos e habilidades necessários para entregar um produto de alta qualidade, passível de entrega. Especialistas podem ser trazidos para orientação, mas apenas para transferir conhecimento à equipe, a fim de fechar lacunas de habilidades.
- O Product Owner Requer uma Visão de Negócios: O Product Owner representa a voz do cliente e deve traduzir suas necessidades em itens acionáveis para o Scrum Master e a equipe de desenvolvimento. Trata-se normalmente de um cargo de tempo integral.
- O Scrum Master Não é um Gerente de Linha: Eles ajudam a orientar a equipe de desenvolvimento e eliminam obstáculos que impedem o progresso.
Artifatos do Scrum
Os artifatos do Scrum ajudam a definir o trabalho que entra na equipe e o que está sendo desenvolvido atualmente. Embora existam mais artifatos — como histórias de usuário, listas de lançamento, gráficos de burn-down — aqui nos concentramos nos três principais:
Backlog do Produto
O Backlog do Produto é uma lista priorizada de histórias de usuário que representam os recursos que a equipe de produto precisa ou espera. Normalmente, o Product Owner mantém essa lista.
Backlog do Sprint
O Backlog do Sprint contém um conjunto de itens selecionados para serem concluídos durante o Sprint atual. Dois pontos-chave a observar sobre a relação entre o Backlog do Sprint e o Backlog do Produto:
1. A equipe decide o que adicionar ao Sprint. Portanto, a equipe possui e é responsável por entregar esses itens.
2. Antes de mover um item do Backlog do Produto para o Backlog do Sprint, a equipe deve garantir que possui todas as informações necessárias. A equipe normalmente define uma lista de verificação de critérios que devem ser atendidos antes que um item possa ser adicionado.
Backlog do Produto vs Backlog do Sprint
O Backlog do Sprint é a lista de tarefas que a equipe Scrum se compromete a concluir durante o Sprint. Durante a reunião de Planejamento do Sprint, a equipe normalmente seleciona algumas Itens do Backlog do Produto na forma de histórias de usuário e determina as tarefas necessárias para concluir cada uma, conforme mostrado abaixo:
Gráfico de Burn-down
Um Gráfico de Burn-down é uma representação gráfica do trabalho restante ao longo do tempo. O trabalho restante (ou trabalho do backlog) é mostrado no eixo vertical, com o tempo no eixo horizontal. É um gráfico contínuo do trabalho que resta para ser feito. Pode ser usado para prever quando todo o trabalho será concluído. É comumente usado em métodos de desenvolvimento de software ágil, como o Scrum, mas pode ser aplicado a qualquer projeto com progresso mensurável ao longo do tempo. O trabalho restante pode ser medido em tempo ou em pontos de história.
Eventos do Scrum
A comunicação é essencial! O Scrum depende da transparência em todos os aspectos (Pilar do Scrum #1). Dado este princípio fundamental, o framework é construído em torno de uma série de eventos-chave para garantir os outros dois pilares—Inspeção e Adaptação—como mostrado na tabela abaixo:
| Evento | Inspeção | Adaptação |
|---|---|---|
| Planejamento do Sprint |
|
|
| Daily Scrum |
|
|
| Revisão do Sprint |
|
|
| Retrospectiva do Sprint |
|
|
Observação: Durante cada Sprint, existem cinco reuniões-chave no Scrum, conforme mostrado abaixo:
Planejamento do Sprint
Cada Sprint começa com o planejamento. A equipe deve determinar e se comprometer com o que irá entregar como parte do Sprint. Itens possíveis são sempre retirados do Backlog do Sprint, como mostrado abaixo:
É aqui que o Scrum Master pode brilhar. O Product Owner define o que é necessário do ponto de vista de negócios/cliente, a equipe Scrum determina o que acredita que pode entregar, e o Scrum Master garante o melhor ajuste para ambos os lados.
Reunião Diária do Scrum
Assim que a equipe se compromete com o que irá entregar como parte do Sprint, realiza-se uma Reunião Diária de Stand-up. O objetivo principal é garantir que cada membro da equipe (e possíveis observadores) entenda plenamente o status e o progresso do trabalho:
- O que eu fiz ontem?
- O que farei hoje?
- O que está me impedindo?
Esta atualização diária fornece feedback imediato à equipe. As reuniões são breves — não mais que 3 minutos por pessoa.
Observação: Os observadores estão lá para observar. O Scrum Master deve minimizar distrações externas e internas.
Reunião de Revisão do Sprint
A Revisão do Sprint ou a Demonstração é realizada no final do Sprint para inspecionar o Incremento. A equipe demonstra o Incremento com base na Definição de Concluído, focando na Meta do Sprint. O Product Owner analisa e aceita o Incremento entregue.
Retrospectiva do Sprint
A Retrospectiva do Sprint é tipicamente a última atividade do Sprint. Muitas equipes realizam-na imediatamente após a Revisão do Sprint. Toda a equipe — incluindo o Scrum Master e o Product Owner — deve participar. Uma retrospectiva de uma hora geralmente é suficiente. Esta reunião permite que a equipe reflita sobre:
- O que deveríamos começar a fazer?
- O que deveríamos parar de fazer?
- O que deveríamos continuar fazendo?
O objetivo é melhorar continuamente a eficiência da equipe.
Refinamento do Backlog
Pense no Backlog do Produto como o mapa estrada do projeto. À medida que a equipe colabora, cria e atualiza uma lista de todos os itens necessários para concluir o projeto, garantindo que todos os requisitos necessários sejam atendidos.
Sprints
No framework Scrum, todas as atividades necessárias para implementar um item do Backlog do Produto Scrum são realizadas dentro de um Sprint (também chamado de “Iterações”). Sprints são sempre curtos — tipicamente de 2 a 4 semanas. Cada Sprint segue um processo definido, como mostrado abaixo:
Como observado, os itens no Backlog do Produto são priorizados e selecionados para o Backlog do Sprint. Um Sprint contém apenas alguns itens principais — qualquer subestimação do trabalho para um único item pode impactar significativamente o Sprint. Como itens maiores são frequentemente mais difíceis de estimar e entender, o risco de falha do Sprint aumenta. Equipes Scrum experientes gastam tempo e esforço para dividir itens complexos ou grandes (por exemplo, funcionalidades do usuário ou Epics) em histórias de usuário menores (ou ainda mais em tarefas ou sub-tarefas).
Epic
Um Epic captura um grande volume de trabalho. É essencialmente uma “história de usuário grande” que pode ser dividida em muitas histórias menores. Concluir um Epic pode levar várias Sprints. Portanto, ao usar Epics no desenvolvimento, eles devem ser decompostos em histórias de usuário menores.
Epics são introduzidos cedo no ciclo de vida do projeto. São pontos funcionais de alto nível, quase voltados para marketing.
Chamamos histórias grandes de “Epics” para transmitir sua escala. Pense como um filme. Se eu lhe disser que um filme é de “ação e aventura”, você tem uma ideia do que esperar — possivelmente perseguições de carros, tiroteios, etc. Da mesma forma, rotular uma história como “Epic” pode, às vezes, transmitir contexto adicional.
História de Usuário
Uma História de Usuário é uma declaração breve de um requisito do produto ou caso de negócio. É geralmente escrita em linguagem simples para ajudar os leitores a entenderem o que o software deveria fazer. O Product Owner cria a história. Em seguida, os membros da equipe Scrum dividem a história em uma ou mais tarefas Scrum.
Histórias de usuário são geralmente funcionalidades visíveis para o usuário final. Elas seguem o formato: “Quero [fazer algo] para que eu possa alcançar um objetivo.” Elas entregam valor ao cliente/usuário. Este é o requisito do produto do cliente.
Exemplo: “Como cliente, quero criar uma conta para que eu possa visualizar minhas compras do ano passado e ajudar-me a planejar meu orçamento no próximo ano.”
Tarefa
Em contraste, uma Tarefa é mais técnica. As tarefas frequentemente envolvem código, design, criação de dados de teste, automação, etc. São geralmente responsabilidades individuais. As tarefas não são escritas no formato de história de usuário. São mais técnicas.
Exemplo: “Avaliar o ângulo da interface usando Material Design” ou “Enviar o aplicativo à App Store.”
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish