setic scrum & xp
DESCRIPTION
Agilidade com Scrum e XP apresentado no SETIC 2010 do IFSCTRANSCRIPT
Agilidade com Scrum e eXtreme Programming
Luiz Fernando Ramos Costa
Coordenadoria de Serviços e Sistemas de Rede
DTIC – IF-SC – (48) 3877-9051
www.fernandocosta.com.br
www.twitter.com/fernandocosta
Facilitador
Scrum
eXtreme Programming
Agenda
Fernando CostaFormado em Redes de ComputadoresPós-graduando em Eng. de SoftwareCertificado LPIC-1, NCLA, DCTSOrientador 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 planoResposta à 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 BacklogID 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 BacklogID 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 BacklogID 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 chart1. 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 fazendoEsta é 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:
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 projetoMãe(desenv.): 9 meses de projeto
Análise
Cliente: “Não era nada disso que eu queria...”
Mentalidade
Cascata
Custo da mudança
porBarry
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
Comunicação
Comunicação
Feedback
Feedback
Coragem
Coragem
Simplicidade
Simplicidade
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
RefactoringProgramaçã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
www.fernandocosta.com.br
www.twitter.com/fernandocosta
Agradecimento:
Vinícius Manhães Teles
Improve It www.innovit.com.br