O paradigma / a quebra do

MDS: há 40 anos

•FREQ. UTIL. FUNCIONALIDADES

• 45% de funcionalidades ñ
usadas
• 19% raramente utilizadas
• 16% as vezes utilizadas
• 13% frequentemente
• 7% sempre
 É m u i t o difícil conhecer
todos os requisitos no
início do projeto;
 Como o cliente tem que
pedir t ud o no início, ele
acaba pedindo até coisas a
mais, para evitar as
mudanças.
 Mudanças durante o projeto
tem alto custo;
 Depois de m u i t o tempo o
usuário tem acesso ao
software.
Pensemos…

Será que este modelo é

ideal para desenvolver
sistemas?

As vantagens são boas

para o cliente?
 Que tal fazer diferente?
} Demonstrar o
} Precisamos } As mudanças
produto (sistema)
conversar mais e devem fazer parte do
constantemente, não
escrever apenas o processo, não lute
no final depois de tudo
necessário; contra elas.
pronto;
Vamos falar
de
agilidade?
 No esporte rugby existe uma formação
conhecida por Scrum, onde 8 jogadores de
cada ti me se encaixam formando uma
O que é Scrum muralha.
Na formação é m u i t o importante o
comprometimento de cada membro, pois
qualquer erro pode comprometer a jogada.
As origens do
Scrum
•O termo Scrum surgiu do arti go “The
New New Product Development Game” (O
novo jogo do desenvolvimento de novos
produtos) publicado por Ikujiro Nonaka
e Hirotaka Takeuchi na Harvard Business
Review de 1986.

A dupla percebeu que melhores resultados

eram alcançados quando equipes pequenas e
multidisciplinares trabalhavam em projetos.
•
Estas equipes altamente produtivas, foi
associada a conhecida formação do esporte
Rugby.
O aprimoramento

Com o desejo de aprimorar o desenvolvimento de

sistemas de sua equipe, Jeff Sutherland, então
vice presidente de engenharia da Easel Inc,
implementou o Scrum em 1993 (com o apoio de
John Scumniotales e Jeff McKenna) no estilo
proposto por Nonaka e Takeuchi.

Quase que paralelamente, Ken Schwaber estava

engajado em pesquisas para melhorar o
desenvolvimento de sistemas de sua empresa, a
ADM (Advanced Development Methods).

Em 1995, Ken e Jeff apresentaram a Scrum

methodology (Metodologia Scrum).
O Manifesto
Ágil
 No Scrum cada pessoa deve estar comprometida
Comprometimento
com os objetivos do time e com a meta do Sprint.
No Scrum o time mantém o foco constante na
Foco
meta da Sprint e nos objetivos do time.
Um Time de Scrum trabalha com coragem para
Coragem fazer a coisa certa e encarar os problemas difíceis,
dentro dos limites do framework.
Os membros do Time do Scrum respeitam uns aos
Respeito
outros como pessoas capazes e independentes.
O Time do Scrum e Stakeholders concordam em
Abertura estarem abertos a respeito do trabalho a ser feito
e dos desafios com a sua execução.

Valores que sustentam os três pilares do Scrum

Transparência

•Isto significa apresentar os fatos como estão,

simples assim!
•Todas as pessoas envolvidas, como SM, PO, Dev
Team, clientes e stakeholders são transparentes
em suas relações diárias uns com os outros.
Todos confiam uns nos outros, e têm a coragem
de dar as boas notícias, assim como as más
notícias. Todos se esforçam e colaboram
coletivamente para o objetivo comum, e
ninguém deve ter nenhuma agenda oculta.
Inspeção
•A inspeção neste contexto não é uma inspeção
por um inspetor ou um auditor, mas sim uma
inspeção por todos na Equipe Scrum.

•A inspeção pode ser feita para o produto,

processos, aspectos de pessoas, práticas e
melhorias contínuas.
•Por exemplo, a equipe mostra abertamente e de
forma transparente o produto no final de cada
Sprint para o cliente, para coletar feedback. Se o
cliente alterar os requisitos durante a inspeção, a
equipe não se queixa, mas sim se adapta, usando
isso como uma oportunidade para colaborar com o
cliente, para esclarecer os requisitos e testar a nova
hipótese.
Inspeção
•A inspeção é um princípio tão forte que o Scrum considera que o
processo de testes está dentro da própria sprint. Isso nos remete aos
conceitos de integração contínua, test driven development e pair
programming, que são formas de garantir a qualidade enquanto o
produto está sendo produzido, ao invés de controlar a qualidade só no
final.

•A inspeção se dá, por exemplo, através dos seguintes itens:

• No conceito de ready (definition of ready)
• No conceito de done (definition of done)
• Na reunião de refinamento
• Quando se estima os story points de uma história de usuário
• Reunião de revisão (review meeting) com o cliente (product owner)
• Diariamente, quando alguém termina um história e um membro
do grupo faz a verificação do DoD
• Na verificação de bugs e sua respectiva correção
Adaptação
•Adaptação neste contexto é sobre a melhoria
contínua, a capacidade de adaptação com base
nos resultados da inspeção.

•Todos na equipe devem fazer esta pergunta

regularmente: estamos melhores do que ontem?

•Se o Time Scrum determinar, a partir da

inspeção, que um ou mais aspectos do processo
estão fora dos limites aceitáveis e que o produto
resultante será inaceitável, ele deverá ajustar o
processo ou o material sendo processado. Esse
ajuste deve ser feito o mais rápido possível para
minimizar desvios posteriores.
 Os três
•Daily Scrum: reunião utilizada para inspecionar
o progresso em direção à Meta da Sprint e para
realizar adaptações que otimizem o valor do

pontos da
próximo dia de trabalho.

•Reuniões de Revisão da Sprint e de

inspeção e
Planejamento da Sprint: utilizadas para
inspecionar o progresso em direção à Meta da
Release e para fazer as adaptações que

adaptação
otimizem o valor da próxima Sprint.

•Retrospectiva da Sprint: utilizada para revisar a

do Scrum Sprint passada e definir que adaptações

tornarão a próxima Sprint mais produtiva,
recompensadora e gratificante.
Vamos começar?
•O Scrum é um framework baseado em
princípios ágeis, que lida com
desenvolvimento de software simples,
complicado e complexo.
•O Scrum é baseado na melhoria contínua do
produto e processo.
•
O Scrum fornece software frequentemente
(valor) e mostra os problemas ocultos no
desenvolvimento do sistema.
•
No projeto scrum, o avanço ocorre em uma
série de iterações chamadas Sprints. Cada
tamanho de sprint é normalmente de duas a
quatro semanas de duração.
•É baseado em inspeção e ciclo
adaptativo. Produzir produtos de forma
incremental e iterativa reduz o risco e
aumenta a visibilidade.
•
Scrum tem papéis, atividades e artefatos
simples
Os Papéis
As responsabilidades

•PO
• Representante do cliente;
• Deve conhecer o negócio;
• Deve conhecer com clareza as necessidades
do usuário e stakeholders;
• Determina o que será incluído no produto e
a prioridade para o desenvolvimento do
produto de acordo com o valor de mercado;
• Tem a última palavra sobre as
funcionalidades do sistema;
• Definir características do produto;
• Decidir a data de lançamento e o conteúdo;
• Ser responsável pela rentabilidade do
produto; e
• Aceitar ou rejeitar itens de trabalho.
As responsabilidades

•Scrum Master
• Guardião e Treinador d o processo Scrum;
• Promulgar valores Scrum;
• Garantir a produtividade da equipe;
• Construir uma equipe vencedora;
• Aplicar princípios ágeis e tornar o sistema efetivo;
• Um grande fa c i l i ta d o r entre o ti m e de
desenvolvimento e o d o n o d o p r o d u t o
re movendo barreiras;
• Evita interferências externas;
• Remove os i m p e d i m e nt o s ;
• Atua co m o u m m e n t o r para ensinar o
D o no d o Produto a p r i o r i z a r itens d o
produto; e
• Não é o chefe d o ti m e de desenvolvimento.
As responsabilidades

•Dev Team
• 2 – 9 membros da equipe
(desenvolvedor, testador)
• Deve possuir habilidades para
desenvolver o sistema;
• São coleti vamente
responsáveis pelos
resultados;
• São a u to - o rga n i za d o s ;
• São m u l ti f u n c i o n a i s ;
• Todos são
desenvolvedores
• Construir o produto
vencedor
• Trabalhar de forma
colaborativa e compartilhar
responsabilidades
• Equipe funcional cruzada.
 Kan = visual
Ban = cartão ou quadro

É  utilizado para gerenciar e monitorar as  atividades de

maneira visual, prática e  rápida;
É  muito bom para gerenciar o andamento do  trabalho;
É  possível ver todo o fluxo de trabalho.
 Modelo Tradicional
O gerente de projetos foca nos
“recursos” e na gestão do projeto.
Requisitos estão escritos na
“pedra”.
Requisitos são ordenados pela
dependência entre eles.
O status do projeto é medido
(geralmente) pelo % de conclusão
ou marcos do projeto.
O cliente espera muito tempo para
ver o sistema em funcionamento.
Scrum
Não tem um gestor de projetos, as
equipes são auto-organizadas.
Requisitos podem mudar.
Requisitos são priorizados pelo
valor que trás ao negócio.
O status é medido em termos de
funcionalidades liberadas.
O cliente tem rápidas liberações do
sistema.
Organizações Scrum.

www.scrum.org

www.scrumalliance.com
Scrum Master

Scrum Product Owner

Scrum Developer
 Professional Scrum Professional Scrum
Master I Master II
Valor $ 100.00 $ 500.00
Tempo 60 minutos 120 minutos
Questões 80 25
Pontuação mínima 85% 85%
Tipo de questão Múltipla escolha Múltipla escolha;
Estudo de caso;
Dissertativas.
Idioma Inglês Inglês
Pré-requisito Nenhum Certificação PSM I

Dados de 01/02/2013
 Adotar Scrum não
significa que todos
seus problemas serão
resolvidos, mas os
problemas durante o
processo de
desenvolvimento de
sistemas serão mais
facilmente
identificados.