1.
Agilidade com Scrum e
eXtreme Programming
Luiz Fernando Ramos Costa
Coordenadoria de Serviços e Sistemas de Rede
DTIC – IF-SC – (48) 3877-9051
luiz.costa@ifsc.edu.br
www.fernandocosta.com.br
www.twitter.com/fernandocosta

2.
Facilitador

Scrum

eXtreme Programming
Agenda
Fernando Costa
Formado em Redes de Computadores
Pós-graduando em Eng. de Software
Certificado LPIC-1, NCLA, DCTS
Orientador do SENAC TI
Analista de TI na Reitoria do IFSC

3.
Paradoxo de Cobb
We know why projects fail, we
know how to prevent their failure
– so why do they still fail?
Martin Cobb
Treasury Board of Canada Secretariat
Nós sabemos porque
os projetos falham,
sabemos como
previnir – Porque
eles continuam
falhando?

4.
Reflexão do Caranguejo
 Todos os caranguejos
ficam amarrados a um barbante que fica
solto.
 Não é preciso amarrar pois todos querem fugir
mas cada um que ir para um lado diferente.
 Ficam no mesmo lugar

5.
Valores do Manifesto Ágil
Processos e
ferramentas
Indivíduos e
interações
ao
invés
de
Seguir um plano
Resposta à
mudanças
www.agilemanifesto.org
Documentação
abrangente
Software que
funciona
Negociação de
contrato
Colaboração do
cliente

6.
Princípios do Manifesto Ágil
1 - O principal compromisso é com a satisfação do
cliente, por meio da entrega mais rápida e
contínua de produto com valor
2 - Receba bem as mudanças de requisitos(mesmo
em estágios tardios do projeto). Processos ágeis
devem admitir mudanças que trazem vantagens
competitivas ao cliente
3 - Libere produto frequentemente (de 2 a 4
semanas), dando preferência para uma escala de
tempo curta

7.
Princípios do Manifesto Ágil
4 - Mantenha pessoas ligadas ao negócio
(cliente) e desenvolvedores trabalhandos
juntos a maior parte do tempo do projeto
5 - Construa projetos com indivíduos
motivados, dê a eles o ambiente e suporte
que precisam e confie neles para ter o
trabalho realizado
6 - O método mais eficiente e efetivo para
repassar a informação entre a equipe é pela
comunicação face a face

8.
Princípios do Manifesto Ágil
7 - Produto funcionando é a principal
medida de progresso de um projeto
8 - Processos ágeis promovem o
desenvolvimento sustentado.
Patrocinadores, desenvolvedores e
usuários devem ser capazes de manter
conversação pacífica
indefinidamente
9 - Atenção contínua para excelência
técnica e bom projeto (planejamento)
aprimoram a agilidade

9.
Princípios do Manifesto Ágil
10 - Simplicidade é essencial e deve ser
assumida em todos os aspectos do
projeto
11 - As melhores arquiteturas,
requisitos e projetos emergem de
equipes auto-organizadas
12 - Em intervalos regulares, as
equipes devem refletir sobre como se
tornarem mais efetivas, e então
refinarem e ajustarem seu
comportamento

10.
SCRUM
Ken Schwaber
@kschwaber

11.
Em resumo...
Imagem disponível em:
www.mountangoatsoftware.com/scrum

12.
Cliente (ou Product Owner)
 Quem é o nosso cliente?
 Funcionalidades do produto
 Decide as datas e conteúdo
 Rentabilidade (ROI)
 Ajusta e prioriza
funcionalidades e prioridades
 Aceita o rejeita resultados

13.
Scrum Master
 Remove obstáculos
 Não tem autoridade
 Produtividade da equipe
 Conduz eventos
 Escudo da equipe

14.
Equipe (ou team)
 5 a 9 pessoas
 Multi-funcional
 Auto-organizável
 Sugere funcionalidades do
produto

15.
Product Backlog
 Lista de funcionalidades desejadas no projeto
 Os itens que compõe a lista são chamados de
histórias ou itens de backlog
 Todos podem incluir histórias
 Somente o Product Owner pode priorizá-las
 Product Owner pode priorizar novamente no
início de cada Sprint

16.
Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de
produtos
2 Carrinho de
compras
3 Cadastro do
cliente
4 Boleto
bancário
5 Cartão de
crédito

17.
Planning Poker
 Vamos estimar os itens de Backlog?
Quem?
 Product Owner
 Scrum Master
 Equipe

18.
Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de
produtos
3
2 Carrinho de
compras
5
3 Cadastro do
cliente
2
4 Boleto
bancário
4 BB e CEF
(sem usar
pagseguro)
5 Cartão de
crédito
3 Visa e
MasterCard

19.
Importância
Qual a importância dos itens de
backlog para o Product Owner?

20.
Must
(tem que
ter)
Should
(deveria ter)
Could
(poderia ter)
Want
(interessante)
Catálogo
de
produtos
Boleto
bancário
Vídeo dos
produtos
Cadastro de
clientes
Controle de
estoque
Cartão de
crédito
Fotos dos
produtos
Registro do
pedido e
entrega
Carrinho de
compras
Regras de
promoções

21.
Must
(tem que
ter)
Should
(deveria ter)
Could
(poderia ter)
Want
(interessante)
Catálogo
de
produtos
Boleto
bancário
Vídeo dos
produtos
Cadastro de
clientes
Controle de
estoque
Cartão de
crédito
Fotos dos
produtos
Registro do
pedido e
entrega
Carrinho de
compras
Regras de
promoções

22.
Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de
produtos
1 3
2 Carrinho de
compras
1 5
3 Cadastro do
cliente
1 2
4 Boleto
bancário
2 4 BB e CEF
(sem usar
pagseguro)
5 Cartão de
crédito
3 3 Visa e
MasterCard

23.
Sprint
 Deve ter um objetivo
 Período de 2 a 4 semanas
 Nenhuma mudança no sprint
 Processo baseado em uma série de iterações
 Produto é desenvolvido no sprint

24.
Product Burnup Chart

25.
Planejamento da Sprint
 Cliente, ScrumMaster e Equipe
 Cliente seleciona itens do Product backlog
 O Sprint backlog
 Tarefas identificadas e estimadas (1 a 16 horas)
 De forma colaborativa (por todos)
 Equipe compromete-se a concluir as tarefas

26.
Planejamento da Sprint
ID – 1
Catálogo de produtos
ID – 1.1
Administrador de
produtos
1 hr
ID – 1.3
Front-end da loja
3 hr
ID – 1.2
Busca fonética
1 hr

27.
Scrum diário
 Tempo de 15 minutos
 Todos em pé
 Não é para a solução de problemas
− Todos são convidados
− Apenas a Equipe, ScrumMaster e Product Owner podem
falar
 Sincronização do conhecimento
 Atualização do burnup chart
1. O que fiz desde a última reunião?
2. O que farei até a próxima reunião?
3. Existe algum obstáculo?

28.
Gerenciando o Sprint Backlog
 Cada membro da equipe escolhe a tarefa que
fará
 Trabalhos nunca são atribuídos
 Atualização diária da estimativa do trabalho
restante
 Equipe pode adicionar, apagar ou mudar
tarefas (não itens de backlog)

29.
Scrum board

30.
Revisão da Sprint
 Informal
 Todos participam
 Hora do feedback
 Resultados do Sprint
Comunicação eficaz:
(bala / bombom)

31.
Retrospectiva da Sprint
 Feita após cada Sprint
 Periodicamente observe pontos positivos e
negativos
 Tipicamente de 15 a 30 minutos
 Todos participam

32.
Inicia, Pára, Continua
 A equipe discute o que gostaria de:
Iniciar a fazerIniciar a fazer
Parar de fazerParar de fazer
Continuar fazendoContinuar fazendo
Esta é uma das
várias maneiras
de se conduzir
uma retrospectiva
do Sprint

33.
Agora vocês explicam! :)

34.
eXtreme Programming
Kent Beck
@kentbeck

35.
Você está fazendo assim?
Comunicação

36.
Fazer software é dureza

37.
Boa notícia
Cases de sucesso:

Google

Microsoft

Philips

FAB (BR)

Oi Paggo

38.
Má notícia
• Seus colegas não vão acreditar
• O seu chefe não vai aceitar
• O chefe do seu chefe não pode nem pensar

39.
Não é assim que se faz software
Falhas:
a) Não entregam o acordado
b) Estouram o orçamento
c) Estouram o prazo
d) Todas alternativas

40.
Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos
EUA pela empresa Standish Group

41.
64% de desperdício

Podem gerar algumas horas extras para a equipe

Cliente paga por lixo

42.
Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos
EUA pela empresa Standish Group

43.
20% muito útil

Geram pelo menos 80% do valor do
produto

20%? desconhecido no início do
projeto
“XP é a arte de maximizar a
quantidade de software
que você não vai fazer “

44.
Análise
Pai(cliente): 1 dia de projeto
Mãe(desenv.): 9 meses de projeto

45.
Análise
Cliente: “Não era nada disso que eu
queria...”

46.
Mentalidade

47.
Cascata

48.
Custo da mudança
por
Barry
Bohem

49.
Problemas e mudanças
Patente do
VELCRO:
em 1941 por
Georges de Mestral

50.
Meio digital
 Fluidez
 Maleabilidade
 Invisibilidade
 Complexibilidade (elementos distintos)
 Baixo custo de manufatura
 Rapidez evolução

51.
Nova mentalidade
• Chef
• Escritor

52.
eXtreme Programming

53.
Valores do XP
RespeitoRespeito
C
om
u
nicação
C
om
u
nicação
Feed
b
ack
Feed
b
ack
C
orag
em
C
orag
em
S
im
plicid
ad
e
S
im
plicid
ad
e

54.
Valores do XP
 Simplicidade
Faça sempre da maneira mais simples e que vá funcionar
 Comunicação
Dentro do time, entre o cliente e a equipe...
 Feedback
Testes de aceitação, presença do cliente
 Coragem
Para fazer refactoring, para jogar fora o código e refazer
tudo no dia seguinte
 Respeito
Trabalho em equipe

55.
Uma pergunta
“Como você programaria se tivesse tempo
suficiente?”
Kent Beck

56.
Possíveis respostas
 Mais testes?
 Mais projeto e arquitetura?
 Menos pessoas?
 Mais qualidade?

57.
Programando ao extremo
Testar toda hora!!
Se projetar é bom, vamos fazer disso parte
do trabalho diário de cada pessoa!
Integrar a maior quantidade de vezes
possível!
Iterações realmente curtas!

58.
Práticas do XP
Testes de
Aceitação
Releases
Curtas
Planning
Game
Cliente
Presente
Integração
Contínua
Passo
Sustentável
Metáfora
Posse
Coletiva Coding
Standard
Design
Simples
Refactoring
Programação
em pares
Test-Driven
Development
Adaptado de xprogramming.com

59.
Cliente presente e envolvido
• Responsabilidade do
projeto:
– Equipe
– Cliente
• Comprometimento

60.
Jogo do planejamento
• Reunião semanal onde todos participam
• Escopo reavaliado
• Cliente prioriza e seleciona as histórias
que serão desenvolvidas
• Ao fim da semana o cliente recebe
produto funcionando

61.
Reunião em pé
• 10/15 minutos
• Todos em pé
• Não é para a solução de problemas
− Todo mundo é convidado
− Apenas a Equipe pode falar
• Sincronização do conhecimento
1. O que fiz desde a última reunião?
2. O que farei até a próxima reunião?
3. Existe algum obstáculo?

62.
Ritmo sustentável
• Semana de 40 horas (8hr/dia)
Sem hora extra:
• Baixa produtividade
• Código de má qualidade
• Aumento de BUGs

63.
Programação em par
• Forneça suporte e ferramentas
• Experimente, você vai se surpreender
• Alterne os pares para não ficar cansativo e
nivelar o time
• Respeite a individualidade das pessoas

64.
Código padronizado

65.
Código Coletivo
• Inibe ilhas de conhecimento
• Padrão de codificação
• Membro da equipe pode ter férias
• Direito de ficar doente

66.
Integração contínua
• Divergências aparecem antes de virar um
problema
• “Isso funcionava na minha máquina”

67.
Projeto simples
• Faça o essencial
• Tudo pode mudar

68.
Refatoração
• “Time que está ganhando não se mexe” – FALSO
• Ex.: Empresas estáveis quebram se não mudarem
• Melhoria contínua

69.
Desenv. Orientado por testes TDD
• Início é um pouco demorado
• Primeiro o teste, depois a funcionalidade
para passar no teste
• Testes automatizados: Unitários, Interface e
Aceitação
• RETORNO: Salvação no FIM do projeto

70.
Releases curtos

71.
Equipe nivelada

72.
Papéis
Tracker
Programador
Goal Donnor
Gold Owner
Coach
Manager
Analista de Testes

73.
Dúvidas?
Luiz Fernando Ramos Costa
Coordenadoria de Serviços e Sistemas de Rede
DTIC – IF-SC – (48) 3877-9051
luiz.costa@ifsc.edu.br
www.fernandocosta.com.br
www.twitter.com/fernandocosta
Agradecimento:
Vinícius Manhães Teles
Improve It
www.innovit.com.br