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

Workshop Agilizando Projetos com SCRUM

  • 2.
    SCRUM PRINCE2 PMBOK XP FDD DSDM O que éScrum Scrum e o manifesto ágil
  • 3.
    O manifesto ágildiz 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 privilegiauma “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 oROI (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 Trabalhandojuntos, 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.
  • 7.
  • 8.
    Estrutura básica Product backloge 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 dasprint 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õesdiá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ãoe 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 Partindodas 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 UserStories 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 UsandoKanbam 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 Estimativasusando 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.
  • 17.
  • 18.
    Valeu galera doFace! Até a próxima.
  • 19.
    Vamos as apostas Umexercí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?
  • 20.