Scrum: Guia Completo do Framework Ágil para Projetos

O que é Scrum?

Scrum surge da necessidade de aumentar o índice ou taxa de sucesso em projetos.

Scrum vs. Métodos Tradicionais

Enquanto métodos tradicionais focam no triângulo de escopo, custo e prazo, Scrum se destaca ao integrar a qualidade, visando gerar projetos ágeis e de alta qualidade.

A concentração exclusiva em escopo e requisitos pré-estabelecidos nem sempre resulta em valor.

Agilidade significa entregar resultados e valor de forma contínua.

Características da Agilidade

• Método ágil para gerenciamento de projetos
• Pequenos times auto-organizados
• Flexibilidade - um "Framework"
• Visibilidade e Adaptação

Manifesto Ágil

Criado em 2001, o Manifesto Ágil visa melhorar o desenvolvimento de software, priorizando:

• Indivíduos e interações mais do que processos e ferramentas
• Software funcionando mais do que documentação abrangente
• Colaboração com o cliente mais do que negociação de contratos
• Responder a mudanças mais do que seguir um plano

Resultados do Desenvolvimento Ágil

O desenvolvimento ágil foca em entregar resultados significativos e mensuráveis.

Melhorias Reportadas (Acima de 10%)

• Aumento de produtividade: 89% dos participantes
• Redução de defeitos: 84% dos participantes
• Menor Time-to-market: 82% dos participantes
• Custo reduzido: 66% dos participantes

Scrum: Um Caminho Ágil

Scrum é um caminho ágil, inserido no conjunto de métodos ágeis para gestão de projetos.

É considerado um framework, e não um método, devido à sua flexibilidade.

Princípios do Scrum

• Scrum enxerga o desenvolvimento como uma caixa preta controlada.
• É um processo iterativo e incremental para desenvolvimento ou manutenção.
• Planeja releases considerando:
  • Requisitos do cliente
  • Urgência
  • Competição
  • Visão do Sistema
  • Recursos Disponíveis

Fases do Scrum (Metáfora)

• Pré-jogo: Planejamento, arquitetura e estabelecimento das definições do trabalho por projeto.
• Jogo: Desenvolvimento do produto.
• Pós-jogo: Fechamento do projeto.

História do Scrum

• Inspiração: Takeuchi e Nonaka.
• Começou em 1990.
• Primeira implementação: 1993 - Sutherland, Scumniotales e McKenna.
• Apresentado na OOPSLA '95 por Jeff Sutherland e Ken Schwaber, com o artigo "The Scrum Development Process".

Aplicações do Scrum

Embora tenha nascido na TI, Scrum é hoje utilizado em diversas outras áreas:

• Gestão de mudanças: IBM
• Call Center: Total Attorneys
• Gestão de Conferências: Trifork
• Consultoria e Finanças: OpenView Venture
• Marketing: GPE

Quando o Scrum é Recomendado?

Scrum pode e é usado em projetos que não são de desenvolvimento de software, sendo particularmente recomendado quando:

• Mudanças são constantes.
• A equipe aprende ao longo do projeto.
• Complexidade e incerteza reduzem a visibilidade.
• A colaboração é importante.

Papéis no Scrum

Existem 3 papéis principais no Scrum:

• Product Owner (PO)

  O Product Owner (PO), ou Proprietário do Produto, é o representante do cliente, responsável pela preparação e visão do produto.

  • Garante o ROI (Retorno sobre o Investimento).
  • Conhece os requisitos e necessidades.
  • Responsável pela macro-gerência (resultados de Sprints, releases, andamento do produto, etc.).
  • Age como mediador quando o produto deve atender a vários clientes.
  • Pode dispor de uma equipe de apoio.

• Scrum Master (SM)

  O Scrum Master (SM) é o facilitador do trabalho, garantindo que as coisas aconteçam e que o Scrum seja seguido.

  • Evita interferências externas no trabalho do time.
  • Remove os obstáculos para permitir o trabalho eficaz e eficiente do time.
  • Ajuda o PO com o Product Backlog.
  • Garante a adesão ao Scrum.

• Responsabilidades do Scrum Master

  • Remover a barreira entre desenvolvimento e cliente.
  • Ensinar o cliente a maximizar o ROI e atingir seus objetivos usando o Scrum.
  • Melhorar o dia a dia do time, facilitando a criatividade e o fortalecimento.
  • Combater a ilusão de comando e controle.
  • Perceber os impedimentos e combatê-los.
  • Facilitar reuniões.
  • Auxiliar o PO com o Product Backlog.
  • Determinar onde o Scrum está, comparado a onde poderia estar.

• Membro da Equipe Scrum

  • Responsável por desenvolver o produto.
  • Equipes auto-organizadas e multidisciplinares.
  • Promove a colaboração como a principal ferramenta de trabalho.

Product Backlog

O Product Backlog é a lista das necessidades do cliente, contendo as histórias que uma equipe Scrum precisa desenvolver, ordenada por prioridade de implementação.

• Necessidades do cliente.
• Conjunto das histórias que darão origem ao produto.
• Ordenado por prioridade de implementação.
• Responsabilidade do PO.
• Evolui com o produto e a dinâmica do ambiente.

Características de um Item do Product Backlog (INVEST)

• Independente
• Negociável (Flexível)
• Valioso (Agrega valor para o usuário)
• Estimável
• Suficientemente pequeno (Realizável em uma Sprint)
• Testável

Metáfora do Iceberg do Backlog

• Histórias mais detalhadas e prontas no topo.
• Épicos (histórias maiores e menos detalhadas) na base.
• Muitas histórias "submersas" (menos detalhadas).

História de Usuário (User Story)

Uma História de Usuário é a descrição do que é necessário desenvolver, gerando valor para o cliente (um requisito), similar a um caso de uso.

• Descreve funcionalidades que devem gerar valor para o cliente.
• Representa necessidades do cliente.
• Funciona como um requisito.
• O PO indica o valor agregado.
• Épicos são histórias ainda brutas, de alto nível.

Estrutura de uma História de Usuário

Uma história possui 3 componentes principais:

• Ator
• Objetivo
• Justificativa

1. Ator

A visão é sempre a do ator:

• Quem precisa dessa história?
• Qual papel ele desempenha?
• É uma pessoa ou um sistema?
• Exemplo: "Como gerente do hotel, eu quero..."

2. Objetivo

• O que o usuário quer fazer?
• Qual o problema a ser resolvido?
• Como deve ser o comportamento do sistema nessa história?
• Qual o resultado final da história?
• Exemplo: "...saber quais clientes estão hospedados há mais de 30 dias para, caso deseje, cobrar as estadias vencidas..."

3. Justificativa

• Por que a história é necessária?
• Provê uma visão abrangente do problema.
• Facilita o entendimento.
• Explicita elementos que podem ser usados na solução.
• Fornece mais informação sobre a história.
• Opcional, mas desejável.
• Exemplo: "...reduzindo o risco de inadimplência."

Características de uma Boa História de Usuário (INVEST)

• Independente
• Negociável (Flexível)
• Valioso (Agrega valor para o usuário)
• Estimável
• Suficientemente pequeno (Realizável em uma Sprint)
• Testável

Construção do Product Backlog

Com todos esses processos, o Product Backlog é gerado e possui as seguintes características:

• Conjunto das histórias que darão origem ao produto.
• Ordenado por prioridade de implementação.
• Responsabilidade do PO.
• Histórias precisam ser mais detalhadas/completas quando no topo.
• Épicos (histórias maiores) ficam na parte inferior.
• Evolui com o produto e a dinâmica do ambiente.
• Temas agrupam histórias relacionadas.
• Muitas histórias são "submersas" (exemplo do iceberg).

Planning Poker

O Planning Poker é uma técnica utilizada para estimar histórias de usuário.

• A equipe trabalha na estimação com a ajuda do SM.
• Utilizam-se cartas com pontuação baseada na série de Fibonacci.
• Para cada história, a equipe, após discutir o problema, joga a carta que acredita representar o esforço necessário para desenvolvê-la.
• Caso não haja concordância, discute-se mais e joga-se novamente.
• A estimativa deve ser encontrada por unanimidade (todos os membros devem concordar).

Velocidade (Velocity)

A velocidade indica o quanto o time consegue fazer em uma Sprint.

• Normalmente medida em pontos.
• Na primeira Sprint é uma estimativa inicial; ao longo do desenvolvimento, estabiliza.
• Usada para o planejamento de Sprints.
• Pode ser usada para o planejamento de Releases (entregas).

Releases (Entregas)

Um Release é uma versão do produto pronta para ser utilizada.

• Normalmente compreende várias Sprints.
• Demanda um planejamento específico.
• O planejamento deve também ser baseado na velocidade.

Eventos (Rotinas e Reuniões) do Scrum

Os principais eventos do Scrum incluem:

• Reunião de Planejamento da Sprint (Parte 1)
• Reunião de Planejamento da Sprint (Parte 2)
• Reunião Diária (Daily Scrum)
• Reunião de Revisão da Sprint (Sprint Review)
• Reunião de Retrospectiva da Sprint (Sprint Retrospective)

Reunião de Planejamento da Sprint (Parte 1)

Foco: O que será feito na próxima iteração de desenvolvimento?

• Proposição de uma Meta da Sprint pelo PO.
• A Meta da Sprint é a descrição do que se deseja ao final da Sprint em termos de valor (ex: funcionalidades do produto).
• Explicação das histórias prioritárias do Product Backlog para a equipe, pelo PO.
• Utilização do Planning Poker para estimativa.
• Para uma Sprint de 30 dias, a reunião dura aproximadamente 4 horas.
• A equipe decide o quanto acredita que conseguirá fazer na Sprint.
• Definição final da Meta da Sprint.

Participantes da Reunião de Planejamento I

• PO, Scrum Master, Equipe de Desenvolvimento, gerência (se necessário) e especialistas da área de negócio (se necessário).

Reunião de Planejamento da Sprint (Parte 2)

Foco: Como realizar as histórias selecionadas?

• A equipe planeja o trabalho.
• As histórias selecionadas no Product Backlog são detalhadas em tarefas.
• As tarefas identificadas constituem o Sprint Backlog.
• Tarefas podem receber estimativa de horas.
• O PO pode participar para tirar dúvidas.
• Outros convidados podem estar presentes para esclarecer o domínio ou ajudar na parte técnica.
• Ao final, as tarefas devem estar bem definidas e entendidas.

Sprints

A Sprint é a iteração executada para o desenvolvimento do produto, objeto do projeto.

• Iterações para a implementação das histórias/tarefas.
• Normalmente duram de 15 a 30 dias.
• Em casos de maior risco, a Sprint pode ser menor.
• Membros da equipe pegam tarefas e as realizam.
• O Scrum Master facilita o trabalho da Equipe.
• Pode ser necessário tirar dúvidas com o PO ou com outros especialistas.
• Evitar MUDANÇAS durante a Sprint é crucial.

Sprint Backlog

O Sprint Backlog é o conjunto das histórias do Product Backlog selecionadas para serem contempladas em uma Sprint.

• A seleção é feita pela ordenação do Product Backlog e de acordo com a velocidade do time.
• As histórias devem ser trabalhadas por prioridade.
• Não deve, mas pode receber novas histórias ao longo da Sprint (com cautela).

Tarefas

• Atividades a serem realizadas para a implementação de uma história.
• Boa prática: Uma tarefa deve ser executável em um dia.

Impedimento

• Um impedimento é algum fator externo que está bloqueando a continuação de uma tarefa.
• O SM é responsável por remover os impedimentos.

Sprint Burndown

O Sprint Burndown é um gráfico para acompanhamento do trabalho da equipe.

• Eixo horizontal: dias da Sprint.
• Eixo vertical: horas (tarefas) ou pontos (histórias).
• Novas tarefas ajustam o gráfico.

Reunião Diária (Daily Scrum)

É onde a equipe colabora para fazer as tarefas diariamente.

• Cada membro responde a três perguntas: O que fiz ontem? O que farei hoje? Há algum impedimento?
• Não é uma reunião para discussões técnicas detalhadas.
• Serve para que todos saibam o que está acontecendo e se coordenem.
• O PO participa apenas como ouvinte.

Reunião de Retrospectiva da Sprint

É a última reunião da Sprint, um debriefing para melhoria contínua.

• O PO e outros são convidados apenas se necessário.
• A equipe se reúne para discutir o que ocorreu na Sprint.
• Pontos positivos e negativos devem ser levantados e registrados.
• Os diversos pontos devem ser discutidos e soluções propostas.
• Revisão sobre os conceitos de "Pronto" (Definition of Done), "Preparado" (Definition of Ready), ferramentas, comunicação, testes, etc.
• Promover a melhoria contínua do trabalho.

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

• O Time de Desenvolvimento apresenta o resultado da Sprint para o PO, para sua aprovação.
• O PO aprova as histórias que considera satisfeitas.
• A definição de "Pronto" (Definition of Done) é muito importante.
• O PO informa se a Meta da Sprint foi ou não atingida.
• É um momento de prestação de contas e transparência.
• Gera subsídios para a próxima reunião de planejamento.
• Para uma Sprint de 30 dias, a reunião dura aproximadamente 4 horas.