SlideShare uma empresa Scribd logo
1 de 20
SCRUM
PRINCE2
PMBOK
XP
FDD
DSDM
O que é Scrum
Scrum e o manifesto ágil
O manifesto ágil diz que: Estamos descobrindo maneiras melhores de desenvolver software fazendo-o
nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
 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
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
O que é Scrum
Scrum e o manifesto ágil
“O Scrum é um processo* de desenvolvimento iterativo e incremental para
gerenciamento de projetos e desenvolvimento ágil de qualquer produto, inclusive
software.”
 Scrum privilegia uma “atitude” ágil.
 O PMBok disponibiliza uma série de técnicas e
ferramentas para a gestão.
 E o PRINCE2 se baseia num processo consistente e
detalhado.
 O ideal é extrair o melhor de cada um adaptado a sua
cultura corporativa.
O que é Scrum
Scrum e outras metodologias de gerenciamento
 Garante o ROI (Retorno do Investimento)
 Defensor dos interesses do cliente
 Define os requisitos de negócio
 Remove os impedimentos do projeto
 Garante o uso do Scrum
 “Blinda” o time de interferências externas
 Define metas para as iterações
 Deve ser auto gerida
 Desenvolve os produtos para os clientes
Papéis e responsabilidades
A integração entre os papéis
Product
Owner
Scrum
Master
Time
Papéis e responsabilidades
Trabalhando juntos, a equipe inteira ganha
 Equipes multidisciplinares, porém todos
responsáveis pela entrega.
 Um membro não faz “o seu trabalho”, mas sim todo
o possível para atingir a meta.
 A chave é quebrar os silos e melindres que o
conhecimento provoca.
Estrutura básica
Uma visão geral
Estrutura básica
Product backlog e o conceito de pronto
 O product backlog é uma lista de necessidades do cliente
atualizada durante todo o projeto.
 Podem ser colocados em forma de requisitos, casos de uso
ou user stories.
 Deve ser priorizado pelo Product Owner em função do
ganho para o negócio.
 Deve-se sempre fazer o questionamento: “O produto
estará pronto quando...”
 É muito importante que o conceito de pronto seja algo
tangível e observável.
Estrutura básica
Planejamento da sprint e Sprint Backlog
 As sprints deve ter tamanhos fixos (2 a 4 semanas) para dar
ritmo as entregas.
 Cada sprint deve ter uma meta que represente um desejo do
cliente.
 O objetivo é entregar constantemente algo de valor real ao
cliente.
 Um Sprint Backlog é uma lista de atividades para se
entregar os produtos da sprint.
 O uso de Kanban é muito bem vindo aqui!
Estrutura básica
As reuniões diárias são essenciais
 O objetivo das reuniões é verificar o que foi feito e
distribuir o que deverá ser feito.
 Deve ser curta (15 min), direta e com todo o time,
tendo preferencialmente um mediador.
 Os impedimentos devem ser apontados, no entanto
tratados após a reunião.
 As saídas destas reuniões devem atualizar o Sprint
Backlog.
Tratando as mudanças
Acredite, mudanças fazem parte do jogo
 Mudanças em projetos acontecem e muitas vezes traduzem a evolução da visão.
 No entanto, elas não devem interferir na sprint em andamento, mas no futuro do projeto.
 Promover mudanças no meio da sprint, descompromete e desmotiva.
 Mudanças devem entrar no Product Backlog e serem priorizadas como tal.
 Não confunda mudança com detalhamento!
Finalmente as entregas
Revisão e retrospectiva da sprint
 A revisão é a apresentação do resultado da sprint para os clientes.
 Todos os envolvidos participam.
 Uma consequência comum destas reuniões é a atualização do Product
Backlog.
 Também podem acontecer mudanças no time, fechamentos de release
ou a própria conclusão do projeto.
 As retrospectivas são reuniões do time com o objetivo de avaliar o
processo e melhorá-lo.
 O princípio é de inspeção e adaptação.
Finalmente as entregas
Partindo das releases para alcançar o ROI
 Uma release é uma nova versão do produto.
 O Product Owner deve definir a sua publicação.
 A release não tem tamanho fixo como a sprint.
 Muitos projetos têm apenas uma release.
 Quando houver mais de uma release, deve-se atentar para
a gerência de configuração.
 Comemore, seu time venceu!
Além do Scrum
User Stories para decompor requisitos
 São descrições simples de uma funcionalidade pelo ponto de vista do
usuário.
 Casos de Uso seguem uma narrativa impessoal entre o usuário e o sistema.
 User Stories focam nos objetivos do usuário e como o sistema alcança esses
objetivos.
 User Stories fracionam os requisitos para que seja possível estimar o esforço
de desenvolvimento.
 Deve ser pequena, independente, valorosa, negociável, testável, e
estimável.
Além do Scrum
Usando Kanbam com Scrum
 Kanban é uma palavra de origem japonesa que significa
literalmente registro ou placa visível.
 Para projetos de software, normalmente é usado um
quadro dividido em estados, onde se movimentam os post-
its com produtos ou atividades.
 Deve estar acessível e disponível para toda a equipe
durante todo o projeto.
 Cada projeto pode implementar o uso de Kanban da forma
que mais lhe convir.
Além do Scrum
Estimativas usando Planning Poker
 Técnica que se baseia na experiência da equipe.
 Usa-se um baralho com a sequência de Fibonacci, pois quanto
maior a estimativa, mais incerta ela é.
 O primeiro passo é eleger o produto de mais rápido
desenvolvimento e designá-lo como número 2.
 A partir daí, o time aposta em cada produto usando como referência
o número 2 eleito.
 O time deve discutir as diferenças nas apostas até que haja o
alinhamento total do entendimento e estimativa.
 Além de eficiente, é divertido.
DevOps
DevOps e Scrum
Valeu galera do Face!
Até a próxima.
Vamos as apostas
Um exercício usando Planning Poker
 O desafio é estimar o tempo de trajeto de três destinos usando um
automóvel comum.
 Nossas viagens começam no Rio de Janeiro.
 O primeiro destino é Assunção no Paraguai.
 O segundo destino é Campo Grande no Mato Grosso do Sul.
 O terceiro destino é La Paz na Bolívia.
Agora quem pode acertar o tempo até La Paz, segundo o Google?
Obrigado
Gustavo Sobral
gustavo.sobral@elumini.com.br
55 21 3861-2719

Mais conteúdo relacionado

Mais procurados

Leading agile teams - Advanced Scrum Master
Leading agile teams - Advanced Scrum MasterLeading agile teams - Advanced Scrum Master
Leading agile teams - Advanced Scrum MasterIlan Kirschenbaum
 
How to be a great scrum master
How to be a great scrum masterHow to be a great scrum master
How to be a great scrum masterDaniel Shupp
 
Scrum - Conceitos, Práticas e Experiências - Manoel Pimentel
Scrum - Conceitos, Práticas e Experiências - Manoel PimentelScrum - Conceitos, Práticas e Experiências - Manoel Pimentel
Scrum - Conceitos, Práticas e Experiências - Manoel PimentelManoel Pimentel Medeiros
 
Agile Methodology (scrum)
Agile Methodology (scrum)Agile Methodology (scrum)
Agile Methodology (scrum)Manoj Ellappan
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)CollectiveKnowledge
 
The Daily Scrum (The Scrum Events)
The Daily Scrum (The Scrum Events)The Daily Scrum (The Scrum Events)
The Daily Scrum (The Scrum Events)George Psistakis
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutosSerge Rehem
 
Agile Project Management with Scrum
Agile Project Management with ScrumAgile Project Management with Scrum
Agile Project Management with ScrumAditya Raj
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumMindMasterBrasil
 
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014
Scrum Master Role and Responsibilities in Agile Environment  - AMECSE 2014 Scrum Master Role and Responsibilities in Agile Environment  - AMECSE 2014
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014 Ahmed Hammad
 

Mais procurados (20)

Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutos
 
Leading agile teams - Advanced Scrum Master
Leading agile teams - Advanced Scrum MasterLeading agile teams - Advanced Scrum Master
Leading agile teams - Advanced Scrum Master
 
Scrum - evolução contínua
Scrum - evolução contínuaScrum - evolução contínua
Scrum - evolução contínua
 
How to be a great scrum master
How to be a great scrum masterHow to be a great scrum master
How to be a great scrum master
 
Scrum
ScrumScrum
Scrum
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
 
Metodologia SCRUM
Metodologia SCRUMMetodologia SCRUM
Metodologia SCRUM
 
Scrum - Conceitos, Práticas e Experiências - Manoel Pimentel
Scrum - Conceitos, Práticas e Experiências - Manoel PimentelScrum - Conceitos, Práticas e Experiências - Manoel Pimentel
Scrum - Conceitos, Práticas e Experiências - Manoel Pimentel
 
Agile Methodology (scrum)
Agile Methodology (scrum)Agile Methodology (scrum)
Agile Methodology (scrum)
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
 
The Daily Scrum (The Scrum Events)
The Daily Scrum (The Scrum Events)The Daily Scrum (The Scrum Events)
The Daily Scrum (The Scrum Events)
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutos
 
Scrum
ScrumScrum
Scrum
 
Scrum 101
Scrum 101 Scrum 101
Scrum 101
 
Scrum
ScrumScrum
Scrum
 
Agile Project Management with Scrum
Agile Project Management with ScrumAgile Project Management with Scrum
Agile Project Management with Scrum
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do Scrum
 
Scrum for Beginners
Scrum for BeginnersScrum for Beginners
Scrum for Beginners
 
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014
Scrum Master Role and Responsibilities in Agile Environment  - AMECSE 2014 Scrum Master Role and Responsibilities in Agile Environment  - AMECSE 2014
Scrum Master Role and Responsibilities in Agile Environment - AMECSE 2014
 

Semelhante a Workshop Agilizando Projetos com SCRUM

Semelhante a Workshop Agilizando Projetos com SCRUM (20)

Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Scrum 8
Scrum 8Scrum 8
Scrum 8
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
 
Scrum
ScrumScrum
Scrum
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
SCRUM
SCRUMSCRUM
SCRUM
 
Scrum - Visão Geral
Scrum - Visão GeralScrum - Visão Geral
Scrum - Visão Geral
 
Scrum
ScrumScrum
Scrum
 
Scrum
ScrumScrum
Scrum
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento Ágil
 
Agilidade Com Scrum
Agilidade Com ScrumAgilidade Com Scrum
Agilidade Com Scrum
 
Colocando o Scrum em prática
Colocando o Scrum em práticaColocando o Scrum em prática
Colocando o Scrum em prática
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Scrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempoScrum - Faça o dobro do trabalho na metade do tempo
Scrum - Faça o dobro do trabalho na metade do tempo
 
PDS_SCRUM.pptx
PDS_SCRUM.pptxPDS_SCRUM.pptx
PDS_SCRUM.pptx
 
Scrum
ScrumScrum
Scrum
 
Scrum agil
Scrum agilScrum agil
Scrum agil
 

Workshop Agilizando Projetos com SCRUM

  • 1.
  • 2. SCRUM PRINCE2 PMBOK XP FDD DSDM O que é Scrum Scrum e o manifesto ágil
  • 3. O manifesto ágil diz que: Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:  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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. O que é Scrum Scrum e o manifesto ágil “O Scrum é um processo* de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de qualquer produto, inclusive software.”
  • 4.  Scrum privilegia uma “atitude” ágil.  O PMBok disponibiliza uma série de técnicas e ferramentas para a gestão.  E o PRINCE2 se baseia num processo consistente e detalhado.  O ideal é extrair o melhor de cada um adaptado a sua cultura corporativa. O que é Scrum Scrum e outras metodologias de gerenciamento
  • 5.  Garante o ROI (Retorno do Investimento)  Defensor dos interesses do cliente  Define os requisitos de negócio  Remove os impedimentos do projeto  Garante o uso do Scrum  “Blinda” o time de interferências externas  Define metas para as iterações  Deve ser auto gerida  Desenvolve os produtos para os clientes Papéis e responsabilidades A integração entre os papéis Product Owner Scrum Master Time
  • 6. Papéis e responsabilidades Trabalhando juntos, a equipe inteira ganha  Equipes multidisciplinares, porém todos responsáveis pela entrega.  Um membro não faz “o seu trabalho”, mas sim todo o possível para atingir a meta.  A chave é quebrar os silos e melindres que o conhecimento provoca.
  • 8. Estrutura básica Product backlog e o conceito de pronto  O product backlog é uma lista de necessidades do cliente atualizada durante todo o projeto.  Podem ser colocados em forma de requisitos, casos de uso ou user stories.  Deve ser priorizado pelo Product Owner em função do ganho para o negócio.  Deve-se sempre fazer o questionamento: “O produto estará pronto quando...”  É muito importante que o conceito de pronto seja algo tangível e observável.
  • 9. Estrutura básica Planejamento da sprint e Sprint Backlog  As sprints deve ter tamanhos fixos (2 a 4 semanas) para dar ritmo as entregas.  Cada sprint deve ter uma meta que represente um desejo do cliente.  O objetivo é entregar constantemente algo de valor real ao cliente.  Um Sprint Backlog é uma lista de atividades para se entregar os produtos da sprint.  O uso de Kanban é muito bem vindo aqui!
  • 10. Estrutura básica As reuniões diárias são essenciais  O objetivo das reuniões é verificar o que foi feito e distribuir o que deverá ser feito.  Deve ser curta (15 min), direta e com todo o time, tendo preferencialmente um mediador.  Os impedimentos devem ser apontados, no entanto tratados após a reunião.  As saídas destas reuniões devem atualizar o Sprint Backlog.
  • 11. Tratando as mudanças Acredite, mudanças fazem parte do jogo  Mudanças em projetos acontecem e muitas vezes traduzem a evolução da visão.  No entanto, elas não devem interferir na sprint em andamento, mas no futuro do projeto.  Promover mudanças no meio da sprint, descompromete e desmotiva.  Mudanças devem entrar no Product Backlog e serem priorizadas como tal.  Não confunda mudança com detalhamento!
  • 12. Finalmente as entregas Revisão e retrospectiva da sprint  A revisão é a apresentação do resultado da sprint para os clientes.  Todos os envolvidos participam.  Uma consequência comum destas reuniões é a atualização do Product Backlog.  Também podem acontecer mudanças no time, fechamentos de release ou a própria conclusão do projeto.  As retrospectivas são reuniões do time com o objetivo de avaliar o processo e melhorá-lo.  O princípio é de inspeção e adaptação.
  • 13. Finalmente as entregas Partindo das releases para alcançar o ROI  Uma release é uma nova versão do produto.  O Product Owner deve definir a sua publicação.  A release não tem tamanho fixo como a sprint.  Muitos projetos têm apenas uma release.  Quando houver mais de uma release, deve-se atentar para a gerência de configuração.  Comemore, seu time venceu!
  • 14. Além do Scrum User Stories para decompor requisitos  São descrições simples de uma funcionalidade pelo ponto de vista do usuário.  Casos de Uso seguem uma narrativa impessoal entre o usuário e o sistema.  User Stories focam nos objetivos do usuário e como o sistema alcança esses objetivos.  User Stories fracionam os requisitos para que seja possível estimar o esforço de desenvolvimento.  Deve ser pequena, independente, valorosa, negociável, testável, e estimável.
  • 15. Além do Scrum Usando Kanbam com Scrum  Kanban é uma palavra de origem japonesa que significa literalmente registro ou placa visível.  Para projetos de software, normalmente é usado um quadro dividido em estados, onde se movimentam os post- its com produtos ou atividades.  Deve estar acessível e disponível para toda a equipe durante todo o projeto.  Cada projeto pode implementar o uso de Kanban da forma que mais lhe convir.
  • 16. Além do Scrum Estimativas usando Planning Poker  Técnica que se baseia na experiência da equipe.  Usa-se um baralho com a sequência de Fibonacci, pois quanto maior a estimativa, mais incerta ela é.  O primeiro passo é eleger o produto de mais rápido desenvolvimento e designá-lo como número 2.  A partir daí, o time aposta em cada produto usando como referência o número 2 eleito.  O time deve discutir as diferenças nas apostas até que haja o alinhamento total do entendimento e estimativa.  Além de eficiente, é divertido.
  • 18. Valeu galera do Face! Até a próxima.
  • 19. Vamos as apostas Um exercício usando Planning Poker  O desafio é estimar o tempo de trajeto de três destinos usando um automóvel comum.  Nossas viagens começam no Rio de Janeiro.  O primeiro destino é Assunção no Paraguai.  O segundo destino é Campo Grande no Mato Grosso do Sul.  O terceiro destino é La Paz na Bolívia. Agora quem pode acertar o tempo até La Paz, segundo o Google?