SlideShare uma empresa Scribd logo
1 de 55
ENTER SCRUM

Breno Campos
TaSafo.org

Safos@yahoogrupos.com.br
TaSafo.org

Quem Somos?
Comunidade de
profissionais
e estudantes de
Tecnologia da Informação.
TaSafo.org

Como ser um Safo?
Entre na lista de discussão.
Participe dos eventos.
Venha pra frente.
Compartilhe algo.
Quem é Breno Campos?
• Bacharel em Sistemas de Informação – UFPa;
• Especialista em Gerência de Projetos de Software – UFPa;
• CSM – Certified SCRUM Master;
• Membro do PMI – SP;
• Trabalha a 4 anos com metodologias ágeis, principalmente
SCRUM;
• Não é desenvolvedor;
• Aficionado por Gestão de TI;
• Atualmente auxilia na Coordenação de uma Equipe de
Desenvolvimento e presta consultoria de Gestão de
Projetos;
ENTER SCRUM

Breno Campos
• Intro
• Pilares
• Papéis
• Cerimônias
• Artefatos
• Definição de Pronto
• Considerações Finais
MANIFESTO ÁGIL

Estamos
descobrindo
maneiras
melhores de desenvolver software
fazendo-o nós mesmos e ajudando
outros a fazê-lo.
Nossos Valores:
• Indivíduos e interação entre eles mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano
Nossos Princípios:
• 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.
Nossos Princípios:
• 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.
• 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.
Nossos Princípios:
• 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.
Os pais da criança

Ken Schwaber

Jeff Sutherland
Origem do nome
O SCRUM NÃO É!
Ferramenta

Técnica

Processo
Então, o que é?
É uma “fusão”!
Beleza, mas como o SCRUM roda?
De forma Iterativa
e Incremental...
O SCRUM é sustentado por 3 pilares.
Transparência Inspeção

Adaptação
Pra quem não entendeu...

<< Patrícia Pilar
Transparência

Os aspectos mais significativos
do projeto devem estar
visíveis
para
todos
os
envolvidos. Deixando claro o
que está sendo feito, o que
ainda será feito, e o que está
pronto.
Inspeção
Os
envolvidos
devem
inspecionar os artefatos
gerados, para verificar se o
projeto está seguindo de
acordo com o planejado,
detectando variações de
desempenho.

Deve-se tomar cuidado
com a frequência das
inspeções para que não
chegue ao ponto de
atrapalhar o andamento do
desenvolvimento;
Baseado
nos
resultados
obtidos da inspeção, a
adaptação
realiza
as
alterações necessárias para
que o projeto continue seu
bom andamento, ou para
consertar falhas;

Adaptação
O SCRUM possui 3 papéis.
Equipe de Desenvolvimento
• Auto gerenciáveis;
• “Sem títulos” definidos;
• TODOS são desenvolvedores;
Product Owner
•
•
•
•

Responsável por Maximizar o ROI;
Gerencia as demandas;
Prioriza as tarefas;
Garante que a E.D. entenda as
tarefas;
• Apenas UMA pessoa;
SCRUM Master
• Líder Servidor;
• Remover impedimentos;
• Proteger a equipe;
SCRUM Master
NÃO É
Gerente de Projetos
Não delega tarefas;
Não define responsabilidades;
Cerimônias
Objetivos
• Criar rotinas;
• Diminuir a quantidade de reuniões desnecessárias;
Time-Boxed

Tempo limite definido!
Sprint
• Principal cerimônia do SCRUM;
• Todas as outras estão contidas
nela;
• Time-Boxing de 1 a 4 semanas;
• Durante essa iteração (Sprint),
é gerada uma release (uma
versão utilizável do produto);
Sprint
• A Sprint é blindada, o que foi
planejado deve ser executado!
• A Sprint pode ser cancelada, mas
somente o Product Owner tem
poder para isso. Seus motivos
podem
variar,
como
o
cancelamento
do
projeto,
mudança de tecnologia ou outros.
Sprint Planning
• Reunião onde é Planejado o que será
executado na Sprint;
• Time-Box: 8 horas para uma sprint de
quatro semanas e deve ser
proporcional para sprints menores;
• O time tenta prever o que ocorrerá
durante a sprint (feriados, faltas, etc);
• A equipe deve estimar as tarefas
priorizadas pelo PO, e alocá-las na
sprint, obedecendo a quantidade de
esforço estimada.
Daily Meeting
• Também conhecida como Stand up
meeting é feita para sincronizar a
equipe, deixar todos a par dos
acontecimentos, e dos avanços de
cada um;
• Time-Box: 15 minutos, o motivo de
ser uma “reunião em pé”, é para
durar mais do que o necessário;
Daily Meeting
• Três perguntas:
• “O que você fez até aqui?”;
• “O que você pretende fazer até
a próxima daily meeting?”;
• “Quais impedimentos você está
tendo?”
Sprint Review
• Os participantes dela são os
integrantes do time Scrum (time
de desenvolvimento, SM e PO);
• Time-Box: 4 horas para uma sprint
de 4 semanas e deve ser
proporcional
para
sprints
menores;
• O P.O. verifica o que está pronto, e
o que não está, é apresentado as
tarefas realizadas;
Sprint Retrospective
• É realizada para que o time possa se
inspecionar, encontrar acertos e falhas,
e pensar em meios de tentar corrigir o
que não saiu como o esperado;
• Ocorre entre a Sprint Review e o Sprint
Planning;
• Time-Box: 3 horas para uma sprint de
um mês e deve ser proporcional para
sprints menores;
Artefatos
Objetivo
• Maximizar a transparência das informações.
Product Backlog
• É o ‘container’ que guarda todas as
tarefas definidas pelo PO;
• É o PO que mantém o backlog, ou seja,
ele inclui tarefas, retira tarefas e as
ordena de acordo com suas prioridades;
• Um backlog de produto dificilmente está
completo, as primeiras iterações
estabelecem requisitos iniciais, e com o
passar dos ciclos o número de requisitos
tende a aumentar;
Product Backlog
• Vale lembrar, que o backlog de produto
é dinâmico, o PO pode alterá-lo em
qualquer parte do ciclo, pode adicionar
tarefas, retirá-las, mudar prioridade de
acordo com sua necessidade. Os itens
de maior prioridade, devem ser melhor
detalhados, visando manter a agilidade.
Itens mais abaixo na lista de prioridade,
não precisam estar tão detalhados, visto
que ainda não entrarão na iteração.
Sprint Backlog
• É o ‘container’ que recebe todas as
tarefas que foram priorizadas e
estimadas para a iteração corrente;
• Deve estar visível para todos, afim de
manter a transparência e mostrar a
todos o que a equipe está realizando;
Sprint Backlog
• Ao contrário do backlog do produto,
este não é dinâmico. As tarefas que
foram alocadas para uma sprint não
podem ser retiradas, adicionadas ou
trocadas;
• O sprint backlog deve ser atualizado a
medida que as tarefas forem sendo
concluídas, para que toda a equipe
possa ver o andamento dos trabalhos.
Gráfico Burndown
• Tem por objetivo manter transparente o
progresso da equipe. Demonstrando a
“queima” das tarefas pelo tempo.
• Começa no topo, indicando o total de
pontos de esforço da sprint, e vai
descendo com o passar do tempo (e da
realização das tarefas).
Definição de Pronto
• Esta definição deve ser válida para toda
a equipe;
• O que o time define como pronto? Um
código que foi escrito? Escrito e
testado?
Escrito,
testado
e
documentado?;
• Resumindo, se alguém disser que o
trabalho está Pronto, todos do time
devem saber o que Pronto significa;
Finalizando
“Papéis, artefatos, eventos e regras do Scrum são imutáveis e
embora seja possível implementar somente partes do Scrum, o
resultado não é Scrum. Scrum existe somente na sua totalidade,
funcionando bem como um container para outras técnicas,
metodologias e práticas.”
Tá Safo?
Obrigado!
brenobcampos@gmail.com

http://www.linkedin.com/in/brenobcampos

http://www.coyoti.com.br/blog
Fontes:

http://www.scrum.org/Scrum-Guides
http://manifestoagil.com.br/
http://coyoti.com.br/blog/scrum-para-iniciantes-parte-1-de-2

Mais conteúdo relacionado

Mais procurados

Introdução a Modelagem
Introdução a ModelagemIntrodução a Modelagem
Introdução a Modelagem
Rodrigo Branas
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
Achiles Camilo
 
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
Roberto Brandini
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Neubio Ferreira
 
Montagem de equipes de software
Montagem de equipes de softwareMontagem de equipes de software
Montagem de equipes de software
Evaldo Barbosa
 

Mais procurados (20)

Framework JGenesis
Framework JGenesisFramework JGenesis
Framework JGenesis
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Usabilidade aplicada a dispositivos móveis
Usabilidade aplicada a dispositivos móveisUsabilidade aplicada a dispositivos móveis
Usabilidade aplicada a dispositivos móveis
 
Métodos Ágeis - Manifesto Ágil, Scrum e XP
Métodos Ágeis - Manifesto Ágil, Scrum e XPMétodos Ágeis - Manifesto Ágil, Scrum e XP
Métodos Ágeis - Manifesto Ágil, Scrum e XP
 
Métricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareMétricas Em Fabricas De Software
Métricas Em Fabricas De Software
 
Introdução a Modelagem
Introdução a ModelagemIntrodução a Modelagem
Introdução a Modelagem
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Lean e a Engenharia de Software
Lean e a Engenharia de SoftwareLean e a Engenharia de Software
Lean e a Engenharia de Software
 
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
 
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
 
Facetas do desenvolvedor agil
Facetas do desenvolvedor agilFacetas do desenvolvedor agil
Facetas do desenvolvedor agil
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
Montagem de equipes de software
Montagem de equipes de softwareMontagem de equipes de software
Montagem de equipes de software
 
[MTC 2021] Continuous quality, desafios da melhorias contínua e entrega com q...
[MTC 2021] Continuous quality, desafios da melhorias contínua e entrega com q...[MTC 2021] Continuous quality, desafios da melhorias contínua e entrega com q...
[MTC 2021] Continuous quality, desafios da melhorias contínua e entrega com q...
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Extreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumExtreme Programming (XP) e Scrum
Extreme Programming (XP) e Scrum
 
SETIC Scrum & XP
SETIC Scrum & XPSETIC Scrum & XP
SETIC Scrum & XP
 
Apresentação e guerra dos métodos 2.0
Apresentação e guerra dos métodos 2.0Apresentação e guerra dos métodos 2.0
Apresentação e guerra dos métodos 2.0
 

Destaque

Apresentação Poderoso Ruby - tasafoemacao
Apresentação Poderoso Ruby - tasafoemacaoApresentação Poderoso Ruby - tasafoemacao
Apresentação Poderoso Ruby - tasafoemacao
pamelagatinho
 
Agilidade em Série - XP - Integração Contínua
Agilidade em Série - XP - Integração ContínuaAgilidade em Série - XP - Integração Contínua
Agilidade em Série - XP - Integração Contínua
Comunidade Tá safo!
 
Empreendendo em comunidades
Empreendendo em comunidadesEmpreendendo em comunidades
Empreendendo em comunidades
Jaime Schettini
 

Destaque (14)

Software Livre: ser, pensar e agir
Software Livre: ser, pensar e agirSoftware Livre: ser, pensar e agir
Software Livre: ser, pensar e agir
 
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
 
Visão Ágil Academic Meeting / TaSAFO em fatos e fotos
Visão Ágil Academic Meeting / TaSAFO em fatos e fotosVisão Ágil Academic Meeting / TaSAFO em fatos e fotos
Visão Ágil Academic Meeting / TaSAFO em fatos e fotos
 
Tá safo em ação refatorada
Tá safo em ação refatoradaTá safo em ação refatorada
Tá safo em ação refatorada
 
Pequenos dispositivos grandes negócio$
Pequenos dispositivos grandes negócio$Pequenos dispositivos grandes negócio$
Pequenos dispositivos grandes negócio$
 
Apresentação Poderoso Ruby - tasafoemacao
Apresentação Poderoso Ruby - tasafoemacaoApresentação Poderoso Ruby - tasafoemacao
Apresentação Poderoso Ruby - tasafoemacao
 
Agora é Android, Tá Safo?
Agora é Android, Tá Safo? Agora é Android, Tá Safo?
Agora é Android, Tá Safo?
 
Tá Safo!?
Tá Safo!?Tá Safo!?
Tá Safo!?
 
Agilidade em Série - XP - Integração Contínua
Agilidade em Série - XP - Integração ContínuaAgilidade em Série - XP - Integração Contínua
Agilidade em Série - XP - Integração Contínua
 
A linguagem Ruby e o framework Rails
A linguagem Ruby e o framework RailsA linguagem Ruby e o framework Rails
A linguagem Ruby e o framework Rails
 
Empreendendo em comunidades
Empreendendo em comunidadesEmpreendendo em comunidades
Empreendendo em comunidades
 
Seja Notável
Seja NotávelSeja Notável
Seja Notável
 
Tá safo em ação
Tá safo em açãoTá safo em ação
Tá safo em ação
 
Ruby and Rails for womens
Ruby and Rails for womensRuby and Rails for womens
Ruby and Rails for womens
 

Semelhante a Enter SCRUM

Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
Marisa Wittmann
 

Semelhante a Enter SCRUM (20)

Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.
 
Xp e Scrum
Xp e ScrumXp e Scrum
Xp e Scrum
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Scrum
ScrumScrum
Scrum
 
Material Workshop Scrum foundation - Fernando Cunha
Material Workshop Scrum foundation -  Fernando CunhaMaterial Workshop Scrum foundation -  Fernando Cunha
Material Workshop Scrum foundation - Fernando Cunha
 
Introdução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com ScrumIntrodução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com Scrum
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
Seja ágil com o Scrum - parte 02
Seja ágil com o Scrum - parte 02Seja ágil com o Scrum - parte 02
Seja ágil com o Scrum - parte 02
 
Metodologia Ágil Scrum
Metodologia Ágil ScrumMetodologia Ágil Scrum
Metodologia Ágil Scrum
 
Palestra : Scrum : A arte de fazer o dobro do trabalho na metade do tempo !
Palestra : Scrum : A arte de fazer o dobro do trabalho na metade do tempo !Palestra : Scrum : A arte de fazer o dobro do trabalho na metade do tempo !
Palestra : Scrum : A arte de fazer o dobro do trabalho na metade do tempo !
 
Scrum Overview
Scrum OverviewScrum Overview
Scrum Overview
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
 
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
 
Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
PDS_SCRUM.pptx
PDS_SCRUM.pptxPDS_SCRUM.pptx
PDS_SCRUM.pptx
 
Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
 
Treinamento - Scrum.pptx
Treinamento - Scrum.pptxTreinamento - Scrum.pptx
Treinamento - Scrum.pptx
 

Enter SCRUM

  • 3. TaSafo.org Quem Somos? Comunidade de profissionais e estudantes de Tecnologia da Informação.
  • 4. TaSafo.org Como ser um Safo? Entre na lista de discussão. Participe dos eventos. Venha pra frente. Compartilhe algo.
  • 5. Quem é Breno Campos? • Bacharel em Sistemas de Informação – UFPa; • Especialista em Gerência de Projetos de Software – UFPa; • CSM – Certified SCRUM Master; • Membro do PMI – SP; • Trabalha a 4 anos com metodologias ágeis, principalmente SCRUM; • Não é desenvolvedor; • Aficionado por Gestão de TI; • Atualmente auxilia na Coordenação de uma Equipe de Desenvolvimento e presta consultoria de Gestão de Projetos;
  • 7. • Intro • Pilares • Papéis • Cerimônias • Artefatos • Definição de Pronto • Considerações Finais
  • 8. MANIFESTO ÁGIL Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.
  • 9. Nossos Valores: • Indivíduos e interação entre eles mais que processos e ferramentas • Software em funcionamento mais que documentação abrangente • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um plano
  • 10. Nossos Princípios: • 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.
  • 11. Nossos Princípios: • 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. • 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.
  • 12. Nossos Princípios: • 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.
  • 13.
  • 14. Os pais da criança Ken Schwaber Jeff Sutherland
  • 16. O SCRUM NÃO É! Ferramenta Técnica Processo
  • 19. Beleza, mas como o SCRUM roda?
  • 22. O SCRUM é sustentado por 3 pilares.
  • 24. Pra quem não entendeu... << Patrícia Pilar
  • 25. Transparência Os aspectos mais significativos do projeto devem estar visíveis para todos os envolvidos. Deixando claro o que está sendo feito, o que ainda será feito, e o que está pronto.
  • 26. Inspeção Os envolvidos devem inspecionar os artefatos gerados, para verificar se o projeto está seguindo de acordo com o planejado, detectando variações de desempenho. Deve-se tomar cuidado com a frequência das inspeções para que não chegue ao ponto de atrapalhar o andamento do desenvolvimento;
  • 27. Baseado nos resultados obtidos da inspeção, a adaptação realiza as alterações necessárias para que o projeto continue seu bom andamento, ou para consertar falhas; Adaptação
  • 28. O SCRUM possui 3 papéis.
  • 29. Equipe de Desenvolvimento • Auto gerenciáveis; • “Sem títulos” definidos; • TODOS são desenvolvedores;
  • 30. Product Owner • • • • Responsável por Maximizar o ROI; Gerencia as demandas; Prioriza as tarefas; Garante que a E.D. entenda as tarefas; • Apenas UMA pessoa;
  • 31. SCRUM Master • Líder Servidor; • Remover impedimentos; • Proteger a equipe;
  • 33. Não delega tarefas; Não define responsabilidades;
  • 35. Objetivos • Criar rotinas; • Diminuir a quantidade de reuniões desnecessárias;
  • 37. Sprint • Principal cerimônia do SCRUM; • Todas as outras estão contidas nela; • Time-Boxing de 1 a 4 semanas; • Durante essa iteração (Sprint), é gerada uma release (uma versão utilizável do produto);
  • 38. Sprint • A Sprint é blindada, o que foi planejado deve ser executado! • A Sprint pode ser cancelada, mas somente o Product Owner tem poder para isso. Seus motivos podem variar, como o cancelamento do projeto, mudança de tecnologia ou outros.
  • 39. Sprint Planning • Reunião onde é Planejado o que será executado na Sprint; • Time-Box: 8 horas para uma sprint de quatro semanas e deve ser proporcional para sprints menores; • O time tenta prever o que ocorrerá durante a sprint (feriados, faltas, etc); • A equipe deve estimar as tarefas priorizadas pelo PO, e alocá-las na sprint, obedecendo a quantidade de esforço estimada.
  • 40. Daily Meeting • Também conhecida como Stand up meeting é feita para sincronizar a equipe, deixar todos a par dos acontecimentos, e dos avanços de cada um; • Time-Box: 15 minutos, o motivo de ser uma “reunião em pé”, é para durar mais do que o necessário;
  • 41. Daily Meeting • Três perguntas: • “O que você fez até aqui?”; • “O que você pretende fazer até a próxima daily meeting?”; • “Quais impedimentos você está tendo?”
  • 42. Sprint Review • Os participantes dela são os integrantes do time Scrum (time de desenvolvimento, SM e PO); • Time-Box: 4 horas para uma sprint de 4 semanas e deve ser proporcional para sprints menores; • O P.O. verifica o que está pronto, e o que não está, é apresentado as tarefas realizadas;
  • 43. Sprint Retrospective • É realizada para que o time possa se inspecionar, encontrar acertos e falhas, e pensar em meios de tentar corrigir o que não saiu como o esperado; • Ocorre entre a Sprint Review e o Sprint Planning; • Time-Box: 3 horas para uma sprint de um mês e deve ser proporcional para sprints menores;
  • 45. Objetivo • Maximizar a transparência das informações.
  • 46. Product Backlog • É o ‘container’ que guarda todas as tarefas definidas pelo PO; • É o PO que mantém o backlog, ou seja, ele inclui tarefas, retira tarefas e as ordena de acordo com suas prioridades; • Um backlog de produto dificilmente está completo, as primeiras iterações estabelecem requisitos iniciais, e com o passar dos ciclos o número de requisitos tende a aumentar;
  • 47. Product Backlog • Vale lembrar, que o backlog de produto é dinâmico, o PO pode alterá-lo em qualquer parte do ciclo, pode adicionar tarefas, retirá-las, mudar prioridade de acordo com sua necessidade. Os itens de maior prioridade, devem ser melhor detalhados, visando manter a agilidade. Itens mais abaixo na lista de prioridade, não precisam estar tão detalhados, visto que ainda não entrarão na iteração.
  • 48. Sprint Backlog • É o ‘container’ que recebe todas as tarefas que foram priorizadas e estimadas para a iteração corrente; • Deve estar visível para todos, afim de manter a transparência e mostrar a todos o que a equipe está realizando;
  • 49. Sprint Backlog • Ao contrário do backlog do produto, este não é dinâmico. As tarefas que foram alocadas para uma sprint não podem ser retiradas, adicionadas ou trocadas; • O sprint backlog deve ser atualizado a medida que as tarefas forem sendo concluídas, para que toda a equipe possa ver o andamento dos trabalhos.
  • 50. Gráfico Burndown • Tem por objetivo manter transparente o progresso da equipe. Demonstrando a “queima” das tarefas pelo tempo. • Começa no topo, indicando o total de pontos de esforço da sprint, e vai descendo com o passar do tempo (e da realização das tarefas).
  • 51. Definição de Pronto • Esta definição deve ser válida para toda a equipe; • O que o time define como pronto? Um código que foi escrito? Escrito e testado? Escrito, testado e documentado?; • Resumindo, se alguém disser que o trabalho está Pronto, todos do time devem saber o que Pronto significa;
  • 52. Finalizando “Papéis, artefatos, eventos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas.”