Treinamento Agile Scrum Foundation - Trainning 2021

Agile Scrum Foundation - ASF
1
Público Alvo
 Pessoas que desejam estar atualizadas;
 Gerente de projetos;
 Profissionais de TI;
 Desenvolvedores de Software;
 Gerente de Serviços de TI;
 Gerente de Negócio.
2
Pré - Requisitos
Não há pré-requisito para realizar o curso e a

prova de certificação.
Entretanto para melhor aproveitamento do curso

é importante que tenha conhecimento básico
sobre TI e gestão de projetos.
3
Sobre o Exame
Duração: 90 minutos
 Questões múltipla escolha
com 4 opções de resposta,
somente uma correta
 Acerto de 26 questões
Questões: 40
 Sem consulta
 Não é permitido o uso de nenhum

equipamento eletrônico
Aprovação: 65% da prova
4
Objetivos do Curso
TEORIA e MINDSET
Apresentar os conceitos básicos das práticas ágeis e fixa-los com dinâmicas
PRATICA E FERRAMENTAS
Apresentar os conceitos de agilidade, alinhando a técnica com a sua
aplicação.
ESCALANDO
Introduzir a prática de gestão global ágil com múltiplas equipes e gestores
com a visão de programa e portfólio.
5
Scrum Guide
Desenvolvido e mantido pelos criadores do Scrum, Ken Schwaber e Jeff Sutherland, o Guia
do Scrum .
Esse material sofre algumas atualizações de tempos em tempos para manter em dia as
inovações. A última ocorreu em 2020.
No documento, as regras e o funcionamento do Scrum estão descritos de forma bem concisa

e objetiva.
6
Agenda
Módulo 1 – Agile Mind Set & Chaos Report

Módulo 2 – O Scrum
Módulo 3 – Papéis no Scrum
Módulo 4 – Artefatos do Scrum
Módulo 5 – Eventos
Módulo 6 – Gestão Financeira
Módulo 7 – Visibilidade & Previsibilidade
Módulo 8 – Escalando Projetos Ágeis
Módulo 9 – Incorporando o Scrum
7
Módulo 1 – Agile Mind Set & Chaos Report
8
Módulo 1 - O que é o Pensamento Ágil ?
Conjunto de técnicas e práticas para gestão de projetos que oferece

mais rapidez, eficiência e flexibilidade.
Tornando os processos mais simples, dinâmicos e iterativos, da

concepção da ideia até o produto final.
De acordo com a pesquisa PMI’s Pulse of the Profession 2018,

realizada pelo Instituto PMI, 73% das organizações globais já utilizam
a agilidade para gerenciar seus projetos.
Módulo 1 - Agile Mind Set - Características
 Desenvolvimento incremental, ou seja, de melhoria contínua;

 Cooperação entre equipe e cliente (ciclo de feedback constante);
 Entregas rápidas e de alta qualidade;
 Flexibilidade de escopo do projeto;
 Criação de valor progressiva e de acordo com as necessidades do
cliente;
 Adaptabilidade às mudanças e alto nível de inovação
Módulo 1 - Porque Adotar o Agile?
Módulo 1 - Áreas de Conhecimento
Módulo 1 - Chaos Report – Sucesso de Projetos
Standish Group 2018
13
Módulo 1 - Chaos Report – Sucesso de Projetos
Standish Group 2019
14
Módulo 1 – Porque o Agile falha?
Fonte: VersionOne, Agile Annual Report, 2020
15
Módulo 2 – O Scrum
16
Módulo 2 – Metodologia vs Framework
Metodologia: é um conjunto de métodos, padrões e regras

que devem ser seguidos.
“Framework” ou Boas Práticas: é uma estrutura, um conjunto de

conceitos e técnicas, totalmente adaptável.
17
Módulo 2 – Metodologia ou Framework?
Você diria que o “Scrum” é uma a metodologia?
“O termo “ágil” data de uma reunião de 2001, na qual eu e 16

...
outros líderes de desenvolvimento de software escrevemos o que
se tornou conhecido como “Manifesto Ágil”. Nele declaramos
os seguintes valores: pessoas em vez de processos; produtos que
realmente funcionem em vez de documentação dizendo como o
produto deveria funcionar; trabalhar com os clientes
em vez de negociar com eles; responder às mudanças em vez de
seguir um plano.
Scrum é a estrutura que eu construí para colocar esses valores em

prática. Não existe uma metodologia.”
Jeff Sutherland, cocriador do SCRUM, no seu Livro Scrum - a arte de fazer

o dobro do trabalho na metade do tempo, pg.15
18
Módulo 2 – Metodologia ou Framework?
Então, um Framework ou boas práticas podem fazer parte de

uma metodologia?
Sim! As práticas ágeis são mais um hábito do que um processo.

Logo, adaptável e flexível em qualquer metodologia.
19
Módulo 2 – O que é o Scrum?
É um processo interativo e incremental para o desenvolvimento de

qualquer produto e desenvolvimento de qualquer projeto/solução;
É mais um framework que uma metodologia, mais atitute que um processo;
20
Módulo 2 – Para que é usado?
• Software comercial • Video games

• Desenvolvimento interno • Sistemas para suporte à vida
• Desenvolvimento contratado (terceirização) • Sistemas para controle de satélites
• Projetos de preço fixo • Websites
• Aplicações Financeiras • Software para handhelds
• Aplicações certificadas pela iso 9001 • Telefones celulares
• Sistemas embarcados • Aplicações para redes
• Sistemas disponíveis 24x7 • Aplicações de ISV (Independent Software
Vendors)
• Pesquisa de inovação
• Algumas das maiores aplicações em
produção
21
Módulo 2 – Tradicional x Agile
Velocidade: É o ponto de diferença entre metodologia ágeis vs metodologias tradicionais
(Cascata).
A metodologia tradicional, ou metodologia cascata, é baseada em sequência predefinida de

etapas, como análise de requisitos, desenvolvimento, testes, produção e manutenção.
Nessa abordagem, os projetos são bastante demorados, e o princípio é prever quais serão os
resultados na entrega final.
Já na metodologia ágil, o foco é adaptar ao invés de planejar. Por isso, os projetos são divididos
em pequenas entregas denominada iterações.
Cada iteração é um “miniprojeto”, ou seja, inclui todas as etapas citadas em um ciclo rápido e
eficiente, que gera uma entrega parcial.
Assim, o cliente consegue ver resultados rapidamente e dar seu feedback durante todo o
processo – daí a característica incremental do método.
Conforme os ciclos se repetem, o produto é aprimorado continuamente de modo experimental,

podendo ser testado a cada funcionalidade. 22
Adaptabilidade: Na metodologia ágil, projetos estão sempre abertos às mudanças, por mais
impactantes que sejam.
Por outro lado, no método tradicional, procuramos minimizar as alterações para não comprometer
o planejamento.
Por fim, a participação dos clientes e colaboradores no processo é mais um diferencial da cultura
ágil.
Isso porque as entregas fragmentadas permitem que todos avaliem o progresso do produto ou
serviço, evoluindo a criação em conjunto.
23
O escopo do projeto, no método tradicional, é No Ágil, o escopo do projeto é realizado por partes, em
realizado no começo já determinando o que entregas incrementais onde permite o cliente a participar
será desenvolvido do inicio ao fim de todo o processo possibilitando pequenas entregas do
produto.
24
Módulo 2 – Valores do Scrum
Comprometimento Coragem Foco Abertura Respeito
Cada integrante de um projeto Scrum se compromete com o trabalho que

se responsabilizou em fazer. Se comprometer é se envolver e não
abandonar o trabalho pela metade ou entregar sem qualidade.
25
Os integrantes de um projeto Scrum (SM + PO + TIME) precisam ter

coragem para fazer a coisa certa e trabalharem juntos removendo
impedimentos, buscando soluções.
26
Os integrantes de um projeto Scrum precisam focar no trabalho durante o

Sprint e nas metas desiguinadas pela empresa. Time disperso perde
produtividade e não alcança os objetivos.
27
Poder ser franco, expor as ideias e propostas mesmo que elas não sejam
aproveitadas. Promover momentos de debates, discussões, ouvir opiniões e
sugestões para gerar novas práticas.
28
Respeitar uns aos outros é o primeiro passo para manter a colaboração, a

integração e bom ambiente de trabalho.
29
Módulo 2 – Estabelecendo a Cultura Agil
Alinhamento entre envolvidos;

Linguagem comum;
Transparência Clareza nas execuções e aceitação;
Definição de Pronto comum entre executores e demandantes
Inspecionar artefatos produzidos;

Inspeção Certificar que as produção estão em conformidade com o solicitado;
Validar o conceito de pronto em todos os itens terminados;
Analisar o grau de impacto de possíveis desvios dentro do plano;

Adaptação Implementar ações de contramedidas com foco em manter a entrega de valor
real ao demandante;
30
Módulo 2 – A cultura seria melhor recebida se...
1. Recebesse entregas periódicas agregando valor ao negócio

2. Pudesse flexibilizar os requisitos de acordo com a necessidade do projeto
3. Verificasse software funcionando em poucas semanas
4. Tivesse pessoas de negócio e desenvolvedores trabalhando em conjunto
5. Construísse projetos em torno de indivíduos motivados
6. Considerasse comunicação verbal o meio de comunicação mais eficiente
7. Medisse o progresso do projeto com o Software funcionando
8. Tivesse um time comprometido e não só envolvido com o sucesso
9. Não abrisse mão da excelência técnica e bom design dentro do tempo do projeto
10. Mantivesse a simplicidade como “pedra fundamental”
11. Tivesse equipes auto-gerenciaveis
12. Trabalhasse em conjunto com o time para a melhoria continua
31
Módulo 2 – A cultura seria melhor recebida se...
1. Recebesse entregas periódicas agregando valor ao negócio

2. Pudesse flexibilizar os requisitos de acordo com a necessidade do projeto
3. Verificasse software funcionando em poucas semanas
12
4. Tivesse pessoas de negócio e desenvolvedores trabalhando em conjunto
Princípios
5. Construísse projetos em torno de indivíduos motivados Ágeis
6. Considerasse comunicação verbal o meio de comunicação mais eficiente
7. Medisse o progresso do projeto com o Software funcionando
8. Tivesse um time comprometido e não só envolvido com o sucesso
9. Não abrisse mão da excelência técnica e bom design dentro do tempo do projeto
10. Mantivesse a simplicidade como “pedra fundamental”
11. Tivesse equipes auto-gerenciaveis
12. Trabalhasse em conjunto com o time para melhoria continua
32
Módulo 2 – Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas

Produto 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."
http://agilemanifesto.org
33
Módulo 2 – Frameworks Ágeis
Source: VersionOne Annual State of Agil Report, 2019
34
Módulo 3 – Responsabilidades no Scrum
35
36
• Product Owner
Responsável por garantir o ROI (Retorno de Investimento);
Responsável por conhecer as necessidades do(s) cliente(s);
Proxy em ambientes com mais de um cliente;
• ScrumMaster
Responsável por remover os impedimentos do time;
Responsável por garantir o uso de Scrum;
Protege o time de interferências externas;
• Time
Definir metas das iterações;
Auto-gerenciamento;
Produzir produto com qualidade e valor para o cliente;
37
Módulo 3 – Estrutura do Scrum
Product Owner ScrumMaster Equipe
38
• O Product Owner define a Visão e Meta do Produto. Esta Visão é o que representa sua necessidade, é o que deve ser satisfeito ao
fim do projeto;
• Para definir esta Visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos, etc.;
39
• O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog.
40
• O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog;
• O ScrumMaster deve auxiliar o PO na elaboração desta lista.
41
• No início de cada iteração (Sprint) o time deve se reunir para realizar a Planning Meeting;
• Nesta reunião o time realizará o planejamento do que será entregue ao final do ciclo da Sprint (que deve ser de 2 a 4 semanas).
•O plano do que será entregue deve levar em consideração a Meta do Produto e a Meta da Sprint.
42
• Na primeira parte da Planning Meeting o PO deverá: definir a meta da Sprint de acordo com a Meta do Produto e falar para o
time sobre os Itens mais prioritários do Product Backlog;
• O time deve estimar os Itens em tamanho (caso ainda não estejam estimados) e selecionar o que acredita que possa ser feito
durante a Sprint, considerando a definição de pronto alinhado com o PO . Essa lista selecionada chama-se Selected Product
Backlog;
• O facilitador desta reunião é o ScrumMaster.
43
• Na segunda parte da Planning Meeting o time deverá colher mais detalhes dos Itens do Selected Product Backlog e decompô-los em
tarefas, gerando assim o Sprint Backlog;
• Para isso pode ser necessária a ajuda de Especialistas de Domínio;
• Após a decomposição, cada membro do time deve selecionar as tarefas que deseja executar durante a Sprint (sempre negociando com
o time) e estimá-las em horas;
• O facilitador desta reunião é o ScrumMaster.
44
• Durante a execução da Sprint, valem as práticas de engenharia definidas para o projeto;

• O ScrumMaster, através da sua capacidade de liderança e colaboração, facilita o trabalho do time removendo os impedimentos
encontrados e garantindo a boa aplicação do Scrum;
• Durante a Sprint o time pode sentir necessidade de consultar Especialistas de Domínio, ou mesmo o Product Owner;.
45
• Diariamente o time realiza uma reunião de 15 minutos (Daily Meeting) :

Através desta reunião o time ganha visibilidade de como está o caminho para a meta e planeja o dia seguinte de trabalho;
• O ScrumMaster novamente é o facilitador, e deve lembrar-se que a reunião é para o time e não para ele.
46
• Ao final da execução da Sprint deve ser realizada a Review Meeting, reunião que tem como propósito apresentar o que foi feito
para o Product Owner e convidados;
• O time é quem realiza a apresentação, que deve ser feita no formato de demo;
• Product Owner avalia se a Meta da Sprint foi alcançada e se as entregas seguiram a definição de pronto acordada;
• Product Owner faz anotações que poderão se tranformar em novos Itens para o Product Backlog.
47
• A última cerimônia de um Sprint Scrum é a Retrospectiva;

• Reunião de lições aprendidas, facilitada pelo ScrumMaster, na qual o time deve avaliar: o que foi bom na última Sprint? O que
deve ser melhorado? Quem está no controle?
• Esta reunião representa o espírito de Inspeção-Adaptação dentro do Scrum;
• É uma reunião do time, mas – caso seja de acordo de todos seus membros – o PO também pode participar.
48
Módulo 3 – O Papel do Scrum Master
A maioria dos projetos entregam software a cada 6 a 18 meses.
SCRUM reduz isso a muitas entregas mensais que incrementam

o controle via inspeção e adaptação.
Isto permite a equipe e a organização, maior visibilidade,

expondo problemas e limitações, ou seja, expondo o que está por trás da “janela suja”.
O trabalho do ScrumMaster é priorizar estes problemas e ajudar a organização a superá-los,

gerenciando investimentos e garantindo o seu retorno.
49
Módulo 3 – Um Scrum Master Deve...
 Remover a barreira entre desenvolvimento e cliente

 Ensinar o cliente a maximir o ROI e atingir seus
objetivos através do Scrum
 Melhorar o dia-a-dia dos membros da equipe facilitando
a criatividade e fortalecimento do grupo
 Priorizar os impedimentos e combatê-los
 Auxiliar o Product Owner com o Product Backlog
 Garantir o uso do Scrum
 Facilitar reuniões
50
Módulo 3 – A Vida de um Scrum Master
 Assegure-se que todo mundo está fazendo o que se comprometeu a fazer
 Determine onde Scrum está, comparado com onde poderia estar e atualize seu próprio Product Backlog
 Trabalhe no Product Backlog com o Product Owner
 Zelar pelo bom funcionamento ágil em toda sua essência
51
Módulo 3 – Autoridade do Scrum Master
O Scrum Master por meio de treinamentos, coaching, removendo impedimentos, solução de problemas
poderá fazer que o Scrum seja entendido.
Não é um gerente do Time. Mas é papel do Scrum Master orientar e motivar o time a seguir o Scrum, sem
obrigar a equipe a realizar ações, pois no ágil as equipes são multidisciplinares e auto organizáveis.
Scrum Master tem como característica ser um líder servidor, sem impor nada ao time.
52
Módulo 3 – Atributos de um bom Scrum Master
Responsabilidades:
 Humildade;
 Colaboração;
 Comprometimento;
 Influência;
 Conhecimento.
53
Módulo 3 – Motivando e Desafiando a Equipe
É necessário para o Scrum Master entender a dificuldade da tarefa que o Product Owner repassa
para equipe;
Esse repasse deverá ser realizado sem tom de problematização, ameaça ou de punição. O
Product Owner tem o dever de explicar a importância da tarefa e a importância de cada membro
para a conclusão da tarefa.
54
Módulo 3 – Métodos Tradicionais e Scrum
Em cenários que existem processos tradicionais e o Scrum, é inevitável não ter problemas.
Nesses casos é importante saber quais são as atitudes corretas que um Scrum Master deve ter,
ou ter como amenizar o tamanho dos problemas.
Realizar análise em detalhes;

Não permitir que tenha conflito nos modelos de gestão;
Descobrir qual é o modelo de gestão que mais se encaixa;
Criar pequenos processos em vez de encurtar um grande processo;
Estabelecer uma forma do Scrum que apoie o método tradicional;
Adequar da melhor maneira as práticas ágeis em qualquer que seja o processo.
 Integração contínua
 Testes automatizados
 Refatoração
 Programação em pares
 Desenvolvimento paralelo
55
Módulo 3 – Aprendizagem
Mesmo após a equipe ter estar com pleno entendimento do Scrum, comprometida com os resultados e
diminuir a dependência dos especialistas é importante os membros procurarem novas formas de
aprender e de compartilhar os conhecimentos proativamente.
Algumas aprendizagens ocorre naturalmente outras procuram intencionalmente, se preocupando com o

agora.
Cabe ao Scrum Master incentivar a equipe a procurar esse conhecimento através de:
 A mentalidade da equipe estar pensando sempre em aprender;

 Os membros tem que ter a possibilidade de compartilhar o conhecimento;
 Liderança cooperando mostrando a equipe a importância do aprendizado constante;
 Ter desafios que motivem a equipe a sempre procurar por aprendizagem.
 Ambiente favorável para aprender.
56
Módulo 3 – Um Product Owner deve...
 Definir a visão do produto (product vision);
 Gerenciar o retorno de investimento (ROI);
 Apresentar ao time os requisitos necessários para a entrega do produto;
 Priorizar cada requisito de acordo com seu valor para o negócio/cliente;
 Gerenciar a entrada de novos requisitos e suas priorizações;
 Planejar entregas (releases);
 Atuar como facilitador quando mais de um cliente estiver envolvido no projeto;
 Garantir que Especialistas estejam disponíveis para o time;
 50% do tempo de um product owner deve ser gasto para entender o negócio do cliente
enquanto os outros 50% devem ser gastos passando esse conhecimento para o restante
do time.
57
Módulo 3 – ROADMAP do Produto
Para ter visibilidade e um bom planejamento do produto

ou projeto que se pretende construir.
O Product Owner (Dono do produto) tem por melhor

prática organizar suas idéias em grandes marcos de
entrega, chamadas RELEASES ou LIBERAÇÕES e a
partir disso, coordenar as solicitações para time Scrum.
Para tanto, pode lançar mão de algumas técnicas. Como

Lembrado o Futuro.
58
Módulo 3 – Lembrando o Futuro
Técnica de BRAINSTORMING que buscar analista de forma macro os

principais passos para atingir um objetivo em um ponto no futuro
59
60
Artefatos do Scrum é todo o esforço ou valor proposto que é gerado no projeto.
Método Tradicional Time Scrum
 Não gasta muito tempo na fase de

 Inicialmente é realizado a coleta de
requisitos;
todo os requisitos do projeto;
 Inicialmente levanta os requisitos em
 Aguarda até que toda a
alto nível, e sucessivamente, vai
especificação do produto seja
especificando-os;
feita;
 Tudo que é coletado é documentado
 Considera que todos os aspectos
no artefato Backlog do Produto;
que ainda estão sem definição seja
encontrado.
 Backlog do Produto é a lista dos
requisitos priorizados
61
Módulo 4 – Backlog do Produto
 Dinâmico, pois é permitido adicionar e remover itens, repriorizar conforme a
necessidade do cliente;
 A mudança constante que ocorre no Backlog do Produto faz dele um

artefato vivo, com as evoluções no produto que acontece a cada Sprint;
 O Backlog do Produto nunca será algo completo;
 O Product Owner é o responsável ;
 Importante que pode ocorrer cenários onde existam mais de um Time

Scrum atuando em um mesmo produto, no entanto deverá existir apenas
um Backlog do Produto.
62
Módulo 4 – Características do Backlog
Não é exigido que o Backlog do Produto seja descrito com Estórias de Usuário, no entanto essa prática é comum e
muito incentivada.
É ordenado pelas estórias de maior valor no topo da lista, e as de menor valor por último.
Aconselha-se não gastar muito tempo com as estórias de menor valor, pois é possível que não sejam feitas no futuro.
Uma boa prática utilizada no Backlog é a técnica INVEST, acrônimo: Independent (Independente); Negotiable
(Negociável); Valuable (aquele que gera Valor); Estimable (Estimável); Small (Pequeno); Testable (Testável).
63
Módulo 4 – Características do Backlog
A estimativa dos itens do Backlog do Produto é de responsabilidade do Time de
Desenvolvimento.
As outras atividades fica na responsabilidade do Product Owner que são:

 Dono do Backlog do Produto;
 Elaborar os itens;
 Priorizar os itens que geram valor;
 Assegurar que os itens que compõe o Backlog estejam claros e objetivos para o
time;
64
Módulo 4 – Nivel certo de priorização
65
Módulo 4 – Funcionamento do Product Backlog
66
67
IDENTIFICAÇÃO
Comece batizando o produto a ser desenvolvido.
PROBLEMAS
Formule uma dinâmica que auxile as partes interessadas a expor os
principais problemas existentes que se esperam ser solucionados com
o produto. Descreva cada um em post-its.
EXPECTATIVAS
Alinhe as expectativas das partes interessadas. Importante que cada
problema se relacione com uma expectiva.
PARTES INTERESSADAS
Comece a personificar os usuários, papéis e responsáveis envolvidos
no negócio. Dê um nome/apelidos, defina suas principais atividades
e/ou objetivos no contexto do negócio que o produto pretende atuar,
alinhando as expectativas do persona com as do passo anterior.
68
AREAS DE NEGÓCIO
Agrupe as personas conforme área de negócio que atuam. Isso auxilia
o PO a ter uma visão de impacto no negócio e por consequência a
começar a priorizar.
ATIVIDADES DE NEGÓCIO
Descreva as atividades de negócio necessárias para cada área listada
anteriormente, associando a parte interessada já identificada.
Detecte cada atividade por sua sequência cronológica, mapeando da

esquerda para a direita, com uma breve descrição e alinhando os
problemas (pontos de melhorias) e as expectativas (pontos que se
espera chegar)
FUNCIONALIDADES
Comece a estratificar as atividades de negócio, gerando as funcionalidades.
69
Módulo 4 – Engenharia do Product Backlog
70
Módulo 4 - Priorizando com Moscow
Benefícios de Custos de Os itens que contemplam o Backlog do Produto tem

Desenvolvimento e
Negócio Manutenção valor ao negócio, que pode ter um cálculo voltado para
termos financeiros ou simples por meio do método
A Estratégia da Organização que irá indicar quais serão os MoSCoW ou outros métodos
benefícios de Negócio
 ROI (Return On Investiment);

 Taxa Interna de Retorno (IRR - Internal Rate of Return);
 Payback Simples e Descontado;
 VPL: Valor Presente Líquido (NVP - Net Present Value);
 Retorno sobre o Investimento (ROI - Return on Investment);
 Custo Total de Propriedade (TCO - Total Cost of Ownership).
71
Módulo 4 – Workshop de Estórias
72
Módulo 4 – Workshop de Estórias
• Workshop de Estórias são reuniões que

Incluem colaboradores, usuários, cliente e product owner;
• Durante este workshop os participantes escrevem a quantidade de

estórias que
conseguirem;
• Prioridades não são associadas;
• Bons workshops combinam os melhores elementos de brainstorming

e prototipação de desenho;
73
Módulo 4 – Estórias
Independente
Negociável
Valiosa para usuários e cliente
INVEST
Estimável
Small (pequena)
Testável
74
Quem?
Como um <PERFIL> eu posso/gostaria/devo
<FUNCTION> para <VALOR AO NEGÓCIO>
O que?
Como um INSTRUTOR eu devo APONTAR A LISTA
DE PRESENÇA DOS ALUNOS para MANTER AS
INFORMAÇÕES DO TREINAMENTO ATUALIZADAS
Por que? 75
Módulo 4 – Workshop de Estórias (Exemplo)
Sua empresa é uma fabrica especializada em construção de aeronaves. Seu cliente, a força aérea, por intermédio de
um representante, entrou em contato e solicitou propostas para um novo projeto de aeronave.
A aeronave deve possuir 12 janelas, cabine, o logotipo da empresa de fabricação, recursos para passageiros e
tripulação.
76
Módulo 4 – Workshop de Estórias (Exemplo)
Como um piloto eu posso realizar check-up on-line da Como um passageiro eu posso ter acesso à um tablet para
aeronave para acelerar os procedimentos de decolagem. visualizar as informações que necessito
Como um empresário da aviação eu gostaria de uma aeronave Como um membro da tripulação eu devo ter facilidade de
com maior autonomia de voo para que o tempo em solo fosse locomoção dentro da aeronave para melhor servir aos
menor passageiros
77
Módulo 4 – Condições de Satisfação
Todo projeto nasce com um grupo de objetivos. Sendo assim é importante elaborar critérios para
o atendimento desses objetivos.
No Scrum, isso é realizado de forma colaborativa entre o Product Owner e o Time que devem
encontrar formas para garantir a satisfação do Product Owner.
Para isso, fatores comuns nas condições de satisfação possui:
 Escopo;
 Cronograma;
 Orçamento;
 Qualidade.
Terá situações que todos os fatores acima não será atendido. Nesses casos as condições são
alteradas.
Por esse motivo que o Planejamento de Liberação e as condições são interativos.
A condição de satisfação é definido como um teste de aceitação de alto nível que se tornará
concreta após a estória do usuário estiver completa.
78
Módulo 4 – Observações sobre Estórias
• Uma característica marcante de projetos/serviços baseados em “Estórias”

é que clientes e usuários estão comprometidos no projeto em toda sua
duração;
• “Estórias” devem ser compreensíveis por todos: usuários, cliente e equipe

de desenvolvimento;
• “Estórias” evitam “interpretações” de documentação
79
Módulo 4 – Testes de Aceitação
Uma das melhores formas de se expressar em uma estória alguns dos detalhes discutidos
entre cliente (Product Owner, Especialista de Domínio, ...) é a escrita de Testes de
Aceitação;
• Voo da aeronave entre duas

principais rotas, analisando
Como um empresário da aviação eu combustível gasto x restante deve
gostaria de uma aeronave com ter consumo abaixo de 50%;
maior autonomia de voo para que o
tempo em solo fosse menor • Tempo de recarga (combustível e
mantimentos) da aeronave em solo
deve ser entre 15-20 minutos;
80
Módulo 4 – Testes de Aceitação (Regras)
• Escrever Testes de Aceitação antes de

Iniciar o trabalho ;
• O cliente é quem deve especificar Testes de

Aceitação;
• Teste DEVEM fazer parte do processo;
• Automatização de Testes de Aceitação

• Ex.: Script de Testes
• Alguns tipos de testes

• Teste de Unidade;
• Teste de Usabilidade;
• Teste de Performance;
• Teste de Stress;
81
Módulo 4 – Nem tudo é Estória
ESTORIA
ESTORIA ESTORIA
EPICO
TEMA
TEMA
ESTORIA ESTORIA ESTORIA
ESTORIA ESTORIA ESTORIA ESTORIA
8
Módulo 4 – Dimensionando Estórias
O esforço estimado para os itens do Product Backlog deve ser negociado entre o time e o Product Owner,
sempre praticando o bom senso;
Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum. O Planning Poker é
uma das mais populares, onde, através de cartas com numeração seguindo a tabela de Fibonacci, os membros
do time “sugerem” um tamanho (size) para os requisitos do Product Backlog.
83
Módulo 4 – Planning Poker
Baseado nas explicações do Product Owner sobre o

requisito, os participantes esclarecem suas dúvidas e fazem
a estimativa de acordo com que consideram em seu
entendimento que é alinhado até chegar a um consenso.
84
Módulo 4 – Scrum Poker
85
Módulo 4 – Planning Poker Funciona porque...
... apresenta múltiplas opiniões de especialistas quanto à estimativa de um requisito;
... estimula o dialogo durante as reuniões, e cada membro do time tem a oportunidade de
explicar para todos os outros membros o porque estimou o requisito com aquele tamanho.
Todo este processo gera compartilhamento de conhecimento;
...estudos mostram que estimas feitas em grupo vem sendo mais bem sucedidas que
estimativas individuais;
86
Módulo 4 – Estimativas erradas
Quanto mais o time vai desenvolvendo as estórias, mais velocidade eles ganham.
Em determinadas estimativas o esforço calculado antes não é o que será realmente gasto.
Por isso as estimativas em Pontos por Estória é a maneira mais correta e simples para corrigir,
pois são auto corrigíveis pela aplicação da velocidade.
Em estimativas com Pontos de Estória é apartado as estimativas de esforço com as estimativas de

duração.
87
Módulo 5 – Eventos
88
Módulo 5 – Objetivo dos Eventos
Os Eventos ou Cerimônias Scrum servem para ter uma rotina e para diminuir a necessidade de
reuniões fora da metodologia Scrum.
É importante inserir todos as cerimônias Scrum para manter a transparência e adaptação nos
processos.
Por este motivo cada cerimônia do Scrum ocorre dentro de uma time-box, ou seja, com um tempo
pré-determinado para que aconteça.
O Time-Box não pode ter seu tempo modificado após o inicio de uma Sprint
89
Módulo 5 – Raio - X dos Eventos
EVENTOS SCRUM:
Time Box
90
Módulo 5 – Planejamento
91
Módulo 5 – Reunião de Planejamento
A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em cena no início de
cada Sprint.
Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a participar em
determinados momentos da reunião, desde que agreguem valor à mesma e tenham seu convite aprovado pelo
Product Owner.
Pela prática, percebemos que a duração desta reunião segue a seguinte tabela:
92
Módulo 5 – Planejamento por compromisso
Se compromete; ainda pode fazer mais
Se compromete; mas não

consegue incluir mais nada
Selecionar um requisito do
Ajuste de prioridades Backlog
Pergunte se time se
Finaliza Sprint Planning
compromete
Quebra requisito em estórias

Não se
compromete
Identificar a meta da Sprint
Estimar estórias
Remove o requisito
93
Módulo 5 – Velocidade
• Velocidade é uma medida da produtividade do Time;
• Representa a taxa de trabalho que o Time conseguiu

completar durante um Sprint;
• Serve de guia para o planejamento de Sprints.
• Serve de guia para o planejamento de Releases e progresso do projeto.
94
Módulo 5 – Planejamento por Velocidade
Reunião I Reunião II
Ajuste de prioridades
Selecionar requisitos do
Identificar a meta da Sprint Quebra requisitos em estórias
Backlog
Determinar velocidade
Estimar estórias
95
Módulo 5 – Planejamento da Release
Trata-se de uma reunião de planejamento de alto nível que abrange a

iteração dos Sprints futuros.
Nessa reunião temos visão a longo prazo do que será feito, quais recursos
serão implementados e quando serão concluídas.
Planejamos as entregas que vão ocorrer ao longo do projeto e monitoramos

o progresso do mesmo ( onde estamos e para onde vamos ).
96
Módulo 5 – Planejamento da Release
Continua planejando Releases até que a Visão do produto seja alcançada
Selecionar um tamanho de
Sprint
Determinar as condições de Estimar velocidade

Estimar os Itens do Backlog Selecionar Itens e data do
satisfação
Release
Priorizar Estórias
97
Módulo 5 – Tamanho da Release
O Product Owner é quem possui a visão de qual o período ideal para distribuir uma
nova versão do produto
Observe:
• Não adianta entregar produto tão rapidamente de forma a tornar impossível o

acompanhamento de atualização do cliente
• Um Release deve ser algo integrado e de grande valor para o cliente
98
Módulo 5 – Planejamento em Camadas
99
Módulo 5 – Planejamento em Camadas - Release
 Tem a visão da liberação (release) do produto;
 Tempo médio de 3 a 9 meses;
 Atividades estimadas em pontos de estória ou dias ideais;
 É composto de informações mais gerais.
100
Módulo 5 – Planejamento em Camadas - Produto
Planejamento do Produto
 O Product Owner terá que ter uma visão generalizada do produto maior que a liberação. Normalmente, esta
visão é composta pelo plano de ROAD MAP do Projeto elaborado nas sessões de “brainstorm”
101
Módulo 5 – Planejamento em camadas - Estratégia
Planejamento de Portfólio e Estratégico
 Incluí uma apuração dos produtos que mais apresentem uma visão da
implementação que foi imposta por meio do planejamento estratégico da
empresa.
102
Módulo 5 – Sprint ou Interação
103
Módulo 5 – Conceito de Sprint
A Sprint é um time-box de 2 a 4 semanas no qual o time do projeto irá produzir uma parte do
produto definida pelo cliente
O conceito de Sprint nos remete à necessidade de estarmos frequentemente entregando algo

de valor para o cliente.
Uma Sprint deve ser empreendida por um time multi-disciplinar com não mais que 9
membros
Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-
box específico
104
Módulo 5 – Entregas Sushi X Sashimi
105
Módulo 5 – Conceito de Pronto
• O que significa “pronto” para você em um Projeto/Serviço ?
• Você concorda com essa definição? Por que?
• Quais problemas você percebe com essa definição de “pronto”?
• Como podemos corrigir isso?
106
Módulo 5 – Definition of Done (DoD)
Definição de Pronto. É o contrato

entre o time de desenvolvimento e o
cliente (P.O.) para cada Sprint,
baseado nisso é determinado se os
objetivos da Sprint foram alcançados
ou não
107
Módulo 5 – Incremento do Produto
Ao final de cada Sprint, o time deve ter produzido um incremento

potencialmente entregável do produto com alta qualidade, testado, completo
e pronto
Potencialmente entregável  entregável
S1 S2 S3 S4
S1, S2, S3 e S4 são produtos potencialmente entregáveis
R1
R1 é um entregável!
108
Módulo 5 – Sprint Smart
Specific – Específico
Measurable – Mensurável
Achivable – Atingível
Realistic – Realista
Timed – Datado
109
Módulo 5 – Regras de Ouro da Sprint
• Sempre entregar valor para o cliente ao final de cada Sprint
• Nunca esquecer: o deadline é sagrado, as funcionalidades é o que podem “variar”
• Se houver necessidade de incluir tarefas técnicas, arquiteturais, estudos, ou qualquer tipo de tarefa
que não forneça valor visível para o cliente: fazer balanceamento entre estas tarefas e as com alto ROI
110
Módulo 5 – Sempre Entregar Valor
Itens técnicos, arquitetura...
Itens com ROI visível

S1 S2 S3 S4 S5 S6
111
Módulo 5 – Tamanho dos Sprint
“O tamanho ideal de uma Sprint é o tamanho que sua equipe e cliente achar ideal.”
Pontos de atenção para mensurar:
• Mudança constante no topo do Product Backlog: ideal trabalhar com Sprints curtos
• Dificuldade de entregar valor para o cliente ao fim das Sprints: ideal trabalhar com Sprints curtos
• Equipe e/ou cliente exaustos com loops tão curtos: ideal trabalhar com Sprints longos
112
Módulo 5 – Sem mudanças durante a Sprint
O que o time se comprometeu a entregar – e o que foi acordado com o Product Owner – é o que deve ser entregue
Quando mudar o conteúdo da Sprint se torna regra...
• Deixa de haver a necessidade de fazer um planejamento de qualidade, bem como de estar atento a uma boa
composição e priorização do Product Backlog; afinal, se pode mudar a qualquer momento, para que se preocupar com
isso?
• A equipe ignora a meta, afinal “com certeza” ela mudará
• A equipe perde foco e motivação
• Stress impera
113
Módulo 5 – Quando parar a Sprint?
Uma Sprint pode ser terminada antes da sua finalização nas seguintes situações:
• A equipe sente que não conseguirá atingir a meta
• O Product Owner percebe que mudanças em fatores externos influenciarão diretamente no valor da meta da Sprint
Caso uma Sprint seja cancelada deve se iniciar imediatamente o planejamento da próxima Sprint
114
Módulo 5 – Backlog da Sprint
Backlog da Sprint é
formado do conjunto de
itens selecionados para a
Sprint
Projeção para o Time de Desenvolvimento de quais itens serão desenvolvidos no próximo

incremento e para o time se planejar em como realizar esse incremento.
Planejamento em detalhes para que seja possível o entendimento claro de todos,

principalmente nas Reuniões Diárias.
115
Módulo 5 – Reunião diária
116
Módulo 5 – Reunião diária (Stand-up Meeting)
Reuniões rápidas e objetivas, com 15 minutos de duração.
Time de desenvolvimento se reúne para verificar se o progresso da Sprint está sendo

direcionado para Meta da Sprint que por sua vez está direcionado á Meta do Produto e como
o esforço está tendendo para conclusão.
Esta reunião não serve para resoluções de problemas e conflitos.
117
Módulo 5 – Reunião de Revisão
118
Módulo 5 – Reunião de Revisão (Sprint Review)
Realizada ao final da Sprint com a participação do Product Owner, Partes Interessadas internas
e externas, Time Scrum e outros, com o foco de verificarem o que foi entregue na Sprint e
analisarem
a necessidade de alguma alteração no projeto.
Reunião informal. É realizada para obter feedback da equipe e dos envolvidos.
Tempo de 4 horas para uma Sprint de um mês.
 Equipe relata o que aconteceu durante a Sprint;

 Entrega o incremento do produto;
 Aprendendo com a experiência da Sprint;
 Proibido apresentação com PowerPoint.
Resultado esperado é o Backlog revisado para a próxima Sprint.
119
Módulo 5 – Reunião de Revisão (Sprint Review)
É o momento formal do Scrum para comunicação e interação entre Dono do Produto

e Stakeholders com o time de desenvolvimento. É uma reunião que promove:
A transparência: pois todo o trabalho desenvolvido até então, é apresentado. Não espera-se o final
do projeto para mostrar o que foi feito.
A inspeção: é possível acompanhar a evolução dos trabalhos, pois é

possível avaliar o que já foi feito e o que ainda falta fazer.
A adaptação: é possível fazer ajustes nos itens que faltam, mudar

sua prioridade e solicitar melhorias no que já foi pedido.
120
Módulo 5 – Pós- Reunião de Revisão
 Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las
 Remover do Product Backlog funcionalidades que foram finalizadas antecipadamente
 Repriorização do Product Backlog

 Solicitar o fechamento de um Release com as funcionalidades demonstradas, sozinhas ou com o
incremento de Sprints anteriores
 Escolher não avançar mais com o projeto e não autorizar outra Sprint
 Solicitar que o progresso do projeto seja acelerado autorizando a inclusão de times adicionais
para trabalhar no Product Backlog
121
Módulo 5 – Reunião de Retrospectiva
122
Última cerimônia realizada na Sprint para o Time Scrum analisar todas as lições aprendidas
(boas ou ruins) que ocorreram durante a Sprint.
Scrum Master é o responsável por esta reunião e auxilia o Time de Desenvolvimento a melhorar
dentro da metodologia Scrum o processo e as práticas de desenvolvimento.
Cerimônia para planejamento de melhorias para o produto.
Tempo de 3 horas para uma Sprint de um mês.
123
 Melhoria de processos no final de cada Sprint
 Falicitada pelo ScrumMaster
 O que foi bom? O que deve ser melhorado?
 O ScrumMaster prioriza os itens citados de acordo com a

direção do time
 O time propõe soluções para a maioria dos problemas que a

atrapalham/irritam
 Retrospectivas são a essência do conceito de inspeção e

adaptação
124
Módulo 5 – Quadro de Retrospectiva
O que foi bom? O que deve melhorar?
125
Módulo 5 – Organizando a Análise
Time Empresa Time Empresa
Impedimentos Backlog
126
Módulo 6 – Gestão Financeira
127
Módulo 6 – Valor do dinheiro no tempo
O cálculo do ROI é os valores iguais do investimento no tempo de um ano e o investimento ganho depois de
cinco anos.
VLP (Valor Presente

Valor Presente Líquido): Investimento do
Valor Presente
TIR (Taxa Interna de

Retorno): métrica da
velocidade do aumento
do investimento do
Desconto: Conduz os valores projeto terá,
futuros para retornar ao É utilizado para se ter a métrica de quanto representado em
valor presente dinheiro investido no projeto hoje terá porcentagem.
retorno no futuro, em valor presente atual
128
Módulo 6 – Calculando o retorno financeiro
 Período de Payback Simples;

 Período de Payback Descontado;
 VPL (Valor Presente Líquido) – NVP;
 TIR (Taxa Interna de Retorno) – IRR;
 TCO (Total Cost of Ownership).
129
 Período de Payback é o tempo que um investimento leva para pagar o seu

investimento inicial.
PAYBACK SIMPLES:
É o número de períodos (ano, meses, semanas) para se recuperar o investimento
inicial.
Calculo: soma dos valores dos fluxos de caixa, período a período, até que o valor se
iguale ao investimento inicia.
130
PAYBACK DESCONTADO:
É o número de períodos (ano, meses, semanas) para se recuperar o investimento
inicial, usando uma TAXA DE DESCONTO antes de proceder com a soma dos fluxos
de caixa.
Calculo: soma dos valores dos fluxos de caixa, período a período, até que o valor se
iguale ao investimento inicial. Entretanto, todos os fluxo DEVERÃO ser descontados
pela taxa em relação ao período ao qual o fluxo está atrelado.
131
VPL (Valor Presente Líquido) – NVP
É usado para analisar a viabilidade de projetos, com ele é possível fazer os ajustes
necessários, descontando as taxas de juros para obter a verdadeira noção do valor
do dinheiro no futuro. Leva em consideração a valorização do capital ao longo do
tempo.
Onde:
VPL = Valor Presente Líquido
FC = fluxo de caixa
t = momento em que o fluxo de caixa ocorreu
i = taxa de desconto (ou taxa mínima de atratividade)
n = período de tempo
132

Ex.:
Vamos imaginar uma empresa que esteja pensando em investir em cota de fundo imobiliário que
paga 0,7% ao mês por 2 anos. O valor dessa cota é de R$ 15.000,00.
#01 – Como primeiro passo, definimos o fluxo de caixa:
Onde:
FC = fluxo de caixa
133

Ex.:
#02 – Feito isso, vamos definir a taxa de desconto, ou taxa mínima de atratividade. Como fundos
imobiliários oferecem mais risco quando comparados aos títulos de governo, utilizaremos uma taxa de
12,1% ao ano.:
#03 – Em seguida, calcularemos o valor presente de cada um dos fluxos:
Onde:
FC = fluxo de caixa
134

Ex.:
#04 – Por fim, conforme a fórmula apresentada, somaremos os valores. No nosso exemplo, teremos
que:
135
TIR (Taxa Interna de Retorno) – IRR
É uma medida relativa – expressa em percentual – que demonstra o quanto rende um projeto,
considerando a mesma periodicidade dos fluxos de caixa do projeto, ou seja, calculando a
viabilidade econômica.
136
TCO (Total Cost of Ownership) – Custo total de propriedade

É uma métrica de análise que tem como objetivo calcular os custos de vida e de aquisição de um produto, ativo ou
sistema. Por esta razão o TCO é às vezes chamado análise de custo do ciclo de vida.
Também usado para o cálculo de aquisições em projetos.
137
Módulo 6 – ROI (Return of Investment)
Retorno do Investimento Inicial Investimento Inicial
O objetivo de se realizar o cálculo ROI é para saber em percentuais o retorno do projeto.
138
Módulo 7 – Visibilidade & Previsibilidade
139
Módulo 7 – Progresso do Projeto
Raramente, ao realizar um acompanhamento do andamento do projeto, o resultado será

como o previsto. Devido a alterações de requisitos, a métrica do progresso não será o que
se é esperado, pois falhas podem ocorrer na maneira de como é realizada a medição da
nossa posição.
Estar preparado para a qualquer momento verificar onde o projeto está e o que resta para
termina-lo.
Caso necessite de alterações no projeto, é importante considerar o trabalho já realizado e

quais serão as alterações realizadas no escopo.
140
Módulo 7 – Monitorando o Andamento
Em qualquer momento do projeto, pode ser somado o tempo restante do trabalho

para alcançar o objetivo.
141
Módulo 7 – Monitorando a Velocidade
Os pontos são contabilizados na

velocidade somente com
estórias concluídas no final da
Problemas em contabilizar trabalhos não
Sprint terminados:
Time Scrum
 Dificuldade em contabilizar um trabalho ainda
inacabado;
 Estórias incompletas diminuem a confiança do

Time de Desenvolvimento e cliente;
 Atividades inacabadas ficam acumuladas.

Faz o acompanhamento do progresso
Quantidade de Pontos de
trabalho medindo através da
Estória realizados por Sprints.
velocidade
142
Módulo 7 – Sprint Burndown
A linha direita representa o atual trabalho

realizado.
A linha esquerda é a velocidade que representa a

taxa estimada de trabalho.
No eixo vertical é apresentado a quantidade de

trabalho a ser completado.
No eixo horizontal é apresentado as datas ou dias

de execução.
143
Módulo 7 – Project BurnUp
A linha azul representa a quantidade de trabalho a ser

realizado no projeto de acordo com o tempo.
A linha verde representa o que de fato foi realizado

por cada Sprint. Sendo que acima da linha azul de
monstra que está adiantado, e abaixo, está atrasado.
No eixo vertical é apresentado a quantidade de

trabalho a ser completado no projeto.
No eixo horizontal é apresentado as datas de

conclusão de cada Sprint.
A linha em amarelo, representa o total do projeto em

pontos que deve ser alcançado.
144
Módulo 7 – Quadro Kanban
O KANBAN. É o ponto de controle da Sprint

do projeto, as estórias (user stories) são
segmentadas e disponibilizadas para serem
tratadas por cada membro da equipe dentro
das etapas do ciclo de trabalho. membro
da equipe conforme evolução.
145
Módulo 7 – Kanban utilização
O KANBAN. Pode ser utilizado de diversas

formas, a mais fácil e intuitiva para seu time é o
que deve ser usado.
146
Módulo 7 – Quadro Kanban (Exemplo)
147
Módulo 7 – Alocando o tratamento de Bugs
Um grande desafio para as times ágeis é como lidar com os erros. O Quadro de Tarefas é um grande auxiliar
nesses casos para iniciar as correções.
Se o time determina que é necessário consertar o erro, por sua prioridade ser alta, o Time de
Desenvolvimento estima o trabalho, logo depois, retirem a mesma quantidade da estimativa de atividades na
coluna "Para Fazer" do quadro de Tarefas.
Para poder corrigir os erros levantados pelo Product Owner, o time escolhe a quantidade de iteração deve ser
orientado para correção de erros em vez de um novo recurso; Depois faz uma triagem de quais erros podem
entrar em um período de tempo.
148
Módulo 7 – Acompanhando o esforço da Equipe
 Realizar a coleta de dados e estimativas sem pressão;

 Entender que estimativas variam;
 Não é aconselhável realizar a métrica de velocidade por individuo. A premissa sempre é de trabalho
em equipe;
 Impossível de calcular individualmente, pois as atividades são direcionadas para serem trabalhadas
por mais de uma pessoa.
149
Módulo 7 – Comunicação entre as partes
Além da importância da comunicação, deve-se focar na forma como realizamos e

passamos as estimativas e os planos, sendo de maneira frequente, transparente e
recíproca.
No decorrer do projeto os planos são atualizados, e essas alterações necessitam que

sejam comunicadas, não ignorando os feedbacks que é uma excelente forma de obter
melhoria continua do produto.
Em comunicados que são realizados com uma demora de tempo é importante que as
partes interessadas tenham um panorama do andamento do projeto em relação ás
revisões do plano de liberação.
150
Módulo 7 – Comunicando os Planos
Os Planos tem que ter uma divulgação transparente e clara a todos os envolvidos no
projeto.
Assegurar que todos aceitem a estimativa real.
Número de Pontos de Estória que serão entregues
Dividindo por uma estimativa de velocidade

Cronograma
151
Módulo 8 – Escalando projetos Ágeis
152
Módulo 8 – Escalando projetos Ágeis
Em projetos grandes é difícil gerenciá-lo como um projeto pequeno, pois eles são mais críticos para
organização, de extrema urgência, pode ocorrer conflitos, seu tempo é maior.
Quando isso ocorre, é necessário distribuir em pequenos times em vez de um único de 5 a 9 pessoas
podendo utilizar quantos times forem necessários, não há um limite.
O Product Owner também pode ser escalado, pois pode ocorrer atrasos, gerenciamento das
dependências do time, em coordenar das atividades entre as equipes.
153
Módulo 8 – Escalando o Product Owner
É aconselhável ter um Product Owner para cada time.
Caso isso não seja possível, não deixar mais do que 2 times por Product Owner. Pois com um
número maior, a chance de ter um mal gerenciamento é muito maior.
Em outros casos, quando possuem vários Product Owners no mesmo time, é aconselhável
deixar um responsável, ter uma visão panorâmica de todo o projeto para atuar
estrategicamente com os demais.
154
Módulo 8 – Diversos Backlogs do Produto
Backlog do Produto será um para cada produto.

Terá um tamanho razoável de itens.
Em casos de mais uma equipe, o ideal é ter apenas um Backlog do Produto mas que contempla as
diversas visões dos outros Product Owners.
Caso um time tenha uma visão igual do Backlog do Produto, que possuir itens do interesse de outro
time, assim os itens podem ser mostrados para ambos os times.
155
Módulo 8 – Gerenciando Dependêcias de Equipes
 Planejar com antecedência: fazer com que cada time tenha na Sprint, um momento para se
planejar para o que será feito nas próximas Sprints;
 Kick off das Liberações: Para manter todo o time na mesma linha de objetivo, se reunir para
explicar o que é esperado;
 Compartilhar os membros dos times entre os times: O mesmo membro trabalhando em duas
equipes ao mesmo tempo;
 Time de integração: trabalha entre as equipes para preencher os espaços que existe.
156
Módulo 8 – Scrum dos Scrums
Cada time possuí o embaixador que através de reuniões periódicas se reúnem para relatar o que cada
um dos times pretendem realizar e os possíveis impedimentos que podem interferir nas atividades.
Os embaixadores podem ser:
 Desenvolvedores;
 Scrum Masters;
 Gerentes de cada equipe.
Cada equipe possuí seu próprio backlog para otimizar a organização entre as equipes.
157
Módulo 8 – Frameworks Escaláveis
1. Nexus
Destinado a 3–9 equipes Scrum.
Foco: Ampliar o Scrum na sua forma mais nativa. Ele mantém o “material” no mínimo, por isso é
conciso e bastante rápido de aprender.
O Nexus está fortemente focado neste papel de integração.
Maiores detalhes: https://www.scrum.org/resources/nexus-guide
2. Less
O LeSS concentra-se fortemente em Scrum-of-Scrums. A estrutura LeSS tem menos processo,

menos artefatos e menos papéis, permanecendo fiel a ter apenas os papéis Scrum originais de
PO, SM e Team.
Utiliza práticas e princípios de outras metodologias como: Mais com menos, foco no produto,
foco no cliente, melhoria contínua, pensamento Lean etc.
Maiores detalhes: https://less.works/

158
Módulo 8 – Frameworks Escaláveis
3. SAFe
Este modelo não é apenas Scrum, mas Agile. Por exemplo, tem um processo Kanban na seção
de portfólio superior.
Na SAFe, o SM é um papel muito importante na equipe Scrum e faz muito coordenação intra-
equipe e inter-equipe.
Em SAFe: Epics, Features e Stories são explicitamente tratados como partes integrantes dos
backlogs SAFe
O SAFe é mais abrangente na oferta de processos e papéis para lidar com o desenvolvimento
de software, ao custo de talvez aparecer pesado em processos.
Maiores detalhes: http://www.scaledagileframework.com/
159
Módulo 8 – SAFE – Scaled Agile Framework
SAFe criado pela Scaled Agile serve para organizações de grande porte.
É uma base de conhecimento para a implementação da metodologia ágil em uma organização.
Com uma interface de usuário principal apresentada por um desenho, ou um Big Picture, que detalha
os papéis, times, tarefas, e artefatos que é preciso para implementar o ágil em grande escala.
160
Módulo 8 – SAFE – 8 Vantagens
1. Visão Global
Elaborado para expandir o Agile em toda a empresa, e não somente na equipe de desenvolvimento. Portanto, a
gerência, os analistas de negócio, analistas de sistemas e gestores também passam a fazer parte deste
FRAMEWORK, utilizando ferramentas e seguindo práticas que antes eram só desempenhadas por desenvolvedores,
projetistas e analistas de testes.
Toda a organização fica integrada em uma única estrutura.
161
2. Big Picture – Tudo em uma mesma página
Na página oficial do SAFe [https://www.scaledagileframework.com/] , há um diagrama definido como The Big

Picture, que aborda todos os fluxos, papéis e atividades, facilitando um entendimento “macro” do framework.
Ao visualizar a The Big Picture pela primeira vez, por exemplo, já é possível observar que se propõe três níveis na
escala organizacional:
1. Portfolio (gerencial),
2. Program (estratégico)
3. Team (operacional)
Cada nível é responsável por um conjunto de funções e tarefas necessárias para a condução das funcionalidades
a serem desenvolvidas em cada ciclo.
162
3. Gratuito
Pela sofisticação, alguém pode pensar que o SAFe exige uma “licença” para ser utilizado. Errado!
Qualquer empresa pode estudar e implantar a metodologia sem custo algum. Todo o material de apoio (muito bem
detalhado!) está disponível no site. A The Big Picture, assim como outros gráficos, também podem ser baixados
gratuitamente.
163
4. Conheça e use
A The Big Picture é totalmente interativa. Cada figura representa um link que leva à uma página com definições
mais detalhadas sobre o conceito. Sendo assim, em 1 semana (ou até bem menos), é possível acessar todos os
links e compreender plenamente o funcionamento do framework.
164
5. Incorpora métodos ágeis já consolidados no mercado]
O SAFe unifica os conceitos das metodologias Scrum e XP e cria um termo literalmente definido como ScrumXP.
Este “novo” termo engloba tanto os procedimentos do Scrum para gerenciamento de equipes, como as práticas
do XP para a qualidade de código.
XP = Extreme Programming (Programação Extrema)
165
6. Novos papéis, equipes e definições no contexto ágil
Release Planning: Onde todas os Agile Teams (equipes ágeis) se unem para discutir as funcionalidades que serão
desenvolvidas no próximo PI (Program Increment)
RTE (Release Train Engineer):Papel responsável por conduzir as equipes de desenvolvimento durante
um ART (Agile Release Train) e ministrar eventos como o I&A (Inspect & Adapt)
System Team: Equipe alocada para homologar as user stories concluídas no ciclo DBT (Define/Build/Test) e
apresentá-las no evento System Demo
Estes e outros conceitos foram elaborados ou customizados para viabilizar o Desenvolvimento Ágil em escala.
166
7. Quebra de Paradigmas
No Scrum, sabemos que as user stories são desenvolvidas em uma Sprint e, ao seu término, um novo incremento
do software é disponibilizado para o cliente.
No SAFe, este ciclo acontece de uma forma um pouco diferenciada: o incremento final do programa é entregue a
cada 75 dias! Mas, calma, isso não significa que tudo é feito em uma única “super” Sprint. Na realidade, são 5
Sprints de 15 dias que, no SAFe, representam um “trem”, ou um Agile Release Train.
Esse time-box foi introduzido para facilitar a integração de vários times ágeis e permitir que o produto, com todas
as implementações do ciclo, seja testado por uma equipe específica antes de ser disponibilizado para o cliente.
Mas o ciclo, por exemplo, pode ser estendido para 90 dias (3 meses) ou reduzido para 60 dias (2 meses). Vale citar
também que a última Sprint de cada “trem”, chamada de Innovation and Planning, é exclusivamente utilizada para
treinamentos, inovações e capacitações dos colaboradores como forma de melhoria contínua.
167
8. Permite a sustentabilidade da arquitetura
Na The Big Picture, pode-se notar que alguns itens dos backlogs estão em vermelho.
Estes são chamados de itens arquiteturais, criados para refinar a arquitetura do projeto (através de refatorações,
por exemplo), ou prepará-la para receber futuras funcionalidades de negócio.
Por meio destes itens, é possível manter a sustentabilidade do projeto, evitando o código legado, módulos
obsoletos e restrições técnicas.
168
Módulo 8 – SAFE – Evolução
169
Os times trabalham em conjunto na release planning, desenhado os riscos e dependências entre times de
acordo com as definições definidas pelo Programa e consequentemente pelo portfólio. O que gera como
resultado um documento chamado “PROGRAM BOARD”
170
171
Cada RELEASE definida pelo portfólio são repassados ao programa que trabalha com o foco no ART
(Agile Release Train).
O ART pode durar de 2 a 3 meses e todos os times trabalham com foco em atender esse release e
outras demandas do backlog esperam a próxima ART.
172
No safe temos outros papeis.
173
O funcionamento do SAFE dentro de um ART é como segue na figura abaixo:
174
Fonte: https://www.scaledagileframework.com/#
175
176
177
178
179
Módulo 9 – Incorporando o Scrum
180
Módulo 9 – Inserindo o Scrum em projetos
Uma organização pode ter vários motivos que a leva a ter restrições para a implementação ágil por toda a
empresa, principalmente quando há um Método em Cascada sendo utilizado ao mesmo tempo.
Para isso é necessário ter a seguinte visão:
 Logo no inicio do projeto se adequar a realidade da organização;

 Scrum e o Cascata se encontram na fase final do projeto, nos testes;
 Que podem existir duas equipes utilizando métodos diferentes para entregar o mesmo produto.
181
Módulo 9 – Zonas de Conflito
Processo de Desenvolvimento: Modos diferentes de processos para desenvolvimento entre o

Scrum e o Cascata.
Processos de Negócio: Se a organização está habituada com os processos em Cascata será

difícil habituar ao processo Scrum.
Pessoas: Conflito entre os diferentes papéis que existem entre as duas formas de trabalho.
182
Módulo 9 – Adotando a Agilidade
As organizações estão optando pelo Ágil devido a sua velocidade de entrega de um produto ou
serviço rápida e com qualidade.
No entanto para iniciar as boas práticas ágeis em uma organização não é tarefa fácil. Alguns
pensamentos que tem ser considerados em uma transição:
 Scrum não é somente na área de Desenvolvimento de Software;

 As boas práticas ágeis devem atingir todos os setores da organização;
 Melhoria Contínua é a alma do Scrum;
 Transparecer em todos da organizações os benefícios da implementação do ágil irá trazer.
183
Módulo 9 – Considerações na Transição para Scrum
 Até mesmo um CEO não terá como implementar o Scrum com uma correta visão, comunicar isso aos
demais, conseguir eliminar os obstáculos, ter ganhos a curto prazo e gerenciar diversos projetos de
mudança.
 Uma organização que quer implementar o Scrum sem o apoio da alta liderança, não terá um resultado
eficaz e eficiente.
 Análises de GAPs: Impossível prever o que irá acontecer no futuro, sozinho ou com a participação de
todos, Scrum é tudo diferente, coletar as melhores práticas pode ser algo perigoso, a mudança acontece
em uma velocidade acima do normal.
184
Módulo 9 – Benefícos do Scrum
Aumento da Funcionários engajados e Time-to-Market

Produtividade envolvidos mais ágil
Redução dos Custos
Aumento da Qualidade Aumento da satisfação O que está sendo feito

das Partes Interessadas atualmente já não
funciona mais
185
Módulo 9 – Adotando com Sucesso
Conscientizar as pessoas Mostrar que o Scrum é Evangelizar o Scrum com

que o método atual não Time-to-Market
uma forma de resolução a troca de experiências
está sendo satisfatório mais ágil
dos problemas atuais
Necessário definir onde todos da empresa: pessoas, times e a

organização como um todo estão no processo de adoção do
Scrum
Passar o conhecimento
da utilização do Scrum na
organização
186
Módulo 9 – Marcos na Transição
A wareness – Consciência do que é feito hoje não está tendo resultados com valor.
D esire – Desejo ter o Scrum como um método para solucionar os problemas.
A bility – Capacidade para obter resultados com o Scrum.
P romotion – Promover a filosofia ágil com troca de experiências.
T ransfer – Transferência de sugestões da utilização do Scrum em toda organização.
187
Módulo 9 – Resistência na Adoção do Scrum
O Scrum Master é responsável por envolver o time na utilização do Scrum por meio de demonstrações dos
benefícios que o framework traz.
Identificar os indivíduos que podem ser resistentes a mudança, sendo eles aqueles que podem perder algo
como: cargo, prestígio, influência e entre outros.
188
Módulo 9 – Tipos de Resistentes
Céticos Sabotadores Resistentes
Teimosos Seguidores
189
Módulo 9 – Lidando com a resitência á Mudança
 O tempo fazer com que a pessoa acredite que dará

certo com os bons resultados;
 Fornecer treinamento;
 Exemplificar com experiências de sucesso;
 Escolher um cético que conseguiu entender o
Céticos processo;
 Auxiliar a pessoa a ter consciência das práticas ágeis e
seus benefícios.
190
 Movê-lo para outra área;

 Mandar embora;
 Ter certeza que as pessoas certas estão falando.
Sabotadores
191
 Deixar claro os incentivos;

 Gerar satisfação com o status-quo;
 Reconhecer e lidar com o medo.
Teimosos
192
 Modificar a composição do time;

 Reconhecer o comportamento correto;
 Envolvê-los;
 Modelar de maneira correta o comportamento de si
Seguidores
mesmo;
 Verificar a verdadeira barreira.
193
Módulo 9 – Equipe Auto Organizada
A prática Scrum preza pelas equipes auto organizáveis, mas isso não significa que não há controles.
Controles de uma forma sutil e indireta.
O Time Scrum tem como tarefa de ser auto organizável em meio a desafios, e dentro dos limites e
restrições.
O time ser capaz de se auto organizar por meio das metas é fundamental em todas as práticas ágeis.
194
Módulo 9 – Construindo Equipes
 Listar todas as habilidades necessárias;

 Balancear níveis de conhecimento técnico;
 Balancear o domínio de conhecimento;
 Localizar diversidade;
 Ser persistente.
195
Módulo 9 – Requisitos ágeis
 Ambiente de trabalho ideal auxilia no apoio ao time;

 A falta do ambiente ideal impede no esforço;
 Ter estrutura para poder questionar;
 Modelo em que os membros do time reportem a um gerente ou o Product Owner;
 Naturalmente a pressão sobre eles tende a minimizar, ajudando então o progresso
do projeto e diminuindo a pressão;
 Product Owner e o Scrum Master não precisam estar na mesma linha do
organograma, porém os dois devem se tratar como parceiros no projeto.
196
Módulo 9 – Espaço de Trabalho
O Scrum preza por ambientes sem divisórias e sem salas para facilitar o fluxo de informações e
comunicação entre todos, com pequenas salas de reunião que podem ser utilizadas por qualquer
pessoa.
 Ambientes abertos facilitam a alteração do layout;

 Como os times mudam de tamanho, os ambientes abertos, são propícios para a alteração dos
lugares quando necessário;
 Sala de Guerra (War Room);
 Times Scrum também necessitam de sala para reuniões;
 Desenvolvedores e Testadores devem sentar juntos.
197
Obrigado
Agile Scrum Foundation

ASF
198

Treinamento Agile Scrum Foundation - Trainning 2021

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Treinamento Agile Scrum Foundation - Trainning 2021

Enviado por

Direitos autorais:

Formatos disponíveis

Agile Scrum Foundation - ASF

 Pessoas que desejam estar atualizadas;

 Gerente de Serviços de TI;

Não há pré-requisito para realizar o curso e a

Entretanto para melhor aproveitamento do curso

 Não é permitido o uso de nenhum

No documento, as regras e o funcionamento do Scrum estão descritos de forma bem concisa

Módulo 1 – Agile Mind Set & Chaos Report

Módulo 3 – Papéis no Scrum

Módulo 4 – Artefatos do Scrum

Módulo 7 – Visibilidade & Previsibilidade

Módulo 8 – Escalando Projetos Ágeis

Módulo 9 – Incorporando o Scrum

Conjunto de técnicas e práticas para gestão de projetos que oferece

Tornando os processos mais simples, dinâmicos e iterativos, da

De acordo com a pesquisa PMI’s Pulse of the Profession 2018,

 Desenvolvimento incremental, ou seja, de melhoria contínua;

Standish Group 2018

Standish Group 2019

Fonte: VersionOne, Agile Annual Report, 2020

Metodologia: é um conjunto de métodos, padrões e regras

“Framework” ou Boas Práticas: é uma estrutura, um conjunto de

Você diria que o “Scrum” é uma a metodologia?

“O termo “ágil” data de uma reunião de 2001, na qual eu e 16

Scrum é a estrutura que eu construí para colocar esses valores em

Jeff Sutherland, cocriador do SCRUM, no seu Livro Scrum - a arte de fazer

Então, um Framework ou boas práticas podem fazer parte de

Sim! As práticas ágeis são mais um hábito do que um processo.

É um processo interativo e incremental para o desenvolvimento de

É mais um framework que uma metodologia, mais atitute que um processo;

• Software comercial • Video games

A metodologia tradicional, ou metodologia cascata, é baseada em sequência predefinida de

Conforme os ciclos se repetem, o produto é aprimorado continuamente de modo experimental,

Comprometimento Coragem Foco Abertura Respeito

Cada integrante de um projeto Scrum se compromete com o trabalho que

Comprometimento Coragem Foco Abertura Respeito

Os integrantes de um projeto Scrum (SM + PO + TIME) precisam ter

Comprometimento Coragem Foco Abertura Respeito

Os integrantes de um projeto Scrum precisam focar no trabalho durante o

Comprometimento Coragem Foco Abertura Respeito

Comprometimento Coragem Foco Abertura Respeito

Respeitar uns aos outros é o primeiro passo para manter a colaboração, a

Alinhamento entre envolvidos;

Inspecionar artefatos produzidos;

Analisar o grau de impacto de possíveis desvios dentro do plano;

1. Recebesse entregas periódicas agregando valor ao negócio

1. Recebesse entregas periódicas agregando valor ao negócio

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

Indivíduos e interação entre eles mais que processos e ferramentas

Source: VersionOne Annual State of Agil Report, 2019

Product Owner ScrumMaster Equipe

• Durante a execução da Sprint, valem as práticas de engenharia definidas para o projeto;

• Diariamente o time realiza uma reunião de 15 minutos (Daily Meeting) :

• A última cerimônia de um Sprint Scrum é a Retrospectiva;

A maioria dos projetos entregam software a cada 6 a 18 meses.

SCRUM reduz isso a muitas entregas mensais que incrementam

Isto permite a equipe e a organização, maior visibilidade,

O trabalho do ScrumMaster é priorizar estes problemas e ajudar a organização a superá-los,

 Remover a barreira entre desenvolvimento e cliente

 Assegure-se que todo mundo está fazendo o que se comprometeu a fazer

 Trabalhe no Product Backlog com o Product Owner

 Zelar pelo bom funcionamento ágil em toda sua essência

Realizar análise em detalhes;