TREINAMENTO
ÁGIL / SCRUM
Gerente de Projetos e Scrum Master
Alessandro_rodrigues@terra.com.br
ALESSANDRO RODRIGUES, CSM
COMO SURGIU O ÁGIL?
• O ágil surgiu dado a necessidade de
melhorarmos a forma como estamos
desenvolvendo SW e nosso foco principal é
satisfazer o cliente.
MANIFESTO ÁGIL
Mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
PRINCÍPIOS ÁGIL
• Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor.
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa
tirar vantagens competitivas.
• Entregar software funcionando com frequência, na escala de semanas
até meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diariamente, durante todo o curso do projeto.
• Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e por
dentro de um time de desenvolvimento, é através de uma conversa
cara a cara.
PRINCÍPIOS ÁGIL
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.
• Contínua atenção à excelência técnica e bom design, aumenta a
agilidade.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não
precisou ser feito.
• As melhores arquiteturas, requisitos e designs emergem de times auto
organizáveis.
• Em intervalos regulares, o time reflete em como ficar mais efetivo,
então, se ajustam e otimizam seu comportamento de acordo.
TRADICIONAIS X ÁGIL
• TODAS metodologias de projetos existem
planejamento antes da execução.
• Tradicionais (PMI e PRINCE, podia usar a palavra
burocracia) se planeja muito com antecedência.
• Plano de Projeto.
• Cronograma detalhado de atividades.
• ...
• Ágeis (SCRUM, DSDM, XP e FDD) se planeja de
forma iterativa e incremental, descobrindo o
percurso no caminho.
TRADICIONAIS X ÁGIL
• Tradicionais: As especificações são mais importantes
que o prazo e custo: o cliente pode querer um carro
com 140 HPs, 5 portas, completo e não menos do
que isso.
• Ágeis: Focam em resolver o problema com um
orçamento e prazo fixo. O cliente precisa de um
veículo e está disposto a aceitar uma bicicleta, uma
moto um carro
TRADICIONAIS X ÁGIL
O QUE É SER ÁGIL?
• Ágil é uma nova forma de gestão e desenvolvimento
de Software que usa uma abordagem de
planejamento e execução iterativa e incremental
• Divide o problema em produtos menores e que visa
entregar software funcionando regularmente
• Visa a aproximação e maior colaboração do time de
desenvolvimento com os experts de negócios
O QUE É SER ÁGIL?
• Então quer dizer que ser Ágil não é entregar mais
rápido?
QUAL O MOTIVO DE SER ÁGIL?
• Maior produtividade e menores custos.
• Projetos ágeis são no mínimo 16% mais produtivos.
• Maior engajamento e satisfação no trabalho da
equipe.
• Melhoria mínima de 10% e média de 63%.
• Maior qualidade
• Maior satisfação dos envolvidos.
QUAL O MOTIVO DE SER ÁGIL?
• Ágil é tão apaixonante quanto um bebe panda.
• Uma gestão transparente e participativa
(management 3.0)
• Porque ser ágil não é simplesmente rodar sprints,
fazer daily meeting ou então montar um kanban
na parede, e sim saber ser transparente, dar e
receber feedback, conflitar, confiar, sempre
enxergar o valor além do código escrito e
entender que o seu melhor amigo é o cliente.
• É por isso que foi tão fácil se apaixonar pelo ágil:
ele te move, te energiza e acima de tudo é
inovação.
VANTAGENS PARA O CLIENTE.
• Foco e maximização do ROI (Retorno do Investimento) e do
Valor de Negócio;
• Entregas do produto + rápida, frequentes e regulares;
• Aceleração do Time-to-market o que se traduz em ganho de
competitividade;
• Foco no que é prioritário e traz mais valor para o usuário, o
que se traduz em ganho de usabilidade;
• Transparência e visibilidade do status do projeto;
• Flexibilidade para mudanças de requisitos e prioridades além
de maior agilidade na tomada de decisões;
• Melhoria da Qualidade do produto final;
• Produtividade;
• Redução dos riscos e das indesejáveis surpresas.
VANTAGENS PARA O EQUIPE.
• Escopo e objetivos claros e priorizados;
• Equipes auto gerenciáveis, maior autonomia, disciplina e
regularidade;
• Maximização do comprometimento;
• Melhoria na comunicação. A comunicação intensa com o
cliente e a gestão de suas expectativas são parte do processo;
• Inspeção e Adaptação constantes do processo em busca da
melhoria contínua e a redução dos desperdícios;
• Antecipação dos problemas e maior agilidade na tomada de
ações.
SCRUM
• Desenvolvimento Incremental
• Que aumenta gradualmente
• Entrega de Valores
• Desenvolvimento Iterativo
• reiterado, repetido
• Teoria da Complexidade
• Timebox
• Lean
TEORIA DA COMPLEXIDADE
Auto
Organização
A  ?
Especialista
A 
A B
C
Processos
A  B
Reação
?  ?
AGILIDADE
Valor de
Negócio
Qualidade
Cultura
AGILIDADE
AGILIDADE
Valor de
Negócio
Qualidade
Técnica
Cultura
(Pessoas e Processos)
Agilidade
AGILIDADE
O QUE É SCRUM?
Scrum é uma estrutura processual (framework) para suportar o
desenvolvimento e manutenção de produtos complexos. O Scrum
consiste em Equipes do Scrum associadas a seus papéis, eventos,
artefatos e regras. Cada componente dentro do framework serve
a um propósito específico e é essencial para o uso e o sucesso do
Scrum.
É um framework ágil para gestão e planejamento de projetos de
software que permite manter o foco na entrega do maior valor de
negócio, no menor tempo possível;
Permite a rápida e contínua inspeção do software em produção;
O QUE É SCRUM?
FRAMEWORK
FRAMEWORKFRAMEWORKFRAMEWORK
- Kanban
- Burndow
SCRUM BUT
O QUE É SCRUM?
Fluxo Papéis
Artefatos Eventos
Valores
e
Princípios
SCRUM E SEUS VALORES
• Foco
• Vamos concentrar em apenas em um pouco de coisas. Nós entregamos
itens valiosos mais cedo
• Coragem
• Trabalhamos como equipe. Coragem para assumir desafios maiores
• Abertura
• A medida que trabalhamos juntos, expressamos como estamos fazendo,
o que está em nossos caminhos e as nossas preocupações.
• Compromisso
• Temos grande controle sobre os nossos compromissos, estamos
comprometidos com o sucesso.
• Respeito
• A medida que trabalhamos juntos, compartilhamos os sucessos e
fracassos.
PAPEIS
PAPEIS
SCRUM TEAM
POSICIONAMENTO DOS PAPEIS
PRODUCT OWNER
Composição: 1 PO  1 DEV TEAM
Habilidades:
• Negócio
• Análise de Negócio
• Gestão do Projeto e/ou Produto
Responsabilidades:
• Dono do Product Backlog
• Dono das prioridades
• Sabe o que deve ser feito e o porque deve ser feito
• Gestão da Visão
• Escreve, Refina e Prioriza os Requisitos
• Gestão dos Releases
• Aceitar ou Rejeitar as entregas do DEV Team
• Forte comunicação com o DEV Team
• Gestão do BUDGET
• Comunica Status Report para os Envolvidos
DEV TEAM
Composição: (3) 5 – 9 pessoas
Habilidades:
• Possuir todo conhecimento técnico necessário
para entregar incremento de produto pronto.
• Auto-Organização (Gestão)
• Comunicação
Responsabilidades:
• Planejar e Gerenciar a Sprint
• Se comprometer e entregar uma meta ao PO.
• Apontar os Impedimentos
• Resolver seus próprios problemas
• Definir soluções técnicas para o produto.
DEV TEAM
Cobra
Ajuda
Auto-Organização
PO
Compartilha as
Metas
“Isso não é
problema meu”
SCRUM MASTER
Composição: 1 SM  1 DEV TEAM
Habilidades:
• MAIOR conhecedor de Scrum naquele projeto.
• Conhecer outros processos.
• Gestão de Pessoas (Soft Skills)
Responsabilidades:
• Ensinar o processo / Manter o processo funcionando
• É um facilitador
• Garante o correto uso dos processos
• Remove os impedimentos do DEV Team
• Energiza as pessoas mantendo-as focadas e
comprometidas
• Facilita as reuniões e discussões
• Fornece coaching aos envolvidos no projeto
SPRINT
SPRINT: O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o
qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado
SPRINT
Produto / Serviço (Valor):
• Cliente / Usuários-Alvo
• Problemas
• Benefícios
• Diferenciais
• Macro Funcionalidades
(Product Backlog)
Projeto (Restrições)
• Custo / Prazo
• Contratos e Aquisições
• Arquitetura e Tecnologia
• Riscos
• ...
Processos (Conformidades)
• Governança
• Certificações, Modelos
• CMMI2...
• Primeiras definições
• Tamanho do Sprint
• Def. of Ready
• Def. of Done
• ...
Participantes: PO, SM, DEV TEAM e Outros Interessados
Reunião de Visão (Pre Game)
SPRINT
+ Valor
+ Granularidade
+ Detalhes
Negócio
BUG
Pesquisa
PBI
Product Backlog
SPRINT
Meta
Reunião de Planejamento (Planning)
Objetivo:
• Primeira Parte (O que?): Apresentação dos Product Backlog Priorizado e
Definir a Meta
• Durante o Sprint Planning Meeting, o Product Owner descreve as
funcionalidades de maior prioridade para a equipe.
• A equipe faz perguntas durante a reunião de modo que seja capaz de
quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas
tarefas irão dar origem ao Sprint Backlog.
• Define o Sprint Backlog Inicial.
• Jogas-se o Planning Poker.
• Define um objetivo para o Sprint, que é uma breve descrição daquilo que
se tentará alcançar no Sprint.
• Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint.
• Depois do Sprint Planning Meeting, a equipe Scrum se encontra
separadamente para conversar sobre o que eles escutaram e decidir
quanto eles podem se comprometer a fazer no Sprint que será iniciado.
Participantes: PO, SM, DEV TEAM e Outros Interessados
SPRINT
Meta
Reunião de Planejamento (Planning)
Objetivo:
• Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint.
• Depois do Sprint Planning Meeting, a equipe Scrum se encontra
separadamente para conversar sobre o que eles escutaram e decidir
quanto eles podem se comprometer a fazer no Sprint que será iniciado.
• Cria-se as atividades
• Cria-se o quadro Kanban
• Cria-se o Burndow.
Participantes: PO, SM, DEV TEAM e Outros Interessados
SPRINT
Reunião de Planejamento (Planning)
Meta
PO
PO
DEV Team
DEV Team
3 5
3
Def. Of Done
• Codificado seguindo o padrão X
• Testado.
• Documentado
• Liberado em ambiente de QA
• Reduz dívidas técnicas
• Ajuda nas “Alterações de 2
minutos”
SPRINT
Reunião de Planejamento (Planning)
SPRINT
Burndow
O Burndown chart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum
(somente para o Dev Team) para representar diariamente o progresso do trabalho em
desenvolvimento. Saber o quanto falta de trabalho. Ou seja, após cada dia de trabalho
o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho
total planejado.
SPRINT
Objetivo:
• Disseminar conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
• Ocorre no mesmo lugar, no mesmo horário com duração máxima de 15
minutos. REALIZADA EM PÉ.
• Daily Scrum não deve ser usado como uma reunião para resolução de
problemas.
• Cada membro da equipe provê respostas para cada uma destas três
perguntas:
• O que você fez ontem?
• O que você fará hoje?
• Há algum impedimento no seu caminho?
• O Daily Scrum não é uma reunião de status report na qual um chefe fica
coletando informações sobre quem está atrasado. É uma reunião na qual
membros da equipe assumem compromissos perante os demais.
• Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum
Master o mais rapidamente possível.
Participantes: SM e DEV TEAM. PO se necessário
Reunião Diária (Daily)
SPRINT
Sprint – Reunião de Revisão do Sprint (Review)
Objetivo:
• O Dev Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso
tem o formato de um demo das novas funcionalidades.
• Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do
Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe
completou cada um dos itens do Product Backlog trazidos para fazer parte do
Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do
Sprint.
• Não deve ocorrer surpresa, pois houve a DAILY com todos os envolvidos.
• Atualizar o status do projeto.
• Os itens que deram problemas será tratados no próximo Sprint.
Participantes: PO, SM, DEV TEAM e Outros Interessados
SPRINT
Sprint – Reunião de Retrospectiva (Retrospective)
Objetivo:
• Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o
que pode ser melhorado e que ações serão tomadas para melhora.
• Apontar quais foram os pontos críticos do Sprint para discutir com todos os
envolvidos na intenção de melhorar no próximo Sprint.
• Utilizar o método de o que foi BOM, RUIM e o que pode MELHORAR criando
planos de ação para os itens que foram ruins e as melhorias apontadas.
• As melhorias podem virar item no Sprint Backlog
Participantes: PO, SM, DEV TEAM e Outros Interessados
Sprint RetroMelhoria
SPRINT
Sprint Planning
1
Sprint Planning
2
Sprint Review
Daily Daily Daily
Sprint na prática
O que?
Como?
Progresso Progresso Progresso
Resultado
SPRINT
Definição de Pronto (Def. Of Done)
Def. Of Done
• Codificado seguindo o padrão X
• Testado utilizando as técnicas X e Y
• Documentado.
• Liberado em ambiente de QA
• Reduz dívidas técnicas
• Ajuda nas “Alterações de 2
minutos”
Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”,
todos devem entender o que o “Pronto” significa.
Com um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida
para incluir critérios mais rigorosos de alta qualidade.
SPRINT
E NA PRÁTICA
DÚVIDAS?
MUITO
OBRIGADO!
MAIORES INFORMAÇÕES
Estou a disposição

Treinamento Ágil / Scrum

  • 1.
  • 2.
    Gerente de Projetose Scrum Master Alessandro_rodrigues@terra.com.br ALESSANDRO RODRIGUES, CSM
  • 3.
    COMO SURGIU OÁGIL? • O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.
  • 4.
    MANIFESTO ÁGIL Mesmo havendovalor nos itens à direita, valorizamos mais os itens à esquerda.
  • 5.
    PRINCÍPIOS ÁGIL • Nossamaior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. • Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • 6.
    PRINCÍPIOS ÁGIL • Softwarefuncional é a medida primária de progresso. • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. • Contínua atenção à excelência técnica e bom design, aumenta a agilidade. • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. • As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis. • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
  • 7.
    TRADICIONAIS X ÁGIL •TODAS metodologias de projetos existem planejamento antes da execução. • Tradicionais (PMI e PRINCE, podia usar a palavra burocracia) se planeja muito com antecedência. • Plano de Projeto. • Cronograma detalhado de atividades. • ... • Ágeis (SCRUM, DSDM, XP e FDD) se planeja de forma iterativa e incremental, descobrindo o percurso no caminho.
  • 8.
    TRADICIONAIS X ÁGIL •Tradicionais: As especificações são mais importantes que o prazo e custo: o cliente pode querer um carro com 140 HPs, 5 portas, completo e não menos do que isso. • Ágeis: Focam em resolver o problema com um orçamento e prazo fixo. O cliente precisa de um veículo e está disposto a aceitar uma bicicleta, uma moto um carro
  • 9.
  • 10.
    O QUE ÉSER ÁGIL? • Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma abordagem de planejamento e execução iterativa e incremental • Divide o problema em produtos menores e que visa entregar software funcionando regularmente • Visa a aproximação e maior colaboração do time de desenvolvimento com os experts de negócios
  • 11.
    O QUE ÉSER ÁGIL? • Então quer dizer que ser Ágil não é entregar mais rápido?
  • 12.
    QUAL O MOTIVODE SER ÁGIL? • Maior produtividade e menores custos. • Projetos ágeis são no mínimo 16% mais produtivos. • Maior engajamento e satisfação no trabalho da equipe. • Melhoria mínima de 10% e média de 63%. • Maior qualidade • Maior satisfação dos envolvidos.
  • 13.
    QUAL O MOTIVODE SER ÁGIL? • Ágil é tão apaixonante quanto um bebe panda. • Uma gestão transparente e participativa (management 3.0) • Porque ser ágil não é simplesmente rodar sprints, fazer daily meeting ou então montar um kanban na parede, e sim saber ser transparente, dar e receber feedback, conflitar, confiar, sempre enxergar o valor além do código escrito e entender que o seu melhor amigo é o cliente. • É por isso que foi tão fácil se apaixonar pelo ágil: ele te move, te energiza e acima de tudo é inovação.
  • 14.
    VANTAGENS PARA OCLIENTE. • Foco e maximização do ROI (Retorno do Investimento) e do Valor de Negócio; • Entregas do produto + rápida, frequentes e regulares; • Aceleração do Time-to-market o que se traduz em ganho de competitividade; • Foco no que é prioritário e traz mais valor para o usuário, o que se traduz em ganho de usabilidade; • Transparência e visibilidade do status do projeto; • Flexibilidade para mudanças de requisitos e prioridades além de maior agilidade na tomada de decisões; • Melhoria da Qualidade do produto final; • Produtividade; • Redução dos riscos e das indesejáveis surpresas.
  • 15.
    VANTAGENS PARA OEQUIPE. • Escopo e objetivos claros e priorizados; • Equipes auto gerenciáveis, maior autonomia, disciplina e regularidade; • Maximização do comprometimento; • Melhoria na comunicação. A comunicação intensa com o cliente e a gestão de suas expectativas são parte do processo; • Inspeção e Adaptação constantes do processo em busca da melhoria contínua e a redução dos desperdícios; • Antecipação dos problemas e maior agilidade na tomada de ações.
  • 16.
    SCRUM • Desenvolvimento Incremental •Que aumenta gradualmente • Entrega de Valores • Desenvolvimento Iterativo • reiterado, repetido • Teoria da Complexidade • Timebox • Lean
  • 17.
    TEORIA DA COMPLEXIDADE Auto Organização A ? Especialista A  A B C Processos A  B Reação ?  ?
  • 18.
  • 19.
  • 20.
  • 21.
    O QUE ÉSCRUM? Scrum é uma estrutura processual (framework) para suportar o desenvolvimento e manutenção de produtos complexos. O Scrum consiste em Equipes do Scrum associadas a seus papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e o sucesso do Scrum. É um framework ágil para gestão e planejamento de projetos de software que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível; Permite a rápida e contínua inspeção do software em produção;
  • 22.
    O QUE ÉSCRUM? FRAMEWORK FRAMEWORKFRAMEWORKFRAMEWORK - Kanban - Burndow SCRUM BUT
  • 23.
    O QUE ÉSCRUM? Fluxo Papéis Artefatos Eventos Valores e Princípios
  • 24.
    SCRUM E SEUSVALORES • Foco • Vamos concentrar em apenas em um pouco de coisas. Nós entregamos itens valiosos mais cedo • Coragem • Trabalhamos como equipe. Coragem para assumir desafios maiores • Abertura • A medida que trabalhamos juntos, expressamos como estamos fazendo, o que está em nossos caminhos e as nossas preocupações. • Compromisso • Temos grande controle sobre os nossos compromissos, estamos comprometidos com o sucesso. • Respeito • A medida que trabalhamos juntos, compartilhamos os sucessos e fracassos.
  • 25.
  • 26.
  • 27.
  • 28.
    PRODUCT OWNER Composição: 1PO  1 DEV TEAM Habilidades: • Negócio • Análise de Negócio • Gestão do Projeto e/ou Produto Responsabilidades: • Dono do Product Backlog • Dono das prioridades • Sabe o que deve ser feito e o porque deve ser feito • Gestão da Visão • Escreve, Refina e Prioriza os Requisitos • Gestão dos Releases • Aceitar ou Rejeitar as entregas do DEV Team • Forte comunicação com o DEV Team • Gestão do BUDGET • Comunica Status Report para os Envolvidos
  • 29.
    DEV TEAM Composição: (3)5 – 9 pessoas Habilidades: • Possuir todo conhecimento técnico necessário para entregar incremento de produto pronto. • Auto-Organização (Gestão) • Comunicação Responsabilidades: • Planejar e Gerenciar a Sprint • Se comprometer e entregar uma meta ao PO. • Apontar os Impedimentos • Resolver seus próprios problemas • Definir soluções técnicas para o produto.
  • 30.
  • 31.
    SCRUM MASTER Composição: 1SM  1 DEV TEAM Habilidades: • MAIOR conhecedor de Scrum naquele projeto. • Conhecer outros processos. • Gestão de Pessoas (Soft Skills) Responsabilidades: • Ensinar o processo / Manter o processo funcionando • É um facilitador • Garante o correto uso dos processos • Remove os impedimentos do DEV Team • Energiza as pessoas mantendo-as focadas e comprometidas • Facilita as reuniões e discussões • Fornece coaching aos envolvidos no projeto
  • 32.
    SPRINT SPRINT: O coraçãodo Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado
  • 33.
    SPRINT Produto / Serviço(Valor): • Cliente / Usuários-Alvo • Problemas • Benefícios • Diferenciais • Macro Funcionalidades (Product Backlog) Projeto (Restrições) • Custo / Prazo • Contratos e Aquisições • Arquitetura e Tecnologia • Riscos • ... Processos (Conformidades) • Governança • Certificações, Modelos • CMMI2... • Primeiras definições • Tamanho do Sprint • Def. of Ready • Def. of Done • ... Participantes: PO, SM, DEV TEAM e Outros Interessados Reunião de Visão (Pre Game)
  • 34.
    SPRINT + Valor + Granularidade +Detalhes Negócio BUG Pesquisa PBI Product Backlog
  • 35.
    SPRINT Meta Reunião de Planejamento(Planning) Objetivo: • Primeira Parte (O que?): Apresentação dos Product Backlog Priorizado e Definir a Meta • Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. • A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog. • Define o Sprint Backlog Inicial. • Jogas-se o Planning Poker. • Define um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. • Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint. • Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Participantes: PO, SM, DEV TEAM e Outros Interessados
  • 36.
    SPRINT Meta Reunião de Planejamento(Planning) Objetivo: • Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint. • Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. • Cria-se as atividades • Cria-se o quadro Kanban • Cria-se o Burndow. Participantes: PO, SM, DEV TEAM e Outros Interessados
  • 37.
    SPRINT Reunião de Planejamento(Planning) Meta PO PO DEV Team DEV Team 3 5 3 Def. Of Done • Codificado seguindo o padrão X • Testado. • Documentado • Liberado em ambiente de QA • Reduz dívidas técnicas • Ajuda nas “Alterações de 2 minutos”
  • 38.
  • 39.
    SPRINT Burndow O Burndown chartou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum (somente para o Dev Team) para representar diariamente o progresso do trabalho em desenvolvimento. Saber o quanto falta de trabalho. Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado.
  • 40.
    SPRINT Objetivo: • Disseminar conhecimentosobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. • Ocorre no mesmo lugar, no mesmo horário com duração máxima de 15 minutos. REALIZADA EM PÉ. • Daily Scrum não deve ser usado como uma reunião para resolução de problemas. • Cada membro da equipe provê respostas para cada uma destas três perguntas: • O que você fez ontem? • O que você fará hoje? • Há algum impedimento no seu caminho? • O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. É uma reunião na qual membros da equipe assumem compromissos perante os demais. • Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível. Participantes: SM e DEV TEAM. PO se necessário Reunião Diária (Daily)
  • 41.
    SPRINT Sprint – Reuniãode Revisão do Sprint (Review) Objetivo: • O Dev Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. • Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint. • Não deve ocorrer surpresa, pois houve a DAILY com todos os envolvidos. • Atualizar o status do projeto. • Os itens que deram problemas será tratados no próximo Sprint. Participantes: PO, SM, DEV TEAM e Outros Interessados
  • 42.
    SPRINT Sprint – Reuniãode Retrospectiva (Retrospective) Objetivo: • Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhora. • Apontar quais foram os pontos críticos do Sprint para discutir com todos os envolvidos na intenção de melhorar no próximo Sprint. • Utilizar o método de o que foi BOM, RUIM e o que pode MELHORAR criando planos de ação para os itens que foram ruins e as melhorias apontadas. • As melhorias podem virar item no Sprint Backlog Participantes: PO, SM, DEV TEAM e Outros Interessados
  • 43.
    Sprint RetroMelhoria SPRINT Sprint Planning 1 SprintPlanning 2 Sprint Review Daily Daily Daily Sprint na prática O que? Como? Progresso Progresso Progresso Resultado
  • 44.
    SPRINT Definição de Pronto(Def. Of Done) Def. Of Done • Codificado seguindo o padrão X • Testado utilizando as técnicas X e Y • Documentado. • Liberado em ambiente de QA • Reduz dívidas técnicas • Ajuda nas “Alterações de 2 minutos” Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Com um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade.
  • 45.
  • 46.
  • 47.
  • 48.

Notas do Editor

  • #4 Oficialmente surgiu em 2001.
  • #5 Oficialmente surgiu em 2001.
  • #8 Desenvolvimento Incremental Que aumenta gradualmente Desenvolvimento Iterativo reiterado, repetido
  • #18 Então quer dizer que não posso usar Scrum em sistemas Complicado (Esforço Definido).
  • #22 Cliente não fica esperando meses para ver os sistema. No final do Sprint ele tem um Sistema funcionando (PRONTO)>
  • #23 SCRUM É UM FRAMEWORK... VC PODE ACRESCENTAR SUAS NECESSIDADES. MAS NÃO PODE TIRAR
  • #33 As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a restrospectiva da Sprint.
  • #40 Não serve para status report. Mostra por time
  • #41 Problemas: Demora, Pessoas Atrasadas, Resposta mecânica as perguntas, Não são levados impedimentos.