Scrum
A verdade sobre projetos

O Standish Group vem, há mais de uma década,
realizando estudos em volta dos resultados dos projetos
de software ao redor do mundo. O resultado destes
estudos é um relatório batizado de Chaos Report;
Chaos Report
Segundo o Standish Group o Chaos Report
revela que:



Em média, os atrasos representaram 63%
mais tempo do que o estimado;
Os projetos que não cumpriram o orçamento
custaram em média 45% mais;
No geral, apenas 67% das funcionalidades
prometidas foram efetivamente entregues;
Chaos Report
Quais os principais fatores para um número ainda tão
alto de projetos que não alcançam seu objetivo?
A vasta maioria dos projetos de software falha por:
 Falta de clareza – sobre funções pessoais,
responsabilidades e requisitos;
 E também por inabilidade para acompanhar o que
ocorre em cada um dos diferentes passos do ciclo de
vida da aplicação;
Telefone sem fio?
Uso de funcionalidades
Resumindo





A comunicação entre as partes envolvidas nos
projetos é muito fraca;
A visibilidade do andamento real e dos problemas
existentes nos projetos é muito fraca;
Clientes pedem sempre mais do que realmente
precisam;
Os projetos são caros e, ainda em sua maioria, não
alcançam sucesso;
Os conflitos existentes entre TI e negócios durante os
projetos são muitos;
Origem do Scrum
Origem do Scrum
Um grupo composto de grandes nomes do
mundo do software, tais como: Kent Beck, Jim
Highsmith, Alistair Cockburn, Martin Fowler, Ken
Shwaber e Jeff Sutherland.
Criaram o Manifesto Ágil.
http://agilemanifesto.org/
Manifesto Ágil
“Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:
Indivíduos e interações
MAIS QUE
processos e ferramentas
Produto funcionando
MAIS QUE
documentação abrangente
Responder a mudanças
MAIS QUE
seguir um plano
Colaboração com o cliente
MAIS QUE
negociação de contratos
Ou seja, mesmo havendo valor nos itens à direita, valorizamos
mais os itens à esquerda.”
http://agilemanifesto.org
O que não é Scrum…
SCRUMbut



É uma anomalia.
É fazer o Scrum de uma forma errada. Mal feito, mal
implementado.
Quando o Scrum mostra os erros e as empresas
removem ou alteram o framework ao invés de tentar
corrigir os erros.
O que é Scrum?

Processo empírico de gerenciamento e controle;

Inspeção e adaptação em loops de feedback;

Usado para gerenciar projetos desde 1990;

Entrega freqüente de funcionalidades com valor para o
cliente;

Escalável a projetos distribuídos, grandes e largos;

Compatível com CMMI Nível 3 e ISO9001;

Extremamente simples, mas resistente;
Processo Empírico
O que é Scrum?

É um processo iterativo e incremental para o
desenvolvimento de qualquer produto e
gerenciamento de qualquer projeto;

É mais um framework que uma metodologia,
mais atitute que um processo;

Não diz em mínimos detalhes como fazer, mas
fornece boas práticas para serem seguidas com o
objetivo de maximizar o sucesso nos projetos;
Incremental e Iterativo
Princípios











Satisfação do cliente
Mudança
Entregas constantes
Colaboração
Motivação
Ambiente adequado
Comunicação face a face
Software funcionando
Ritmo sustentável
Simplicidade
Melhoria contínua
Porcos e Galinhas
Baseados nesta historinha, costumamos dizer que
existem dois tipos de pessoas em projetos Scrum:
 Galinhas: Apenas envolvidas com o projeto;
 Porcos: Totalmente comprometidos com o projeto;
Papéis no Scrum
Product Owner (MACRO Gerenciamento)
•
Responsável por garantir o ROI (Retorno de Investimento);
Responsável por conhecer as necessidades do(s) cliente(s);
Proxy em ambientes com mais de um cliente;
•
Scrum Master (Gerenciamento do PROCESSO)
Responsável por remover os impedimentos do time;
Responsável por garantir o uso de Scrum;
Protege o time de interferências externas;
• Time (MICRO Gerenciamento)
Multi-disciplinar;
Auto-gerenciado;
Produzir produto com qualidade e valor para o cliente;
Time Scrum
Scrum
Master
Product
Owner
Time
Time
Time
Time
Time
Fluxo do Scrum
Visão
É o que representa a necessidade do cliente, é o que
deve ser satisfeito ao fim de um determinado projeto.
Sendo que:
 O Product Owner é o responsável pela criação da
visão;
 Para definir essa visão o Product Owner colhe
informações junto a clientes, usuários finais, membros
do time, gerentes, stakeholders, executivos, etc;
 Ele compartilha essa visão com o Time;
 Ele refina essa visão com o Time;
Product Backlog
É a lista de necessidades que precisam ser produzidas para que a Visão
do produto seja atingida. O Product Backlog deve seguir as seguintes
regras:







Deve ser apresentado no formato de uma lista com itens priorizados e
ordenados de acordo com o valor que representam para o cliente e
negócio.
Apenas um Product Backlog deve existir por projeto.
O Product Backlog irá existir por todo o ciclo de vida do projeto (e não
da sprint);
O Product Owner é o responsável pelo conteúdo do Product Backlog,
sua disponibilidade e sua priorização;
O Product Backlog deve ser atualizado pelo Product Owner para refletir
as mudanças e necessidades do cliente, mudanças estratégicas ou
tecnológicas, novas idéias, enfim... mudanças;
Enquanto existir um produto, o Product Backlog também existe;
O Scrum Master deve auxiliar o PO na elaboração do Product Backlog;
Sprint Planning Meeting
É a reunião realizada para planejar a próxima Sprint,
esta reunião deve ter duração de aproximadamente
5% do tamanho total da Sprint e deve ser dividida em
duas partes.
Sprint Planning 1
Sprint Planning 1







O Product Owner apresenta os itens de maior prioridade do
Product Backlog ao time;
Product Owner e Time trabalham em conjunto para descobrir
qual funcionalidade deverá ser desenvolvida durante o próximo
Sprint;
A decisão referente à quantidade de itens que o Time seleciona
cabe somente ao Time, somente o Time pode saber o que ele é
capaz de realizar no próximo Sprint;
O Product Owner tira dúvidas sobre os itens selecionados;
O Product Owner em conjunto com o Time definem a Meta da
Sprint;
A Meta da Sprint é uma descrição que fornece orientação ao
Time sobre a razão pela qual ele está produzindo o incremento;
O resultado da Sprint Planning 1 é o Selected Backlog;
Sprint Planning 2
Sprint Planning 2





O Time analisa e identifica quais tarefas são necessárias para
transformar os Itens do Backlog selecionados na primeira parte
da reunião em software funcional;
As tarefas devem ser decompostas (quebradas) de forma que
possam ser feitas em menos de um dia (8 horas);
Essa lista de tarefas é chamada de Sprint Backlog;
O Product Owner deve estar presente nessa parte da reunião
para esclarecer dúvidas sobre os itens do Product Backlog e
para ajudar a efetuar mudanças, caso estas sejam necessárias;
Se o Time determinar que há muito ou pouco trabalho, ele pode
renegociar o Selected Backlog com o Product Owner;
Sprint Planning Meeting
Parte I
Ajuste de
prioridades
Identificar a
meta da
Sprint
Parte II
Selecionar
Itens do
Backlog
Quebrar Itens
em tarefas
Determinar
velocidade
Estimar
tarefas
Sprint Backlog
Sprint Backlog é o resultado da Sprint Planning Meeting, ele é
composto por:
 Itens de Backlog selecionados;
 Tarefas definidas para cada Item de Backlog;
 Meta da Sprint;
Sprint
A Sprint é um Time-Box de 2 a 4 semanas no qual o time do projeto
deverá produzir um incremento potencialmente entregável do
produto, com alta qualidade, testado, completo e pronto. Para
isso é necessário seguir as seguintes regras:






Ter uma meta clara e objetiva;
Duração de 2 a 4 semanas;
Nenhuma mudança no Sprint Backlog;
Local e horário definido para a reunião diária;
Disponibilidade de cada membro da equipe;
Data definida para a apresentação da sprint;
Daily Meeting
A Daily Meeting é uma reunião diária de 15 minutos na qual cada
membro deve responder:








O que fiz desde a última reunião?
O que pretendo fazer até a próxima reunião?
Tive (estou tento) algum obstáculo/impedimento?
Todos em pé;
Sincronização do conhecimento;
Atualização dos charts;
Não é para a solução de problemas;
Todo mundo é convidado:
– Apenas Equipe, ScrumMaster e Product Owner podem falar;
Sprint Review
É a reunião realizada ao final da Sprint, e tem como propósito apresentar o
que foi feito para o Product Owner e convidados. Ela deve ter duração
máxima de 2,5% do tamanho total da Sprint, e deve incluir ao menos os
seguintes elementos:
 O Time demonstra o trabalho que foi feito e responde a
questionamentos;
 A demonstração deve ser feita em formato de demo no sistema e nunca
em apresentações (ppt);
 O Product Owner identifica o que foi feito e o que não foi feito, e avalia
se a meta da sprint foi alcançada;
 O Time discute o que correu bem durante a Sprint e quais problemas
foram enfrentados, e também como esses problemas foram resolvidos;
 O Product Owner então discute o Product Backlog da maneira que este
se encontra. Ele faz projeções de datas de conclusão com várias
hipóteses de velocidade;
 O grupo inteiro colabora com o que viu e o que isso significa com
relação ao que fazer em seguida;
Retrospective Meeting
É a reunião realizada após a Sprint Review, e tem como propósito a reflexão e
o aprendizado, ou seja a inspeção e adaptação dentro do Scrum. Ela deve
ter duração máxima de 2,5% do tamanho total da Sprint, e deve seguir as
seguintes regras:
 O Scrum Master deve encorajar o Time a revisar o processo de trabalho,
tendo como base o processo de modelo de trabalho e práticas Scrum, de
forma a torna-lo mais eficaz e agradável para o próximo Sprint;
 A finalidade da Reunião de Retrospectiva é inspecionar como correu a
última Sprint em se tratando de pessoas, relações entre elas, processos e
ferramentas;
 A inspeção deve identificar e priorizar os principais itens que correram bem
e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas
ainda melhores;
 Isso inclui a composição do time, preparativos para reuniões, ferramentas,
definição de pronto (done), métodos de comunicação, e processos para
transformar itens do Product Backlog em alguma coisa “feita”;
 No final da Reunião de Retrospectiva, o Time Scrum deve ter identificado
medidas de melhoria que implementará na próxima Sprint. Essas mudanças
se tornam a adaptação para a inspeção empírica;
Agora vocês explicam
Hotel para Cachorro
Um investidor, com intenção de abrir um
hotel para cachorro precisa montar um
panfleto divulgando seu novo negócio.
Sabendo disso vamos:
- Entrevistar o investidor;
- Levantar os itens necessários;
- Quebrar os itens em tarefas;
- Desenvolver o panfleto;
- Apresentar o produto final;