Falando sobre

Scrum
Alexandre Magno Figueiredo

Quem sou eu?

Consultor, instrutor e autor:
Alexandre Magno vive em So Paulo -SP, onde trabalha como consultor em
liderana e gerenciamento de projetos de software atravs do uso de
metodologias e processos geis, principalmente FDD e Scrum. Atua na rea de
software h mais de 15 anos, j tendo participado de projetos de variadas
dimenses de lead time, escopo e investimento. Foi o primeiro Certified Scrum
Practitioner da Amrica Latina, possuindo ainda certificaes dos fornecedores
IBM e Borland, e dos grupos OMG e PMI. Magno fundador do grupo ScrumBrasil.

Introduo s abordagens geis

O Manifesto gil

Em 2001, um grupo de profissionais

veteranos na rea de software decidiu
se reunir em uma estao de esqui, nos
EUA, para discutir formas de melhorar o
desempenho de seus projetos. Embora
cada envolvido tivesse suas prprias
prticas e teorias sobre como fazer um
projeto de software ter sucesso, cada
qual com as suas particularidades,
todos concordavam que, em suas
experincias prvias, um pequeno
conjunto de princpios sempre parecia
ter sido respeitado quando os projetos
davam certo;

O grupo era composto de grandes

nomes do mundo do software, tais
como: Kent Beck, Jim Highsmith,
Alistair Cockburn, Martin Fowler, Ken
Shwaber e Jeff Sutherland;

Introduo s abordagens geis

O que agilidade?

Um estado mental, no um conjunto de documentos, passos ou tcnicas;

mais atitude do que um processo, mais ambiente que uma metodologia;

Desenvolvimento iterativo;

Entregar produto com valor para o negcio, mais rpido e continuamente;

Garantir progresso real;

Abraar mudanas;

Melhorar a comunicao entre negcios e TI;

Qualidade desde o incio;

Introduo s abordagens geis

O Manifesto gil

O manifesto diz:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o
ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos
a valorizar:
Indivduos e interao entre eles mais que processos e ferramentas
Produto em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens
esquerda."
http://agilemanifesto.org

Introduo s abordagens geis

Desenvolvimento iterativo

Uma iterao um pacote de tempo que possui um

custo fixo e um conjunto de funcionalidades que pode
variar;

As funcionalidades que faro parte de uma iterao so

priorizadas pelo cliente;

Iteraes podem perder funcionalidades, mas nunca

datas;

Cliente entende que prioridades no final da lista podem

ficar de fora e/ou eles podem adicionar funcionalidades;

Flexibilidade est nas funcionalidades, no no prazo ou no

custo;

Introduo s abordagens geis

Desenvolvimento iterativo

Produto

novo release a cada x meses

nova iterao a cada x semanas

7

Introduo s abordagens geis

Desenvolvimento iterativo

Produto

Introduo s abordagens geis

As abordagens geis

Hoje, as abordagens geis mais difundidas e praticadas com sucesso so:

Scrum: uma abordagem gil para o gerenciamento de projetos. Fornece

prticas que ajudam gerentes a tornar mais dinmico e gerencivel o ambiente
de desenvolvimento de software.

XP (eXtreme Programming): uma abordagem gil para a engenharia de

projetos de software. Como o prprio nome diz, extremamente focada no
desenvolvimento, e tem como principal caracterstica a programao em par.
FDD (Feature-Driven Development): uma abordagem gil para a engenharia
de projetos de software. Defende o desenvolvimento de um modelo abrangente
no incio do projeto pelo qual as funcionalidades do sistema sero descobertas e
desenvolvidas.
9

Introduo s abordagens geis

A mitologia gil

Escuto freqentemente contos sobre a falta da

disciplina em Agile: Agile deixa minhas equipes
de engenharia fazer o que quiserem e a
qualidade do produto cair. Ou sobre a falta da
visibilidade: Eu no tenho nenhuma visibilidade
do que est acontecendo e eu no consigo
prever o que eu comearei, ou quando. E sobre
a falta de aplicabilidade: Agile apenas para
geeks ou Agile apenas para equipes
pequenas.

E principalmente: Agile fcil!

Fonte: Hubert Smiths, 2006 Introduction to Agile Methods and Practices

10

Introduo s abordagens geis

Posicionamento de Agile no mercado

Pesquisa sobre adoo de Agile divulgada em dezembro de 2006 pela Trail Ridge
Consulting

Equipes seguindo algum processo gil

(em todo tamanho de organizao)

Principal processo gil em uso

(em todo tamanho de organizao)

Tempo (em anos) que algum processo gil vem

sendo utilizado na organizao

Principal processo gil em uso

(por tamanho de organizao)

11

Introduo s abordagens geis

Sucesso com Scrum

O Yahoo! usa Scrum h mais de

18 meses e possui uma mdia de
500 colaboradores usando Scrum
nos Estados Unidos, Europa e
ndia. Scrum vem sendo usado
com sucesso em projetos como o
Yahoo! Podcasts e outros
Pete Deemer
Chief Product Officer, CSM
Yahoo! Bangalore - 25/07/2006

12

O que Scrum?
A origem do Scrum
Scrum foi criado no incio da dcada de 1990 por Jeff Sutherland, PhD e Ken
Schwaber,
nos Estados Unidos.

oe
v
i
t
a
r
o I te
t
n
e
olvim ental
v
n
e
m
Des
Incre

SCRUM
13

O que Scrum?
Algumas definies

Scrum um processo iterativo e incremental para o desenvolvimento de qualquer

produto e gerenciamento de qualquer trabalho.

Scrum um processo gil para o gerenciamento e controle de projetos;

Scrum um wrapper para prticas de engenharia existentes;

Scrum uma abordagem para desenvolvimento de sistemas e produtos onde os

requisitos sofrem constantes mudanas;

Scrum uma forma de otimizar a comunicao do time e favorecer a cooperao;

Scrum escalvel para pequenos projetos e grandes corporaes;

14

O que Scrum?
Aspectos do Scrum

Substitui o gerenciamento emprico e processos de controle, por feedback em loops de

inspeo e adaptao.

Distribui funcionalidades em Sprints de 30 dias.

Escalvel para projetos longos, largos e distribudos (Scrum of Scrums, Type C Scrum,
MetaScrum).

Suporta CMMI Nvel 3 e ISO9001.

Extremamente simples, mas resistente!

15

O que Scrum?
Liderana-Colaborao sim! Comando-Controle NO!

Comando - Controle
Liderana - Colaborao
Comando-Controle muito lento porque:

No permite processar informaes rapidamente;

No permite tomar decises rapidamente;

16

O ciclo de vida do Scrum

17

Os papis no Scrum
O Product Owner (PO)

O Product Owner representa o cliente ou patrocinador do

projeto, e faz parte do time que entregar o produto.
Suas responsabilidades so:

Definir a viso do produto (product vision);

Gerenciar o retorno de investimento (ROI);

Apresentar ao time os requisitos necessrios para a entrega

do produto;

Priorizar cada requisito de acordo com seu valor para o

negcio/cliente;

Gerenciar a entrada de novos requisitos e suas priorizaes;

Planejar entregas (releases);

Atuar como facilitador quando mais de um cliente estiver

envolvido no projeto;

Garantir que Especialistas de Domnio estejam disponveis

para o time;

18

Os papis no Scrum
O Scrum Master (SM)

O papel do Scrum Master, diferentemente dos gerentes de

projeto na maioria das prticas e metodologias, difere do
tradicional comando e controle. Em Scrum, um Scrum
Master trabalha com e, principalmente, para o time.
Suas responsabilidades so:

Permitir que o time seja auto-gerencivel;

Garantir que os caminhos para a comunicao do time

estejam abertos permanentemente;

Garantir e auxiliar o time a seguir corretamente as prticas

do Scrum;

Remover qualquer impedimento que o time encontre;

Proteger o time de interferncias externas para garantir que

sua produtividade no seja afetada;

Facilitar as reunies dirias.

19

Os papis no Scrum
Os membros do time

Um membro do time algum que esteja comprometido a

fazer o trabalho necessrio para atingir a meta de uma
sprint. Em Scrum no temos arquitetos, testers ou
programadores, temos sim, membros com perfis de
arquiteto, de tester ou de programador...mas que podem
atuar em papis secundrios para garantir o alcance da
meta.
Suas responsabilidades so:

Definir a meta da sprint;

Estar comprometido com o trabalho e com a alta qualidade;

Trabalhar seguindo a viso do produto e meta da sprint;

Colaborar com outros membros do time e ajudar a torn-lo

auto-gerenciado;

Estimar os itens do backlog e garantir o esforo necessrio

para que as estimativas sejam realistas;

Participar das reunies dirias;

Manifestar impedimentos;
20

Os papis no Scrum
Fluxo simples

Coloca
itens
(priorizados)

Pega itens

Coloca
Time

Product Owner

Product Backlog

O que sobrar...devolve.

Sprint Backlog

serve
21
Scrum Master

O conceito de Sprint
Caractersticas

A Sprint um time-box 30 dias no qual o time do projeto ir produzir uma parte do

produto definida pelo cliente;

O conceito de Sprint nos remete necessidade de estarmos frequentemente entregando

algo de valor para o cliente. Diferentemente dos modelos tradicionais, onde voc
desenvolve o produto em um longo perodo de tempo e, apenas no final com o produto
pronto - o entrega ao cliente, em Scrum voc sempre entregar parte do produto em
pequenos intervalos de tempo, sendo que esta parte a prioridade do cliente, ou seja,
o que ele realmente est precisando naquele momento;

Uma Sprint deve ser empreendida por um time multi-funcional com no mais que
nove membros;

Cada Sprint deve ter uma meta especfica que represente o desejo do cliente para
aquele time-box especfico;

Os membros do time da Sprint so os responsveis por estimar os itens que compem o

desejo do cliente e dar a palavra final do que ser possvel ser desenvolvido naquele
time-box;

22

O conceito de Sprint
Composio

Uma Sprint composta das seguintes etapas:

Planejamento (Sprint Planning Meeting)

Execuo (The Sprint)

Reviso (Sprint Review)

Retrospectiva (Sprint Retrospective)

23

Product Backlog
Exemplo (e apenas exemplo!)

24

Product Backlog
Um outro exemplo (e apenas um outro exemplo!)

25

Sprint Planning Meeting

Regras

A Sprint Planning Meeting ou Reunio de Planejamento, dividida em duas partes, e

entra em cena no incio de cada Sprint.

Alm de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser

convidados a participar em determinados momentos da reunio, desde que agreguem
valor mesma e tenham seu convite aprovado pelo Product Owner.

Pela prtica, percebemos que a durao desta reunio segue a seguinte tabela:

26

Sprint Planning Meeting

Sprint Planning Meeting #1

Na primeira parte, o Product Owner e o time, sendo facilitados pelo Scrum Master,
realizam uma reviso no Product Backlog, discutindo sobre o propsito e metas de cada
item e dando a oportunidade para que o Product Owner exponha seus desejos. O time
seleciona os itens que acredita que possam ser desenvolvidos na prxima Sprint e define
a meta.

O Product Backlog deve ter sido preparado pelo Product Owner antes da reunio de
planejamento. O Scrum Master deve auxili-lo nesta tarefa.

Meta do Sprint:
Refatorar banco de dados e
implementar relatrios de
vendas necessrios para as
tomadas de decises nos finais
de quarter.
27

Sprint Planning Meeting

Sprint Planning Meeting #2

A segunda parte da reunio de planejamento deve ocorrer imediatamente aps a

finalizao da primeira;

O Product Owner deve estar disponvel para, caso necessrio, detalhar algum item ou
remover dvidas quanto ao objetivo do mesmo;

O time deve elaborar a estratgia de desenvolvimento que ser utilizada para que a
meta da Sprint seja atingida. Ao final desta reunio eles devem saber responder como
construiro as funcionalidades do produto durante o Sprint;

Essas estratgias so geradas a partir do detalhamento dos itens do Product Backlog.

As tarefas geradas atravs desse detalhamento chamada de Sprint Backlog;

Os membros do time devem escolher suas tarefas e ento estim-las em horas;

Tarefas devem ter de 1 a 16 horas de durao. Tarefas maiores devero ser quebradas
em duas ou mais.

28

Scrum Daily Meeting

Se reunir todo dia? Impossvel!
Uma vez que a Sprint tenha sido iniciada, emerge ento
uma das principais prticas do Scrum: as reunies dirias
(Scrum Daily Meetings);

Uma Scrum Daily Meeting uma reunio diria, com

durao exata de 15 minutos, que devem sempre ser
realizada no mesmo local e horrio e sempre com a
participao do Scrum Master (facilitador) e dos membros
do time;

Cada membro deve relatar ao time sobre os progressos

e obstculos que vem encontrando em seu caminho. Em
suma, trs perguntas devem ser respondidas por cada
um deles:
1. O que fiz (quanto andei) desde a ltima reunio
diria?
2. O que pretendo fazer (quanto andarei) at a
prxima reunio diria?
3. Estou encontrando impedimentos? Quais?

29

Scrum Daily Meeting

O quadro de acompanhamento
Item

Refactoring do
banco de dados

Tarefas
desejadas
Aplicar script
de refatorao

Tarefas
em andamento

Montar Script
de refatorao

02

08

13
Estimativa em Tamanho

Tarefas para
inspeo

Definir
estratgia
02

Tarefas
finalizadas
Mapear as
tabelas que
sero
refatoradas 06

Horas

24

Avaliar eficincia
da refatorao
06

Estimativa em Tempo

Relatrio de
vendas por
unidade e
21 perodo

30

Scrum Daily Meeting

O quadro de acompanhamento

31

Scrum Daily Meeting

Sprint Backlog

32

Scrum Daily Meeting

Sprint Burndown
Aps a reunio diria, os membros do time atualizam o montante de tempo que falta
para completar cada tarefa do Sprint Backlog. Esta informao gravada em um
grfico denominado Sprint Burndown. Este grfico mostra, dia aps dia, a quantidade
de horas que faltam ser completadas para o atingimento da meta da Sprint;

Atravs do Sprint Burndown a equipe consegue rapidamente identificar problemas no

ritmo do time e tomar as providncias necessrias;

33

Sprint Review
E o resultado foi...

Aps a finalizao de uma Sprint, hora de realizar a

Sprint Review;

Aqui deveremos avaliar: O que estou entregando? O que

eu deveria estar entregando?

Nesta atividade a equipe ir realizar uma apresentao

do produto que foi gerado (incrementado) durante a
Sprint, focando nas tarefas do Sprint Backlog;

Participam da Sprint Review o Product Owner, o Scrum

Master, os membros do time, clientes, stakeholders,
executivos, e qualquer pessoa que esteja interessada no
resultado da Sprint;

Esta apresentao dura normalmente entre 30 minutos

e 1 hora e deve ser realizao no formato de demo, ou
seja, Power points so completamente dispensveis;

Qualquer participante da Sprint Review deve ser

encorajado a realizar perguntas e fornecer sugestes.

34

Sprint Retrospective
Aprendendo com os acertos...mas principalmente com os erros
A Sprint Retrospective uma das ferramentas mais
importantes para que voc obtenha sucesso com Scrum;

Esta a oportunidade que o time tem para discutir

sobre o que funcionou e o que no funcionou durante a
Sprint;

Product Owner, Scrum Master e os membros do time

devem participar da retrospectiva. Uma boa estratgia
convidar algum neutro para facilitar a sesso;

A estrutura da Sprint Restrospective bem simples.

Divida um quadro branco ou poster em duas reas com
os seguintes ttulos: O que funcionou bem? e O que
pode ser melhorado?. Aps isso, cada membro deve
colocar post-its em cada uma das reas indicando os
itens que, em sua opinio, merecem estar ali;

Ento, o time me visualiza os itens citados, discute

sobre e planeja aes a serem tomadas para a prxima
Sprint;

35

Scrum e...

FDD
36

Prximos eventos...

37

Prximos treinamentos...

Scrum @

Treinamento

Gerenciamento de Projetos de Software com Scrum

www.caelum.com
38

ltimas dvidas...
39

Obrigado!
Alexandre Magno, CSP
amagno.blogspot.com
axmagno@gmail.com

40