1.
SCRUM
PRINCE2
PMBOK
XP
FDD
DSDM
O que é Scrum
Scrum e o manifesto ágil

2.
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.”

3.
 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

4.
 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

5.
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.

6.
Estrutura básica
Uma visão geral

7.
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.

8.
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!

9.
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.

10.
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!

11.
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.

12.
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!

13.
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.

14.
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.

15.
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.

16.
DevOps
DevOps e Scrum

17.
Valeu galera do Face!
Até a próxima.

18.
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?

19.
Obrigado
Gustavo Sobral
gustavo.sobral@elumini.com.br
55 21 3861-2719