Scrum

• Metodologia ágil de desenvolvimento de software
• Inspirado em ideias de Takeuchi e Nonaka, 1986
• Ken Schwaber, Jeff Sutherland, anos 1990
• Também aplicada a outros domínios (ex.: eduScrum)

história, motivação

Guia oficial

http://www.scrumguides.org/scrum-guide.html

relato de experiência

resumo

Pilares

Transparência

Inspeção

Adaptação

Valores

Comprometimento

Coragem

Foco

Abertura

Respeito

Papéis

• Product Owner (PO)
• Scrum Master (SM)
• Development Team

= Scrum Team

Product Owner

Comunicação

Visão do negócio

Priorização

Development Team

3-9 pessoas

Mesmo espaço

Multifuncional

Auto-organizável

Scrum Master

Remove impedimentos

Preza pelo uso do Scrum

Workflow

• Atividades / eventos / rituais / cerimônias
• Produtos / artefatos

As atividades têm duração fixa (timebox)

Sprint (= 1-4 semanas)

Sprint Planning

Desenvolvimento

Sprint review

Sprint retrospective

Sprint Backlog

Daily Scrum

Daily Scrum

..............

Demo,

Incremento

Acertos e melhorias

(Refinamento do backlog)

Product Backlog

• Lista priorizada de itens (PBI) que devem compor o produto, sem detalhamento
• Principal responsável: Product Owner
• Formato: em aberto (geralmente, estórias do usuário)
• Priorização: risco, valor, dependências, prazo, esforço
  • Priorizar menor esforço ou maior risco?
• Itens no topo (mais prioritários) são mais detalhados

Refinamento do Backlog

• Itens são detalhados, estimados e repriorizados
• Pode acontecer a qualquer momento

Sprint Planning

• 4 horas para sprints de 2 semanas
• O que vai ser entregue na sprint?
  • Esclarecimentos sobre cada item. Definição de pronto (critério de aceitação).
  • Escolha de itens do topo do product backlog que vão fazer parte do sprint backlog, de acordo com a estimativa de esforço
• Como o trabalho será feito?
  • Cada item é detalhado em tarefas

Esforço

• Cada item do backlog deve ter uma estimativa de esforço feita pela equipe
• Esforço é uma medida relativa
• O tempo depende do esforço e da velocidade da equipe
• Uma forma de estimar o esforço é usando o Planning Poker

Desenvolvimento

• Cada desenvolvedor escolhe uma tarefa e faz
• Cada tarefa não deve demorar mais de um dia

Monitorando o progresso

Comum: burndown chart

Daily Scrum

• Reunião diária, Scrum Master + Development Team
• Mesmo horário e local
• Máximo 15 minutos
  • Comum: stand-up meeting
• Todos falam:
  • O que eu fiz ontem pela sprint?
  • O que farei hoje pela sprint?
  • O que impede completar a sprint?
• Discussões mais detalhadas para remover impedimentos podem ser feitas após a reunião diária

Sprint review

• Scrum Team + stakeholders
• PO explica que itens estão prontos e quais não estão
• Equipe demonstra o produto
  • Apenas itens prontos podem ser demonstrados!
• Todos discutem o que deve ser feito a seguir

Sprint retrospective

• Scrum Team
• Momento de auto-avaliação
• Duas perguntas:
  • O que deu certo?
  • O que pode melhorar?
• Equipe discute que melhorias podem ser implementadas na próxima sprint

Discussão

E os detalhes?

• Como o software deve ser testado?
• Como o software deve ser implantado?
• Que boas práticas de desenvolvimento devem ser adotadas?
• Scrum descreve o processo em um nível mais gerencial, sem entrar em detalhes operacionais

Scrum-But

• Desvios comuns na aplicação do Scrum
• "Eu uso Scrum, mas..."
• ... só faço reuniões diárias uma vez por semana
• ... um gerente diz em que tarefas os membros da equipe devem trabalhar
• ... algumas pessoas se vangloriam de seu trabalho
• ... demonstro coisas que não estão prontas
• ... não tenho tempo de melhorar o processo porque tenho muitas funcionalidades pra implementar
• ... a retrospectiva foca nas pessoas, não nos problemas

Limitações do Scrum

• Supõe time trabalhando no mesmo local
• Supõe que membros têm conhecimento geral
• Supõe que não há fortes dependências com outras equipes
• Supõe que produtos podem ser testados dentro da duração de uma sprint