Scrum

MATA62 - Engenharia de Software I

Universidade Federal da Bahia

Prof. Rodrigo Rocha

2016.1

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

Scrum

By Rodrigo Rocha Gomes e Souza