Agile Scrum Master - ASM

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

Conhecimento prévio dos conceitos básicos do

Scrum é recomendável para realizar o curso e a
prova de certificação.

Além do treinamento em Scrum Master e prática

com exercícios e simulados.

3
Sobre o Exame

✓ Questões múltipla escolha com 4

Duração: 90 minutos opções de resposta, somente uma
correta

✓ Acerto de 26 questões
Questões: 40

✓ Sem consulta
Aprovação: 65% da prova ✓ Não é permitido o uso de nenhum
equipamento eletrônico

4
Alcance do Exame

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 – Forma Ágil de Pensar - Agile Mind Set

Módulo 2 – O Papel do Scrum Master

Módulo 3 – Estimativa, planejamento, monitoramento e controle Ágeis

Módulo 4 – Projetos Complexos

Módulo 5 – Adotando o Ágil

7
Módulo 1 – Agile Mind Set

8
Agile Mind Set - O que é

É o conjunto de atitudes que sustentam um ambiente de trabalho

ágil.

Este mindset é necessário para cultivar equipes de alta performance,

que, por sua vez, oferecem um valor incrível a seus clientes.

9
Agile Mind Set - Conceitos Ágeis

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

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

11
Valores do Scrum

Comprometimento Coragem Foco Abertura Respeito

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.

12
Valores do Scrum

Comprometimento Coragem Foco Abertura Respeito

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

Sprint e nas metas designadas pela empresa. Time disperso perde
produtividade e não alcança os objetivos.

13
Valores do Scrum

Comprometimento Coragem Foco Abertura Respeito

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.

14
Valores do Scrum

Comprometimento Coragem Foco Abertura Respeito

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

integração e bom ambiente de trabalho.

15
Estabelecendo a Cultura Ágil

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

16
Manifesto Ágil – Valores da agilidade (4)

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

Software em funcionamento documentação abrangente

Mais que

Colaboração com o cliente negociação de contratos

Responder a mudanças seguir um plano

17
Manifesto Ágil – Princípios (12)

1. Nossa maior prioridade é satisfazer o cliente, através da entrega antecipada e contínua

de software de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis

devem se adequar às mudanças, para que o cliente possa obter vantagens
competitivas.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com
preferência para períodos mais curtos (2 a 4 semanas).

4. Pessoas relacionadas ao negócio e desenvolvedores devem trabalhar em conjunto e,

de preferência, diariamente, durante todo o curso do projeto.

18
Manifesto Ágil – Princípios (cont.)

5. Construir projetos ao redor de pessoas motivadas, dando a elas o ambiente e suporte

necessários, e confiar que farão o trabalho.

6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time
de desenvolvimento, é através de uma conversa cara a cara.

7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
constantes.

19
Manifesto Ágil – Princípios (cont.)

9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então os membros se
ajustam e otimizam seu comportamento de acordo.

20
Abordagens ágeis

21
 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 AGILIDADE , 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
Tradicional x Agile

Adaptabilidade: Na AGILIDADE, 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
Áreas de Conhecimento

24
Módulo 2 – O Papel do Scrum Master

25
Alicerce da Comunicação

26
Visão mais nítida
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 Scrum Master é priorizar estes problemas e

ajudar a organização a superá-los, gerenciando
investimentos e garantindo o seu retorno.

27
Um Scrum Master Deve...

➢ Remover a barreira entre desenvolvimento e cliente;

➢ Ensinar o cliente a maximizar 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.

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

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

30
Atributos de um bom Scrum Master

Responsabilidades:
▪ Humildade;
▪ Colaboração;
▪ Comprometimento;
▪ Influência;
▪ Conhecimento.

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

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

33
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.
34
O Time deve...

➢ Executar as ações definidas para o Sprint Backlog;

➢ Ser por característica multidisciplinar;

➢ Ter foco na meta da Sprint e do Produto;

➢ Prezar pela comunicação clara, objetiva e efetiva;

➢ Zelar pela garantia do DEADLINE da SPRINT;

➢ Ser inovador e contribuir ativamente para o sucesso do projeto;

➢ Entender a demanda apresentada e propor a melhor forma de atendê-la;

➢ Ser claro na informação sobre IMPEDIMENTOS encontrados durante a

Sprint;

➢ Sempre entregar como resultado da Sprint, algo que agregue valor ao

cliente;

35
O Time Scrum

OS PAPÉIS NO SCRUM
• 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;

• Equipe
Definir metas das iterações;
Auto-gerenciamento;
Produzir produto com qualidade e valor para o cliente;

36
Módulo 3–Estimativa, planejamento, monitoramento e controles Ágeis

37
Estrutura do Scrum

Product Owner ScrumMaster Equipe

38
Estrutura do Scrum

• O Product Owner define a Visão 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
Estrutura do Scrum

• 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
 Escrevendo o 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.

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

42
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;

43
Nível certo de priorização

44
Funcionamento do Product Backlog

45
Funcionamento do Product Backlog

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

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.

46
Módulo 4 – Funcionamento do Product Backlog

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.

47
Engenharia do Product Backlog

48
Lista de Desejos no Product Backlog
O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os requisitos que um cliente
espera receber ao final do projeto, descrito com sua própria linguagem. O ponto central do Scrum é a criação
do Product Backlog, é nele que o projeto começa.

Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder começar a
executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso. Afinal nesse ponto ainda
não conhecemos suficiente o projeto e precisamos avançar um pouco mais em algumas hipóteses antes de ter
tanta “certeza”.

Uma mudança muito clara no mindset é que no início do projeto o Product Backlog não precisa estar completo.
Podemos ter uma visão macro do produto e dos requisitos esperados. Conforme avançamos no projeto, o
Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Para melhor estruturar o Product Backlog nós utilizamos as chamadas estórias — itens do Product Backlog —
elas contém a descrição detalhada dos requisitos de cada solicitação a ser implementada. Em nossas estórias
incluímos os seguintes campos:

49
Lista de Desejos no Product Backlog
ID ou #
Uma identificação única, apenas um número com auto-incremento. O objetivo disto é evitar que, ao mudarmos
seu nome, percamos o controle sobre as estórias.

Nome
Um nome curto e descritivo para a estória. Por exemplo; “Layout do Relatório”. O nome tem que ser explicativo
o bastante, para que os membros do time e o Product Owner entendam minimamente sobre o que estamos
falando, e específico o suficiente para distingui-la das demais estórias.

Prioridade
Definir qual é importância dessa estória na perspectiva do Product Owner (em relação ao cliente). Por
exemplo: 10 ou 150. Quanto mais pontos mais prioritário.

Estimativa
Estimativas preliminares que o time dá sobre quanto tempo será necessário para concluir uma determinada
estória, se comparada as demais. Normalmente dá-se uma pontuação que está diretamente relacionada à
complexidade da tarefa e que servirá como base para se calcular quantos dias / horas / pessoas serão
necessárias para entregar. Se a pontuação estiver muito alta, uma dica interessante é quebrar a tarefa
em duas atividades, desta forma ficará mais fácil acertar na estimativa.

Critérios de Aceite
Em alto nível criamos uma descrição de como a estória será demonstrada na apresentação da sprint.
50
Workshop de Estórias

51
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;

52
Estórias

Independente
Negociável
Valiosa para usuários e cliente
INVEST
Estimável
Small (pequena)
Testável

53
 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? 54
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.

55
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

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

57
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

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

58
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;

59
Nem tudo é Estória

ESTORIA
ESTORIA ESTORIA
EPICO
TEMA

TEMA
ESTORIA ESTORIA ESTORIA
ESTORIA ESTORIA ESTORIA ESTORIA

60
Estrutura do Scrum

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

61
Estrutura do Scrum
• Na primeira parte da Planning Meeting o PO deverá: definir a meta da
Sprint 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. Essa lista selecionada chama-se Selected Product Backlog;
• O facilitador desta reunião é o Scrum Master.

62
Dimensionando Estórias (Planning Poker)

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.

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.

63
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;

64
Estrutura do Scrum

• 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 Scrum Master.

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

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

67
Quadro Kanban (Exemplo)

68
Planejando ...

69
Planejamento em Camadas

70
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:

71
Estrutura do Scrum

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

para o projeto;
• O Scrum Master, 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;.

72
Conceito de Iteração (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 multidisciplinar com não mais que 10 membros

Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-box
específico

73
Sprint Smart

Specific – Específico

Measurable – Mensurável

Achivable – Atingível

Realistic – Realista

Timed – Datado

74
Estrutura do Scrum

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

na qual cada membro deve responder:
• O que fiz desde a última reunião?
• O que pretendo fazer até a próxima?
• Tive (estou tendo) algum impedimento?
• 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 Scrum Master novamente é o facilitador, e deve lembrar-se que a
reunião é para o time e não para ele.

75
Reunião diária (Daily stand-up)
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 e como o esforço está tendendo para conclusão.

▪ O que foi feito?

▪ O que será feito?
▪ Tem algum obstáculo?

Esta reunião não serve para resoluções de problemas e conflitos.

76
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

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

78
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

79
Entregando o 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!
80
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

81
Sempre Entregar Valor
Itens técnicos, arquitetura...

Itens com ROI visível

S1 S2 S3 S4 S5 S6

82
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

83
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

84
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

85
Planejamento da Liberação (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 ).

86
Planejamento da Liberação (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

87
Tamanho da Liberação (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

88
 Planejamento do 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”

89
Conceito de pronto (DoD)

90
Conceito de Pronto (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 foram alcançados ou não.

91
Criando o Conceito de Pronto (DoD)
Documento colaborativo

A criação do conceito de pronto deve ser realizada de maneira colaborativa, ou seja, por todos os membros
do Time Scrum.

Durante a primeira Sprint Planning, o time definir a v1 da sua definição de pronto. Por exemplo: comece com
coisas simples como “todo item dado como pronto deve ter passado em testes unitários” e depois se aprofunde
em itens mais “avançados” como testes de regressão e teste em pares

Seguindo os pilares no Scrum inspeção e adaptação, transparência) itere e melhore seu conceito de pronto a
cada Sprint.

Pegue o que deu errado na Sprint Review e aborde na Sprint Retrospective e aplique de maneira aperfeiçoada
na próxima Sprint Planning. Comece simples e avance rapidamente. Lembre-se que a função deste artefato
é garantir a qualidade, mas lembre-se também de se manter ágil.

Na Sprint Planning considerar o conceito de pronto pois o tempo para que cada entrega fique pronta pode
mudar drasticamente. Tenha a definição de pronto pronta antes de jogar Planning Poker, por exemplo.

92
Criando o Conceito de Pronto (DoD)

Contrato moral

O conceito de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas.

Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há um elemento
de software envolvido, lhe cobrando diariamente que cumpra os requisitos do documento.

Sendo um contrato moral e ao mesmo tempo algo colaborativo, o time terá de achar o checklist que agrade a todos,
incluindo aqui o Product Owner, que é quem tem a palavra final sobre os itens do Backlog que o Time de
Desenvolvimento está trabalhando.

O documento deve ser útil para garantir a qualidade das entregas que seja executável, exequível.

93
Acompanhamento do Projeto

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

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

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

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

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

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

100
Estrutura do Scrum

• 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;
• Product Owner faz anotações que poderão se transformar em novos
Itens para o Product Backlog.

101
Revisão da Sprint (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.

102
Retrospectiva da Sprint (Retrospective)

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

• Reunião de lições aprendidas, facilitada pelo Scrum Master, 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.

?
103
Ú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.

104
Módulo 4 - Projetos Complexos

105
Adequação do Ágil para diferentes tipos de projetos

A necessidade de transformação está acontecendo mais rápido do que nunca. Cada vez mais, empresas precisam se
adaptar a mudanças de requisitos e prazos definidos de entrega.

O Agile ou Ágil tem o objetivo de proporcionar o produto ou projeto funcionando o mais rápido possível com permite um
melhor uso dos recursos humanos e dos gastos financeiros. Além disso, garante a satisfação do cliente com entrega
adiantada e contínua, assim como mudanças necessárias no escopo do produto.

Esta prática pode ser adaptada a equipes e empresas de diferentes tamanhos com formas de contratação variadas.

106
Adequação do Ágil para diferentes tipos de projetos
Projeto com prazo fixo
Nesse tipo de contrato, o escopo do projeto deve ser negociado. Quando a versão de entrega do produto tem data fixa, é
possível determinar um valor no início do projeto, pois será possível calcular quantas Sprints serão necessárias e seu
orçamento.

Projeto sem prazo fixo

Quando um contrato não tem prazo fixo, mudanças no escopo do projeto e variação de custos podem acontecer. Sendo
assim, é necessário ter uma equipe auto-organizada, que tenha conhecimento do projeto, de Scrum e de negócios.
Assim, é possível definir a quantidade de Sprints e o valor máximo do projeto.

Preço fixo por Sprint

Com esse contrato, há um escopo fechado e um preço fixo. Os requisitos do Product Backlog são programados para
cada Sprint e é determinado o valor que elas terão. Esse tipo de contrato oferece a opção de parada do projeto caso a
empresa não esteja satisfeita.

Preço fixo com metas por Sprint

O contrato de preço fixo oferece metas de qualidade, ou seja, é determinado um custo do projeto, uma velocidade de
produtividade da equipe e um intervalo-limite de tolerância para essa velocidade.

107
O Ágil vs Método tradicional

A metodologia Waterfall (Cascata), é uma metodologia de gerenciamento de projetos que adapta o modelo de entrega em
cascatas.

“O planejamento em cascata, também conhecido como Waterfall, ou como ciclo de vida preditivo significa conduzir o
projeto através de fases sequenciais que podem ter duração curta ou longa”.

A metodologia Waterfall segue etapas para a execução do projeto final.

Estas etapas consistem na análise do problema, observando o que está sendo estudado. Depois temos o desenho da
solução, que dará uma visualização do conteúdo. A tecnologia vem em seguida, e ajuda na resolução dos problemas para
a implementação, na hora de sair do papel.

As últimas etapas são divididas entre a fase de testes e implantação, resultando no produto final.
.

108
O Ágil vs Método tradicional
Atendimento das expectativas
Por ser um processo de desenvolvimento com muitas e longas fases, e sabendo que o resultado do produto só é
visualizado na última etapa, corre-se o risco de o cliente não ficar satisfeito.
Como o ágil resolve: com a Sprint Scrum e o Agile UX.

Mudanças de mercado e negócio

As condições de mercado e negócio podem mudar no decorrer do projeto, e o resultado final pode não estar adaptado a
essas mudanças.
Como o ágil resolve: com a Sprint Review.

Alteração de requisitos
No decorrer do projeto, o cliente pode sentir a necessidade de alterar a ordem de alguns requisitos ou até mesmo
acrescentar pedidos que ficaram de fora no primeiro momento. Essa prática pode impactar possíveis restrições do
projeto, como tempo e custo.
Como o ágil resolve: com a Sprint Backlog.

Problema na fase de testes

Essa é uma das últimas etapas para o final do projeto, como também é a etapa em que são encontrados muitos
problemas que geram retrabalhos, custo e insatisfação das partes interessadas.
Como o ágil resolve: com o Sprint retrospective.

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

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

111
Diversos Backlogs do Produto

Backlog do Produto será um para cada produto e 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.

112
Gerenciando Dependências 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.

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

114
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/

115
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/

116
Ferramentas para gestão Ágil

Existem vários aplicativos que permitem o gerenciamento de projetos nas prática ágeis de forma premium ou
paga. As mais úteis e fáceis de usar são:

Trello (Premium)
Plataforma extremamente útil, flexível, visual e GRATUITA! Permite visualizar fluxos de trabalho confortavelmente
e temporariamente, a partir de colunas verticais às quais as diferentes etapas do projeto podem ser atribuídas
(pendentes, em curso, concluídas …), notas, perfis de certos trabalhadores, etc. Também podemos criar
categorias e listas de verificação para marcar todas as tarefas concluídas ou para concluir, etc.

Trello tem seu aplicativo para smartphones e tablets, além de permitir o acesso à internet.

Atlassian Jira (Paga)

Ideal para empresas de desenvolvimento de software. Permite organizar os estágios de um projeto, atribuí-los a
profissionais e acompanhar seu desenvolvimento em equipe.

Sua interface é confortável e intuitiva, pois mostra todas as atividades futuras, em desenvolvimento, completo ou
em incidentes do mesmo módulo principal organizado por colunas.

Embora seja pago, permite o download para uma semana de teste gratuita.

117
Ferramentas para gestão Ágil
Asana (Premium)
O Asana é um dos softwares mais populares pelo seu design intuitivo bem como suas funcionalidades: permite aos
profissionais visualizar seus objetivos, atribuir-lhes um tempo e priorizá-los, receber atualizações e visualizar tudo como
um calendário. Ele também tem seu aplicativo.

Axosoft (Paga)
Possui quatro módulos: Scrum, Bug Manager, Help Desk e Wiki. Otimiza os processos operacionais por meio de análise
automatizada, gráficos e uma tabela que permite a visualização, edição e difusão de tarefas. Permite o uso gratuito por
14 dias grátis.

iceScrum (Premium)
Facilita o cumprimento dos objetivos comerciais. Permite a organização de tarefas por colunas, exatamente como as
anteriores. No entanto, como um programa gratuito, sua vantagem está focada na análise, indicadores e gráficos que ele
constrói a partir dos dados que fornecemos.

118
Módulo 5 – Adotando o Ágil

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

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

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

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

123
Benefícios 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

124
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

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

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

127
Tipos de Resistentes

Céticos Sabotadores Resistentes

Teimosos Seguidores

128
Lidando com a resistência a 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.

129
Lidando com a resistência á Mudança

▪ Movê-lo para outra área;

▪ Mandar embora;
▪ Ter certeza que as pessoas certas estão falando.

Sabotadores

130
Lidando com a resistência á Mudança

▪ Deixar claro os incentivos;

▪ Gerar satisfação com o status-quo;
▪ Reconhecer e lidar com o medo.

Teimosos

131
Lidando com a resistência á Mudança

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

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

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

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

135
Obrigado

Agile Scrum Master

ASM
136