Aula 7 – Processo de

Software Scrum
Prof. Rafhael Cunha
rafhael.cunha@iffarroupilha.edu.br
Roteiro
• Scrum

Análise e Modelagem de Sistemas 2

Aula Anterior
• Desenvolvimento Ágil de Software
• Características Fundamentais
• Métodos Ágeis
• Manifesto para Desenvolvimento Ágil de Software
• Princípios dos Métodos Ágeis

Análise e Modelagem de Sistemas 3

Perdendo no revezamento...
• O estilo de “corrida de revezamento” aplicado ao
desenvolvimento de produtos pode conflitar com
os objetivos de velocidade e flexibilidade máximas.
Ao invés disto, um estilo holístico, onde a equipe
busca, como em um jogo de futebol, de forma
integrada, chegar ao gol, com passes de bola, pode
servir melhor às atuais necessidades competitivas.

• Adequado de “The New New Product Development Game”, Hirotaka

Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986

Análise e Modelagem de Sistemas 4

Quem Usa o Scrum?
• Microsoft • Nielsen Media
• Yahoo • First American Real Estate
• Google • BMC Software
• Electronic Arts • Ipswitch
• High Moon Studios
• John Deere
• Lockheed Martin
• Lexis Nexis
• Philips
• Siemens
• Sabre
• Nokia • Salesforce.com
• Capital One • Time Warner
• BBC • Turner Broadcasting
• Intuit • Oce
Análise e Modelagem de Sistemas 5
Scrum tem sido usado para
• Software comercial
• Desenvolvimento interno
• Desenvolvimento contratado
(terceirização)
• Projetos de preço fixo
• Aplicações Financeiras
• Aplicações certificadas pela
ISO 9001
• Sistemas embarcados
• Sistemas disponíveis 24x7
• Desenvolvimento por hackers
solitários
Análise e Modelagem de Sistemas
• Video games
• Sistemas para suporte à vida
• Sistemas para controle de
satélites
• Websites
• Software para handhelds
• Telefones celulares
• Aplicações para redes
• Aplicações de ISV (Independent
Software Vendors)
• Algumas das maiores
aplicações em produção
6
Scrum
• Scrum é um framework ágil de gestão de projetos
usado para entregar aos clientes, de forma
iterativa, incrementos de produto de alto valor

Análise e Modelagem de Sistemas 7

Scrum
• Scrum depende de times hábeis e auto organizados
para entregar os incrementos do produto

• Também depende de um cliente, ou Dono do

Produto (Product Owner), que indique um time
com uma lista de funcionalidades desejadas, e que
use o valor de negócio como mecanismo de
priorização

Análise e Modelagem de Sistemas 8

 Desenvolvimento Sequencial X
Paralelo
Requerimentos Projeto Código Teste

Ao invés de completar
uma coisa por vez...
... equipes Scrum fazem
um pouco de cada
coisa, todo o tempo.

Análise e Modelagem de Sistemas 9

Scrum
• No Scrum, os projetos acontecem em uma série de
iterações, com até um mês de duração, chamadas
Sprints.

• Scrum é ideal para projetos cujos requisitos mudam

rapidamente ou são altamente emergentes.

• O trabalho a ser feito em um projeto Scrum é

registrado nas Pendências do Produto (Product
Backlog), que é uma lista de todos os desejos de
mudança no produto.
Análise e Modelagem de Sistemas 10
Scrum
• No inicio de cada incremento é feita uma Reunião
de Planejamento de Incremento (Sprint Planning
Meeting) na qual o Dono do Produto (Product
Owner) prioriza as Pendências do Produto
(Product Backlog), e a Equipe Scrum (Scrum Team)
seleciona as tarefas que ela pode completar
durante o próximo incremento.

• Essas tarefas são então movidas das Pendências do

Produto para as Pendências do Incremento.

Análise e Modelagem de Sistemas 11

Scrum
• Durante um incremento, são conduzidas curtas
reuniões diárias chamadas de Scrum Diário (Daily
Scrum), que ajudam a equipe a manter-se no rumo.

• Ao final de cada incremento a equipe demonstra a

funcionalidade concluída, na Reunião de Revisão
do Incremento (Sprint Review Meeting).

Análise e Modelagem de Sistemas 12

Visão Geral do Scrum

Análise e Modelagem de Sistemas 13

Papéis Scrum
•Dono do produto Framewor
•ScrumMaster k
•Equipe Cerimônia
•Planejamento
•Revisão
•Retrospectiva
•Reunião diária
Artefatos
•Product backlog
•Sprint backlog
•Burndown charts
Análise e Modelagem de Sistemas 14
Papéis Scrum
•Dono do produto Framewor
•Scrum Master k
•Equipe Cerimônia
•Planejamento
•Revisão
•Retrospectiva
•Reunião diária
Artefatos
•Product backlog
•Sprint backlog
•Burndown charts
Análise e Modelagem de Sistemas 15
Dono do Produto
(Product Owner)
• Define as funcionalidades do produto
• Decide datas de lançamento e conteúdo
• Responsável pela rentabilidade (ROI)
• Prioriza funcionalidades de acordo com o valor de
mercado
• Ajusta funcionalidades e prioridades
• Aceita ou rejeita o resultado dos trabalhos

Análise e Modelagem de Sistemas 16

ScrumMaster
• Representa a gerência para o projeto
• Responsável pela aplicação dos valores e práticas
do Scrum
• Remove obstáculos
• Garante a plena funcionalidade e produtividade da
equipe
• Garante a colaboração entre os diversos papéis e
funções
• Escudo para interferências externas
Análise e Modelagem de Sistemas 17
Time Scrum
(Scrum Team)
• O Scrum Team constrói o produto que o cliente irá
utilizar
• O time no Scrum é multifuncional - ele contém
todas as especialidades necessárias para entregar o
produto potencialmente utilizável a cada Sprint
• É auto organizável, com um alto grau de autonomia
e responsabilidade.
• Scrum Teams desenvolvem um profundo espírito de
camaradagem e o sentimento de que "estamos
juntos nisso".
Análise e Modelagem de Sistemas 18
Papéis Scrum
•Dono do produto Framework
•ScrumMaster
•Equipe Cerimônia
•Planejamento
•Revisão
•Retrospectiva
•Reunião diária
Artefatos
•Product backlog
•Sprint backlog
•Burndown charts
Análise e Modelagem de Sistemas 19
Planejamento do Sprint
• A equipe seleciona itens do Product Backlog com os
quais compromete-se a concluir
• O Sprint Backlog é criado
• Tarefas identificadas e estimadas (1 a 16 horas)
• De forma colaborativa, não apenas feito pelo
ScrumMaster
• Planejamento de alto nível é considerado

Análise e Modelagem de Sistemas 20

Scrum Diário
(Daily Scrum)
• Parâmetros
• Diário
• 15 minutos
• Todos em pé!
• Não é para a solução de problemas
• Todo mundo é convidado
• Apenas os membros da equipe, ScrumMaster, dono do
produto podem falar
• Ajuda a evitar reuniões adicionais desnecessárias

Análise e Modelagem de Sistemas 21

Três questões, para todos
• As respostas não são um “relatório” para o
ScrumMaster

• Elas são compromissos perante os pares

Análise e Modelagem de Sistemas 22

Revisão do Sprint
• Equipe apresenta os resultados obtidos durante o
Sprint
• Tipicamente, demonstração de novas
funcionalidades ou sua arquitetura
• Informal
• 2 horas de preparação
• Sem slides
• Todo o time participa
• O mundo é convidado

Análise e Modelagem de Sistemas 23

Retrospectiva do Sprint
• Periodicamente, observe o que funciona e o que
não funciona
• Tipicamente de 15 a 30 minutos
• Feita após cada Sprint
• Toda a equipe participa
• ScrumMaster
• Dono do produto
• Membros da equipe
• Clientes e outros

Análise e Modelagem de Sistemas 24

Inicia, Pára, Continua
• A equipe discute o que gostaria de:

Iniciar a fazer

Parar de fazer
Esta é uma das
várias maneiras Continuar
de se conduzir
uma fazendo
retrospectiva do
Sprint
Análise e Modelagem de Sistemas 25
Papéis Scrum
•Dono do produto Framework
•ScrumMaster
•Equipe Cerimônia
•Planejamento
•Revisão
•Retrospectiva
•Reunião diária
Artefatos
•Product backlog
•Sprint backlog
•Burndown charts
Análise e Modelagem de Sistemas 26
Product Backlog
• Os requerimentos
• Uma lista de todo o trabalho
desejado no projeto
• Idealmente, na forma em que
cada item tenha seu peso de
acordo com a vontade do
cliente ou usuários
• Priorizado pelo dono do
Este é o Product produto
Backlog • Repriorizado no início de
cada Sprint
Análise e Modelagem de Sistemas 27
 Exemplo de Product Backlog
Item do Backlog Estimativa
Permitir que o usuário faça uma reserva 3

Permitir que o usuário cancele a reserva 5

Permitir a troca de datas da reserva 3

Permitir que empregadod do hotel gerem 8

relatórios de lucratividade
Melhorar manipulação de erros 8

... 30

... Análise e Modelagem de Sistemas 50 28

Gerenciando o Sprint Backlog
• Cada indivíduo escolhe o trabalho que fará
• Trabalhos nunca são atribuídos
• Atualização diária da estimativa do trabalho restante
• Qualquer membro da equipe pode adicionar, apagar
ou mudar tarefas
• O trabalho aparece a partir do Sprint
• Se uma tarefa não é clara, defina-a como um item com
uma quantidade maior de tempo e subdivida-a depois
• Atualize as coisas a serem feitas na medida em que se
tornam mais conhecidas
Análise e Modelagem de Sistemas 29
 Sprint Backlog
Tarefas Seg Ter Qua Qui Sex
Codificar interface de
8 4 8
usuário
Codificar regra de negócio 16 12 10 4

Testar 8 16 16 11 8

Escrever help online 12

Escrever a classe foo 8 8 8 8 8

Adicionar log de erros 8 4

Análise e Modelagem de Sistemas 30

Burndown Chart

Análise e Modelagem de Sistemas 31

Quadro de Tarefas (KanBan)
• O Quadro de Tarefas mostra todo o trabalho que o
time está desenvolvendo durante o Sprint.
• Ele é atualizado continuamente no decorrer do
Sprint - se alguém pensa em alguma nova tarefa,
eles a escrevem em um novo cartão e colocam-no
no quadro.
• Antes ou durante um Daily Scrum, as estimativas
são alteradas (para mais ou menos) e os cartões
são movidos no quadro.

Análise e Modelagem de Sistemas 32

Análise e Modelagem de Sistemas 33
Escalabilidade
• Equipe de 7 ± 2 pessoas
• Escalabilidade através de equipes de equipes
• Fatores de escala
• Tipo de aplicação
• Tamanho da equipe
• Dispersão da equipe
• Duração do projeto
• Scrum é usado em projetos envolvendo mais de
500 pessoas

Análise e Modelagem de Sistemas 34

Resumo da Aula
• Scrum

Análise e Modelagem de Sistemas 35

Alguns Links
• http://www.desenvolvimentoagil.com.br/scrum/

• http://epf.eclipse.org/wikis/scrumpt/

• https://
www.youtube.com/results?search_query=scrum

Análise e Modelagem de Sistemas 36

Referências
• SOMMERVILLE, Ian. Engenharia de software. 9ª edição.
São Paulo: Pearson Prentice Hall, 2011.
• PRESSMAN, Roger S. Engenharia de software. McGraw
Hill Brasil, 2011.
• GUEDES, G. UML 2 – Uma abordagem prática. 2ª ed.
São Paulo: Novatec, 2011.
• Apresentação Distribuível de Introdução do Scrum. http
://
www.mountaingoatsoftware.com/uploads/presentation
s/Portuguese-Redistributable-Intro-Scrum.ppt
• Notas de Aula profº Thiago Krug – Disciplina de Análise
e Modelagem de Sistemas.
Análise e Modelagem de Sistemas 37