Embed Size (px)
Citation preview
ProblemasAgillidade
Papéis do ScrumProcesso do
ScrumResultados
PROBLEMAS
PROBLEMASCom desenvolvimento tradicional de
softwareCom desenvolvimento tradicional de
software
TradicionalTradicionalDesenvolvimento em FasesResultados AntecipadosAlto valor do PlanejamentoPouca Visibilidade
Desenvolvimento em FasesResultados AntecipadosAlto valor do PlanejamentoPouca Visibilidade
Requisitos não são claros
Medo de ir para próxima fase
Paralisia da Análise (Analysis paralysis)
Mudança nos Requisitos
Mudanças se tornam mais e mais caras...
Clientes não sabem o que querem...
Projetos demoram muito
Projetos demoram muito
SUCESSO em apenas 34% dos projetos entregues
Longa duração ADIA retorno financeiro para empresa
Fonte: Standish Report 2003
Não há tempo para testes
Não há tempo para testesGarantia de Qualidade é Reduzida
Integração tardia significa falhas mais tarde
Garantia de Qualidade é ReduzidaIntegração tardia significa falhas mais tarde
Tempo jogado no LIXOTempo jogado no LIXO
• 52% dos requisitos entregues
• 64% das funcionalidades são raramente usadas
Fonte: Standish Report 2003
ÁgilDesenvolvimento
De Software
Valores do Manifesto Ágil
Indivíduos e interações, ao invés de processos e ferramentas;
Software funcional, ao invés de documentação compreensiva;
Colaboração do cliente, ao invés de negociação de contrato;
Resposta a mudanças, ao invés de seguir um plano.
Princípios do Manifesto Ágil
• Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual.
• Seja bem-vindo à mudança de requisitos, mesmo que tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
• Entregar software utilizável frequentemente, de algumas semanas a alguns meses, com preferência a menores escalas de tempo.
• Executivos e desenvolvedores devem trabalhar juntos diariamente durante o projeto.
Princípios do Manifesto Ágil
• Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda que eles precisam e confie neles para ter o trabalho concluído.
• O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é conversa face-a-face.
• Software funcional é a medida primordial do progresso.
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente.
Princípios do Manifesto Ágil
• Atenção contínua à excelência técnica e bom design aumenta a agilidade.
• Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
• As melhores arquiteturas, requisitos e design surgem de um time auto-organizado.
• Em intervalos regulares, o time reflete em como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento.
SCRUM
ObjetivoObjetivo Entregar software funcional e de alto
valor agregado para o cliente o mais rápido possível
Entregar software funcional e de alto
valor agregado para o cliente o mais rápido possível
Papéis
Product Owner
Dono da Visão do ProjetoRepresenta o Cliente
Product Owner
Define funcionalidadesPrioriza as funcionalidadeEscolhe datas de lançamento
Dá FeedbackGerencia as partes
interessadasAceita ou Rejeita resultados
Define funcionalidadesPrioriza as funcionalidadeEscolhe datas de lançamento
Dá FeedbackGerencia as partes
interessadasAceita ou Rejeita resultados
TEAMTEAM
Pequeno5-9 pessoas
Auto-organizadoMulti-disciplinar
Dedicado
TEAMTEAM
Define as tarefasEstima o EsforçoDesenvolve o produtoGarante a QualidadeSegrega os Processos
SCRUM MASTER
Líder ServidorProtetor do Time
Quebra-galhoGuia Scrum
SCRUM MASTER
Remove Impedimentos
Previne InterrupçõesFacilitador do TimeSuporta o Processo
Faz a Gestão
Dream Pig Team
Product Owner
Scrum Master
Membros do Time
Usuários
Gerentes
Vendas
X
Processo Scrum
Product Backlog
Expressa Valor
Adia decisões precipitadas
Product Backlog
Product Backlog
Propriedade do Product Owner
Requisitos de alto nível
Expressa o valor de negócio
Não completo, não perfeito
Espera-se que mude e evolua
Visão limitada para o recurso
Product Backlog
Item de BackLog: Número sequencial a
ser adicionado na linha após a criação do Sprint Backlog
Título do Baygon(s): caso o baygon seja relacionado com mais de um baygon, inserir o número e título
dos outros baygons nesta coluna.
Tema ou Módulo ou Sistema para o qual o Baygon se refere.
Sprint ao qual o baygon será
atendido
Benefício de se ter a
funcionalidade
Penalidade de não se ter a funcionalidade
entregue
Valor de Negócio = Soma dos
Benefícios e das Penalidades
O Valor de Negócio é divido pela Estimativa
(dificuldade / complexidade
para se entregar aquela
determinada funcionalidade), resultando no Benefício
Relativo.
Estórias do Usuário
Como um papel [usuário final], eu quero [a vontade] para que [a
razão]
Sprints
Time Box – Recursos Congelados
Escopo Variável – Software Funcionando
Sprint PlanningCapacidade do Time, Product Backlog, Produto Atual, Negócio, Tecnologias
+
=GOAL - OBJETIVO
Sprint Planning
Comunicação Face a Face
Pequenos Passos Reversíveis
Perspectiva do Usuário
Sprint Planning 1
Planejamento de Nível Estratégico
Prioriza e seleciona as funcionalidades
Discute os Critérios de Aceitação
Tira dúvidas
1/2 – 1 hora por Sprint
Sprint Planning 2
Planejamento de Nível Tático
Define os itens do Sprint Backlog
Estima-se os itens do Sprint Backlog
Velocidade do Sprint (baseado no anterior)
Comprometimento entre as partes
1/2 – 1 hora por Sprint
Sprint BacklogSprint Backlog
Repartição do Valor de Negócio
em Tarefas Atribuíveis
Sprint BacklogSprint Backlog
Sprint BacklogSprint Backlog
Propriedade da Equipe
Aloca trabalho ao Time
Sem adições de outros
DailyScrum
O coração do Scrum
DailyScrum
Compromisso e Responsabilidade
Fala-se:
O que fiz, o que vou fazer e quais dificuldades estou
sentindo
DailyScrum
O que eu fiz desde a última reunião?
O que vou fazer até a próxima?
Que coisas estão atrapalhando meu trabalho?
Todos podem participar
Apenas o Time fala
Não se resolvem problemas
Máximo de 15 minutos
De pé
Quadro de Tarefas
Detalhes: http://blogdojonas.com.br/blog/?p=915
Definição deDefinição deEvitar síndrome dos 90%
Codificado, Comitado, Testado, Publicado em Ambiente de Testes, documentado e funcionando
= DONE DONE
Sprint Burn Down
Satisfação do Product Owner
Feedback do Produto
Sprint Review
Informal, nada de slides
Todo o time participa
O mundo é convidado
Sprint Review
Necessária preparação
Mostrar funcionalidades prontas
Aceitação ou Rejeição dos Resultados
1 – 2 horas por Sprint
Sprint Review
Retrospectiva
Evolução do Processo
Retrospectiva
Reflexo do processo e do produto
Todos do Time Participam
Retrospectiva
Sprints
Foco no valor de negócio
Inspeção e Adaptação
SprintsDirigido pelo Product Owner
Passos pequenos reversíveis
Bem vindo à mudança
Time multi-funcional
Inclue projeto e testes
Passos constantes
Compromisso entre as partes
Qualidade Alta, DONE
Feedback
“Fail Fast”
ResultadosEfeitos da Aplicação do
Scrum
Gestão
Planejamento Sucessivo e Constante
Mini-projetos de baixo risco
EscopoFlexível
Permite mudanças em
intervalos fixos
Aprendizagem a cada liberação
EntregaRápida
Time to Market
Valor entregue de forma incremental
MaiorQualidade
Testes acontecem continuamente
Melhoria do Processo
MaiorVisibilidade
Os problemas são visíveis
Progresso visto a cada teste de
software
Times mais felizes e divertidos!
Pré-condiçõesForça
Disciplina
Coragem
Vigor
Paixão
Coaching
Times Estáveis
Multi-funcional
Cliente disponível
RenúnciaNão há práticas de Engenharia
Parece simples
É difícil
Bala de Prata
Não está completo
Leva tempo
Dúvidas?
Tradução e Adaptação
The Zen of Scrum
http://www.slideshare.net/jurgenappelo/the-zen-of-
scrum-10
Jurgen Appelo
Sobre o Palestrante
Blog do Jonasblogdojonas.com.br
Currículocurriculodojonas.blogger.c
om
Twitter@jonastlc
