SlideShare uma empresa Scribd logo
1 de 74
Baixar para ler offline
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
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
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?
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
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
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
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
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
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
SCRUM
Ken Schwaber
@kschwaber
Em resumo...
Imagem disponível em:
www.mountangoatsoftware.com/scrum
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
Scrum Master
 Remove obstáculos
 Não tem autoridade
 Produtividade da equipe
 Conduz eventos
 Escudo da equipe
Equipe (ou team)
 5 a 9 pessoas
 Multi-funcional
 Auto-organizável
 Sugere funcionalidades do
produto
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
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
Planning Poker
 Vamos estimar os itens de Backlog?
Quem?
 Product Owner
 Scrum Master
 Equipe
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
Importância
Qual a importância dos itens de
backlog para o Product Owner?
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
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
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
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
Product Burnup Chart
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
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
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?
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)
Scrum board
Revisão da Sprint
 Informal
 Todos participam
 Hora do feedback
 Resultados do Sprint
Comunicação eficaz:
(bala / bombom)
Retrospectiva da Sprint
 Feita após cada Sprint
 Periodicamente observe pontos positivos e
negativos
 Tipicamente de 15 a 30 minutos
 Todos participam
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
Agora vocês explicam! :)
eXtreme Programming
Kent Beck
@kentbeck
Você está fazendo assim?
Comunicação
Fazer software é dureza
Boa notícia
Cases de sucesso:

Google

Microsoft

Philips

FAB (BR)

Oi Paggo
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
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
Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos
EUA pela empresa Standish Group
64% de desperdício

Podem gerar algumas horas extras para a equipe

Cliente paga por lixo
Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos
EUA pela empresa Standish Group
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 “
Análise
Pai(cliente): 1 dia de projeto
Mãe(desenv.): 9 meses de projeto
Análise
Cliente: “Não era nada disso que eu
queria...”
Mentalidade
Cascata
Custo da mudança
por
Barry
Bohem
Problemas e mudanças
Patente do
VELCRO:
em 1941 por
Georges de Mestral
Meio digital
 Fluidez
 Maleabilidade
 Invisibilidade
 Complexibilidade (elementos distintos)
 Baixo custo de manufatura
 Rapidez evolução
Nova mentalidade
• Chef
• Escritor
eXtreme Programming
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
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
Uma pergunta
“Como você programaria se tivesse tempo
suficiente?”
Kent Beck
Possíveis respostas
 Mais testes?
 Mais projeto e arquitetura?
 Menos pessoas?
 Mais qualidade?
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!
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
Cliente presente e envolvido
• Responsabilidade do
projeto:
– Equipe
– Cliente
• Comprometimento
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
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?
Ritmo sustentável
• Semana de 40 horas (8hr/dia)
Sem hora extra:
• Baixa produtividade
• Código de má qualidade
• Aumento de BUGs
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
Código padronizado
Código Coletivo
• Inibe ilhas de conhecimento
• Padrão de codificação
• Membro da equipe pode ter férias
• Direito de ficar doente
Integração contínua
• Divergências aparecem antes de virar um
problema
• “Isso funcionava na minha máquina”
Projeto simples
• Faça o essencial
• Tudo pode mudar
Refatoração
• “Time que está ganhando não se mexe” – FALSO
• Ex.: Empresas estáveis quebram se não mudarem
• Melhoria contínua
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
Releases curtos
Equipe nivelada
Papéis
Tracker
Programador
Goal Donnor
Gold Owner
Coach
Manager
Analista de Testes
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

Mais conteúdo relacionado

Mais procurados

Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoAchiles Camilo
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveMarcos Alves
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Annelise Gripp
 
Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme ProgrammingMilfont Consulting
 
Gerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshellGerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshellDextra
 
Gestão Ágil de Produtos com Lean Startup para times Scrum
Gestão Ágil de Produtos com Lean Startup para times ScrumGestão Ágil de Produtos com Lean Startup para times Scrum
Gestão Ágil de Produtos com Lean Startup para times ScrumMarcos Garrido
 
Scrum - Framework, Competências e Valores (versão community)
Scrum -  Framework, Competências e Valores (versão community)Scrum -  Framework, Competências e Valores (versão community)
Scrum - Framework, Competências e Valores (versão community)Manoel Pimentel Medeiros
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumMarcos Garrido
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme ProgrammingDenis L Presciliano
 
[Webinar] Scrum - Você está fazendo do jeito certo?
[Webinar] Scrum - Você está fazendo do jeito certo?[Webinar] Scrum - Você está fazendo do jeito certo?
[Webinar] Scrum - Você está fazendo do jeito certo?TargetTrust
 

Mais procurados (20)

Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Enter SCRUM
Enter SCRUMEnter SCRUM
Enter SCRUM
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspective
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme Programming
 
Gerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshellGerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshell
 
MBA em projetos - Gestao Ágil
MBA em projetos - Gestao ÁgilMBA em projetos - Gestao Ágil
MBA em projetos - Gestao Ágil
 
Gestão Ágil de Produtos com Lean Startup para times Scrum
Gestão Ágil de Produtos com Lean Startup para times ScrumGestão Ágil de Produtos com Lean Startup para times Scrum
Gestão Ágil de Produtos com Lean Startup para times Scrum
 
O que é SCRUM
O que é SCRUMO que é SCRUM
O que é SCRUM
 
Agilidade: Scrum e Xp
Agilidade: Scrum e XpAgilidade: Scrum e Xp
Agilidade: Scrum e Xp
 
Facetas do desenvolvedor agil
Facetas do desenvolvedor agilFacetas do desenvolvedor agil
Facetas do desenvolvedor agil
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
 
Scrum - Framework, Competências e Valores (versão community)
Scrum -  Framework, Competências e Valores (versão community)Scrum -  Framework, Competências e Valores (versão community)
Scrum - Framework, Competências e Valores (versão community)
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Gerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com ScrumGerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com Scrum
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme Programming
 
[Webinar] Scrum - Você está fazendo do jeito certo?
[Webinar] Scrum - Você está fazendo do jeito certo?[Webinar] Scrum - Você está fazendo do jeito certo?
[Webinar] Scrum - Você está fazendo do jeito certo?
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
 

Semelhante a SETIC Scrum & XP

Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)André Dias
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrumjrompkovski
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...Luiz Lemos
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012Libia Boss
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To ScrumJuan Bernabó
 
Scrum - Um Método Ágil de Desenvolvimento de Sistemas
Scrum - Um Método Ágil de Desenvolvimento de SistemasScrum - Um Método Ágil de Desenvolvimento de Sistemas
Scrum - Um Método Ágil de Desenvolvimento de SistemasWomen Techmakers Sorocaba
 
Workshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMWorkshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMElumini Outdoing IT
 
Scrum - seminario
Scrum - seminarioScrum - seminario
Scrum - seminariorenatofabro
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com ScrumIgor Macaubas
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareRoberto Brandini
 
Gestão Ágil de Projetos
Gestão Ágil de ProjetosGestão Ágil de Projetos
Gestão Ágil de ProjetosInaniaVerba
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme ProgrammingRodrigo Branas
 

Semelhante a SETIC Scrum & XP (20)

Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
 
Gerenciamento de projetos de TI
Gerenciamento de projetos de TIGerenciamento de projetos de TI
Gerenciamento de projetos de TI
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
Scrum - Um Método Ágil de Desenvolvimento de Sistemas
Scrum - Um Método Ágil de Desenvolvimento de SistemasScrum - Um Método Ágil de Desenvolvimento de Sistemas
Scrum - Um Método Ágil de Desenvolvimento de Sistemas
 
Scrum
ScrumScrum
Scrum
 
Workshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMWorkshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUM
 
Scrum - seminario
Scrum - seminarioScrum - seminario
Scrum - seminario
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Slideshow - Metodologias ágeis
Slideshow - Metodologias ágeisSlideshow - Metodologias ágeis
Slideshow - Metodologias ágeis
 
Scrum
ScrumScrum
Scrum
 
Gestão Ágil de Projetos
Gestão Ágil de ProjetosGestão Ágil de Projetos
Gestão Ágil de Projetos
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
 
Portuguese Scrum
Portuguese ScrumPortuguese Scrum
Portuguese Scrum
 
Metodologias ageis
Metodologias ageisMetodologias ageis
Metodologias ageis
 

SETIC Scrum & XP

  • 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
  • 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
  • 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)
  • 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
  • 35. Você está fazendo assim? Comunicação
  • 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...”
  • 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
  • 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
  • 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
  • 73.
  • 74. 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