Agilidade: SCRUM e XP · Scrum Agenda SCRUM: Fernando Costa formado em Redes de Computadores ... de...
-
Upload
nguyenduong -
Category
Documents
-
view
215 -
download
0
Transcript of Agilidade: SCRUM e XP · Scrum Agenda SCRUM: Fernando Costa formado em Redes de Computadores ... de...
Facilitador
Contexto de projetosValores ágeisPrincípios ágeisScrum
Agenda SCRUM:
Fernando Costaformado em Redes de ComputadoresSócio da 3LJ Tecnologia – www.3lj.com.br
Paradoxo de CobbWe 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 ÁgilProcessos e ferramentasIndivíduos e interações
ao invés de
Seguir um planoResposta à mudanças
www.agilemanifesto.org - 2001
Documentação abrangenteSoftware que funciona
Negociação de contratoColaboração do cliente
Princípios do Manifesto Ágil1 - 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 Ágil4 - 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 Ágil7 - 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 Ágil10 - 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
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
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 Cesta de compras
3 Cadastro do cliente
4 Boleto bancário
5 Cartão de crédito
Nosso Product BacklogID Nome Importância Estimativa Observação
1 Catálogo de produtos
3
2 Cesta de compras
5
3 Cadastro do cliente
2
4 Boleto bancário 4
5 Cartão de crédito
3
Must(tem que
ter)
Should(deveria ter)
Could(poderia ter)
Want(interessante)
Catálogo de produtos
Boleto bancário
Videos dos produtos
Cadastro de clientes
Controle de estoque
Cesta de compras
Registro do Pedido e entrega
Cartão de crédito
Fotos dos produtos
Regras de promoção
Nosso Product BacklogID Nome Importância Estimativa Observação
1 Catálogo de produtos
1 3
2 Cesta de compras
1 5
3 Cadastro do cliente
1 2
4 Boleto bancário 2 4 BB e CEF
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
Planejamento do 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
ID - 1Catálogo de produtos
ID – 1.1Administrador dos
Produtos10 horas
Planejamento do Sprint
ID – 1.2 Busca fonética de
produtos2 horas
ID – 1.3Front-end da Loja
15 horas
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)
Revisão do Sprint Informal Todos participam Hora do feedback Resultados do Sprint
Comunicação eficaz:(bala / bombom)
Retrospectiva do 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
Resumo: Gerenciamento ágilTópico CaracterísticasObjetivo principal Orientado ao produto e centrado nas pessoasTipo do projeto Projetos com mudanças constantes e que necessitam de respostas
rápidasTamanho Mais efetivo em projeto pequenos(5 a 9 pessoas)Gerente do projeto Papel de facilitador ou coordenadorEquipe do projeto Atuação colaborativa em todas as atividades do projetoCliente Essencial. Deve ser parte integrante da equipe do projetoPlanejamento Curto e com a participação de todos os envolvidos na elaboração
do planejamentoArquitetura Aplicação de design simples. Evolui junto com o projeto e
baseia-se na refatoraçãoModelo de desenvolvimento
Iterativo e Incremental
Comunicação Informal
Tópico Características
Dúvidas?Fernando Costa
www.3lj.com.br www.innovit.com.br
Patrocínio: Agradecimento:
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
Principais falhas:
a) Não entregam o acordado
b) Orçamento
c) Prazo
d) Todas alternativas
Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group
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 “Vinícius Manhães Teles
Meio digital Fluidez Maleabilidade Invisibilidade Complexibilidade (elementos distintos) Baixo custo de manufatura Rapidez evolução
RespeitoRespeito
Valores do XP
Comunicação
Comunicação
Simplicidade
Simplicidade
Feedback
Feedback
Coragem
Coragem
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
Integração Contínua Ritmo
Sustentável
Metáfora
Código Coletivo Coding
Standard
Design Simples
RefactoringProgramação
em pares
Test-Driven Development
Testes de Aceitação
Releases Curtas
Planning Game
Cliente Presente
Adaptado de xprogramming.com
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 conhecimento1. 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 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”
Refatoração “Time que está ganhando não se mexe” –
FALSO Ex.: Empresas estáveis quebram se não
mudarem Melhoria contínua
Desenvolvimento Orientado
a 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
Dúvidas?
Fernando [email protected]
3LJ Tecnologiawww.3lj.com.br
Agradecimento:Vinícius Manhães TelesImprove It