Curso preparatório para as certificações

Lean IT Essentials, Scrum Essentials e

DevOps Essentials
(DevOps Lead)
Lean IT Essentials
Objetivo do módulo
• Este módulo tem por objetivo preparar estudantes e profissionais de TI para realizar o exame da
certificação ITC-027 Lean IT Essentials.
Introdução

• Lean IT
• Filosofia que tem por objetivo eliminar atividades desnecessárias, reduzir custos, agregar
valor e aumentar a satisfação dos clientes, promovendo maior eficiência e a melhoria
contínua dos serviços de TI, com ênfase no envolvimento dos colaboradores na otimização
dos processos de negócios da organização.

• É a aplicação dos princípios lean para todos os processo de TI.

• Abordagem baseada na filosofia Lean Thinking (Mentalidade Lean), Sistema Toyota de

Produção(STP) e Six Sigma.
Filosofia Lean

• Objetivo da Filosofia Lean

• Principal objetivo da filosofia Lean é agregar valor para o cliente por meio da eliminação
sistemática do desperdício.
• Identificar o que é valor para o cliente é o ponto de partida da filosofia Lean.

• Princípios
• Continuo envolvimento de todos os colaboradores.
• Transparência da informação.
• Respeito pelas pessoas.
Sistema Toyota de Produção (STP)
• Sistema Toyota de Produção (STP)
• Surgiu após a Segunda Guerra Mundial.
• Taiichi Ohno é considerado um dos principais responsáveis pela criação do Sistema Toyota de
Produção (STP).
• O Sistema Toyota de Produção (STP) surgiu com 2 (dois) princípios básicos:
• Just-in-time
• Produção de acordo com a demanda (eliminação de estoques desnecessários e
aumento da produtividade).
• Jidoka
• Automação com toque humano.
• Princípios superiores incluídos na filosofia Toyota (Toyota Way):
• Respeito pelas pessoas.
• Ir ao local onde o trabalho é realizado (Gemba).
• Melhoria contínua.
Lean Thinking (Mentalidade Lean)
• Lean Thinking (Mentalidade
Lean)
• Filosofia para aumentar a
satisfação dos clientes por
meio da melhor utilização
dos recursos.

• 5 Princípios da Filosofia Lean

Thinking
Lean Thinking (Mentalidade Lean)
• Lean Thinking (Mentalidade Lean)
• Filosofia para aumentar a satisfação dos clientes por meio da melhor utilização dos
recursos.

• 5 Princípios da Filosofia Lean Thinking

• Valor
• Princípio Lean que representa os requisitos (exigências) do cliente em relação ao
produto ou serviço entregue.
• É aquilo que o cliente quer e está disposto a pagar.
• Identificar o que é valor para o cliente é o ponto de partida.
• Utiliza-se a Voz do cliente (Voice of Customer).
• Voz do cliente é a representação dos requisitos (exigências) e desejos do cliente.
 Lean Thinking (Mentalidade Lean)
• Valor
• Representa os requisitos (exigências) do cliente em relação ao produto ou serviço entregue.
• É aquilo que o cliente quer e está disposto a pagar. Identificar o que é valor para o cliente é o ponto de
partida. Utiliza-se a Voz do cliente (Voice of Customer).
• Fluxo de Valor
• Representa todas as etapas necessárias para viabilizar um produto ou serviço, desde a concepção até a
entrega ao cliente, incluindo todos os fluxos de informação, trabalho e materiais.
• Reduzir as atividades que geram desperdícios e aumentar as atividades que agregam valor.
• Fluxo Contínuo
• Atividades devem seguir umas às outras com o mínimo de interrupções e sem estoques intermediários. É
necessário eliminar os desperdícios.
• Sistema de Produção Puxado (Pull)
• Fazer o que é necessário quando necessário, produzindo apenas o que o cliente comprou, reduzindo ao
máximo o estoque.
• Perfeição
• Princípio Lean que visa fazer as coisas certas da primeira vez. Busca pela Melhoria Contínua.
Mapeamento de Fluxo de Valor
• Mapeamento de Fluxo de Valor
• O Mapeamento do Fluxo de Valor exibe o fluxo de trabalho e informações, ao longo de todo o
processo.
• O Mapeamento do Fluxo de Valor é um método para analisar o estado atual e projetar o estado
futuro do processo.
• O Mapa de Fluxo de Valor ajuda a identificar os desperdícios do processo (8 tipos).
• Ajuda a equipe a enxergar o processo com um todo.
• Lead Time
• Tempo total transcorrido entre o momento em que o cliente pediu algo e o
momento em que é feita a entrega.
• Tempo Takt (Takt time)
• É o ritmo de produção necessária para acompanhar a demanda do cliente.
• SIPOC (Supplier, Input, Process, Output e Customer)
• Ferramenta utilizada no Mapeamento do Fluxo de Valor
• Método que fornece uma visão de alto nível do processo.
• É utilizado para definir o escopo de um fluxo de valor a ser melhorado.
• É uma ferramenta para compreender os desperdícios e oportunidades de melhoria em um
processo.
Mapeamento de Fluxo de Valor

• Valor agregado
• Atividades que geram valor na perspectiva do cliente.

• Sem valor agregado mas necessárias

• Atividade que não agregam valor na perspectiva do cliente, mas que são necessárias.

• Sem valor agregado

• Atividades que não geram valor na perspectiva do cliente.
Desperdício

• Desperdício
• É o trabalho que consome recursos sem agregar valor.
• Três práticas que causam desperdício (três Ms).
• Mura
• Irregularidade e variabilidade.
• Muri
• Sobrecarga (excesso).
• Muda
• Desperdício (8 tipos).
Desperdício
• 8 (oito) tipos de desperdício em TI
• Produção em excesso
• Excesso de e-mails, relatórios, alertas do sistema que não são lidos ou que são ignorados.
• Estoque
• Hardware e licenças de softwares não utilizadas.
• Movimentação
• Movimentação desnecessária de pessoas.
• Espera
• Tempo de espera, atrasos, tempo de respostas lentos, downtimes, etc...
• Transporte
• Movimentação de itens de trabalho e troca de informações entre departamentos.
• Excesso de Processamento
• Trabalho excessivo ou desnecessário.
• Defeitos
• Informações incorretas, extemporâneas ou confusas que resultem em decisões
inadequadas.
• Talento
• Subutilização de colaboradores.
Seis Sigma (Six Sigma)

• Seis Sigma (Six Sigma)

• Metodologia de melhoria de processo que visa reduzir a variabilidade e eliminar defeitos no
processo.

Kaizen

• Kaizen
• Termo de origem japonesa que significa melhoria continua utilizando pequenas mudanças
incrementais.
Kaizen
• Tipos de Kaizen
• Kaizen Sistêmico
• Melhoria do fluxo de valor.
• Tem por objetivo melhorar o fluxo de trabalho e de informações. Além de eliminar a
sobrecarga e variação.
• Kaizen de Processo
• É o tipo de Kaizen que concentra-se em reduzir os desperdícios em áreas específicas
dentro do fluxo de valor (eliminação de desperdícios).
• Kaizen Diário
• Tipo de melhoria espontânea feita quando se identifica uma necessidade.
• Eventos Kaizen
• Esforços de melhoria no curto prazo que, em geral, envolvem uma equipe
multifuncional e duram de três a cinco dias.
• Kaikaku
• Iniciativa estratégica que visa obter uma melhoria radical (um grande salto) em oposição
a uma melhoria gradual e contínua (Kaizen).
Ferramentas
• Ciclo de Deming (PDCA)
• É a principal ferramenta utilizada para
melhoria continua.
• Planejar, Fazer, Verificar e Agir

• Metodologia DMAIC (Define, Measure, Analyze,

Improve and Control)
• Ferramenta utilizada para Solução de
Problemas.
• Definir, medir, analisar, melhorar e controlar.
• 5S
• Método de organização do local de trabalho.
• Separar (Seiri), Organizar (Seiton), Limpar
(Seisou), Padronizar (Seiketsu), Disciplina
(Shitsuko)
Ferramentas

• Diagrama de Ishikawa
• Diagrama de causa e efeito (espinha de peixe).
• 5 Porquês
• Método eficaz de análise da causa raiz.
• A3
• Ferramenta de análise e solução de problemas baseada na utilização de uma
única folha de papel.
• Benchmarking
• Prática que visa identificar e avaliar as melhores práticas dentro da
organização, assim como em outras organizações a fim de estimar o
desempenho e estabelecer alvos de melhoria e metas no longo prazo.
 Ferramentas

• Trabalho padronizado
• Define e documenta o
método mais eficiente de
realizar uma determinada
tarefa.

• Local de trabalho visual

• Torna o processo de TI, o
fluxo de informações e o
andamento dos projetos
visíveis para todos.
• Quadro Kanban.
Simulados

1. Selecione nas alternativas abaixo os 5 princípios do Lean Thinking (Mentalidade Lean).

a. Valor, Fluxo de Valor, Fluxo Contínuo, Produção Puxada e Perfeição

b. Desperdício, Fluxo de Falha, Gargalo, Produção Empurrada e Defeito
c. Valor, Fluxo de Falha, Fluxo Contínuo, Produção Empurrada e Defeito
d. Excesso, Fluxo de Falha, Fluxo Contínuo, Produção Empurrada e Retrabalho
Simulados

2. Selecione nas alternativas abaixo o princípio Lean que representa os requisitos (exigências) do
cliente em relação ao produto ou serviço entregue.

a. Perfeição
b. Fluxo
c. Valor
d. Fluxo de valor
Simulados

3. Qual das seguintes não é um dos 8 (oito) tipos de desperdício em TI?

a. Lucro
b. Produção em excesso
c. Espera
d. Defeitos
Simulados

4. Selecione nas alternativas abaixo o método que exibe o fluxo de trabalho e de informações, ao
longo de todo o processo e é utilizado para analisar o estado atual e projetar o estado futuro do
processo.

a. Mapeamento do Fluxo de Valor

b. PRINCE2
c. Estudo de Caso
d. Estatística
Simulados

5. Selecione nas alternativas abaixo o método que fornece uma visão de alto nível do processo e
é utilizado para definir o escopo de um fluxo de valor a ser melhorado.

a. 5S
b. PDCA
c. Diagrama de causa e efeito
d. SIPOC
Simulados

6. Selecione nas alternativas abaixo a iniciativa estratégica que visa obter uma melhoria radical (um
grande salto) em oposição a uma melhoria gradual e contínua.

a. Kaikaku
b. Kaizen
c. Kaizen sistêmico
d. Kaizen de processo
Simulados

7. Selecione nas alternativas abaixo como é chamado o tipo de Kaizen que concentra-se em reduzir
os desperdícios em áreas específicas dentro do fluxo de valor.

a. Kaizen blitz
b. Kaizen sistêmico
c. Kaizen diário
d. Kaizen de processo
Scrum Essentials
Objetivo do módulo
• Este módulo tem por objetivo preparar estudantes e profissionais de TI para realizar os exames
das certificações ITC-028 Scrum Essentials, ITC-035 Product Owner Foundation e ITC-036 Scrum
Master Foundation.
Introdução

• Scrum
• Scrum é um framework para desenvolver, entregar e manter produtos complexos.
• É um framework de desenvolvimento ágil com foco em entregas rápidas, incrementais e
relevantes largamente utilizado no desenvolvimento de software.
• Pilares (Pillars)
• Transparência (Transparency)
• Inspeção (Inspection)
• Adaptação (Adaptation)
• Valores do Scrum (Scrum Values)
• Comprometimento (Commitment)
• Coragem (Courage)
• Foco (Focus)
• Abertura (Openness)
• Respeito (Respect)
Framework Scrum

• Visão geral (Atividades e artefatos)

Eventos Scrum
• Sprints
• No Scrum, o trabalho é realizado por meio de Sprints.
• O trabalho realizado em cada Sprint deve criar algo de valor tangível para o cliente ou usuário.
• Sprints são iterações ou ciclos com time-boxed (duração fixa), ou seja, possuem datas de ínicio e fim fixadas,
geralmente com a mesma duração (geralmente de uma a quatro semanas).
• Uma vez que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada.
• Uma nova Sprint se inicia imediatamente após a conclusão da Sprint anterior.
• A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto (mudanças de mercado ou tecnologia).
• A Sprint poderá ser cancelada caso a meta da Sprint perca o sentido ou se torne obsoleta.
• Somente o Product Owner tem a autoridade para cancelar uma Sprint.
 Eventos Scrum

• Cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa.

• O Scrum prescreve quatro eventos formais para inspeção e adaptação:

• Planejamento da Sprint (Sprint Planning)

• Scrum Diário (Daily Scrum)

• Revisão da Sprint (Sprint Review)

• Retrospectiva da Sprint (Sprint Retrospective)

Eventos Scrum

• Grooming do Product Backlog (Product Backlog Grooming)

Eventos Scrum

• Grooming do Product Backlog (Product Backlog Grooming)

• Atividade de criar e refinar os itens do Product Backlog, estimando e priorizando-os.
Eventos Scrum

• Planejamento da Sprint (Sprint Planning)

 Eventos Scrum
• Planejamento da Sprint (Sprint Planning)
• É a primeira atividade em uma Sprint. É um evento time-boxed com no máximo 8 horas de
duração para uma Sprint de um mês de duração.
• São reuniões que acontecem no início de cada Sprint, na qual o Product Owner, o Time de
Desenvolvimento e o Scrum Master se reunem para determinar, planejar e priorizar os itens do
Product Backlog que serão desenvolvidos na Sprint que vai começar.
• Atividade na qual o Product Owner e o Time de Desenvolvimento definem a Meta da Sprint
(Sprint Goal).
• Entradas (inputs)
• Sprint Goal Inicial (Resumo de alto nível do objetivo que o Product Owner gostaria de alcançar
durante o Sprint).
• Restrições.
• Velocidade e Capacidade do Time de Desenvolvimento.
• Product Backlog.
• Saídas (outputs)
• Meta do Sprint (Sprint Goal) e Sprint Backlog.
Eventos Scrum

• Planejamento da Sprint (Sprint Planning) – Entradas e Saídas

Eventos Scrum

• Scrum Diário (Daily Scrum)

Eventos Scrum
• Scrum Diário (Daily Scrum)
• Reuniões diárias que tem por objetivo disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
• São reuniões rápidas que devem durar no máximo 15 (quinze) minutos.
• Essa atividade de inspeção e adaptação é algumas vezes chamada de Daily stand-up, por conta
da prática comum dos participantes ficarem de pé durante a reunião para incentivar que ela
seja breve.
• A Reunião Diária deve ser realizada no mesmo horário e local todos os dias a fim de reduzir a
complexidade.
• Portanto, todo dia, no mesmo horário, o Time de Desenvolvimento e o Scrum Master se reúnem
e respondem à três perguntas:
• O que foi feito desde a última reunião?
• O que será feito até a próxima reunião?
• Existe algum impedimento?
• O Scrum Master é responsável por remover os impedimentos.
• Impedimentos são os problemas que surgem durante a Sprint e que impedem a equipe de
trabalhar.
Eventos Scrum

• Execução da Sprint (Sprint Execution)

Eventos Scrum
• Execução da Sprint (Sprint Execution)
• É o trabalho que a equipe Scrum realiza para alcançar a Meta da Sprint (Sprint Goal).
• Atividade de maior duração em uma Sprint.
• Durante a Execução da Sprint os membros do Time de Desenvolvimento se auto-organizam e
determinam a melhor maneira de atender o objetivo estabelecido durante o Planejamento
da Sprint (Sprint Planning).
• O Scrum Master participa como coach, facilitador e removedor de impedimentos, fazendo o
que for necessário para ajudar a equipe a realizar o trabalho.
• Entradas (inputs):
• Sprint Goal e Sprint Backlog que foram gerados durante o Planejamento da Sprint (Sprint
Planning).
• Saídas (output):
• Um Incremento potencialmente entregável do produto.
Eventos Scrum

• Execução da Sprint (Sprint Execution) – Entradas e Saídas

Eventos Scrum
• Revisão da Sprint (Sprint Review)
 Eventos Scrum
• Revisão do Sprint (Sprint Review)
• Penúltima atividade em uma Sprint.
• Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês.
• Reunião na qual o Time de Desenvolvimento apresenta ao Product Owner e à todas partes
interessadas (stakeholders internos e externos) o que foi realizado durante a Sprint.
• O objetivo dessa atividade é inspecionar o produto ou a funcionalidade desenvolvida e que
possa ser entregue (funcional).
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões
sobre o incremento.
Eventos Scrum

• Retrospectiva da Sprint (Sprint Retrospective)

Eventos Scrum

• Retrospectiva da Sprint (Sprint Retrospective)

• Última atividade de uma Sprint.
• Esta é uma reunião de no máximo 3 horas para uma Sprint de um mês.
• Reunião de inspeção e adaptação realizada no final de cada Sprint a fim de rever o processo e
identificar oportunidades de melhoria continua.
• A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e
criar um plano para melhorias a serem aplicadas na próxima Sprint.
• A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da
próxima Sprint.
Papéis no Scrum
Papéis

• Time Scrum
• Product Owner
• Time de Desenvolvimento
• Scrum Master
• Times Scrum são auto-organizáveis e multifuncionais.
• Auto-organizáveis
• Escolhem a melhor forma para realizarem o trabalho.
• Multifuncionais
• Possuem todas as competências necessárias para realizar o trabalho.
• Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades
para feedback.
• O modelo de time no Scrum é projetado para otimizar a flexibilidade, criatividade e
produtividade.
Papéis
• Product Owner
• O Product Owner representa os interesses de todos os envolvidos (Stakeholders), define as funcionalidades do
produto e prioriza os itens de Product Backlog.
• É responsável por transformar a visão do produto em um Backlog.
• O Product Owner é a pessoa responsável por gerenciar o Backlog do Produto (Product Backlog).
• É responsável por garantir que o Backlog do Produto (Product Backlog) seja visível, transparente e claro para
todos.
• É o responsável por definir os critérios de aceitação dos itens do Product Backlog e confirmar se eles foram
atendidos.
• Precisa compreender o negócio, o mercado e o cliente.
• É responsável por maximizar o valor do produto.
• O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar o desejo de um comitê no
Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem
endereçá-la ao Product Owner.
• É responsável por otimizar o valor do trabalho que o Time de Desenvolvimento realiza.
• Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob
influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.
 Papéis
• Scrum Master
• Papel que tem por objetivo ajudar a todos os envolvidos entenderem e abraçarem as regras, práticas e os valores
do Scrum. (Ajuda o Time Scrum a entender as regras, práticas e valores do Scrum.)
• É o papel responsável por remover impedimentos que possam inibir a produtividade do time de
desenvolvimento.
• É responsável por proteger a equipe de interferências externas.
• Não é um Gerente de Projetos.
• O Scrum Master é um líder-servo (servant-leader) para o Time Scrum. Age como um Coach.
• É um Agente de Mudanças. É um Facilitador.
• É responsável por facilitar os eventos quando requeridos ou necessários.
• É responsável por assegurar que os eventos (reuniões) ocorram e que os participantes entendam o seu propósito.
• Garantir que o Scrum é entendido e adotado corretamente.
• Ajuda a organização na adoção do Scrum.
• Promove mudanças que aumentem a produtividade do Time de Desenvolvimento.
• Trabalham com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.
• O Scrum Master trabalha com o Product Owner e o Time de Desenvolvimento para aumentar a transparência dos
artefatos.
• O Scrum Master ensina o Time de Desenvolvimento a manter a reunião dentro do time-box.
Papéis
• Time de Desenvolvimento
• O Time de Desenvolvimento é responsável pelo desenvolvimento do produto.
• O Time de Desenvolvimento é responsável por tornar os itens do Product Backlog em incrementos
potencialmente entregáveis do produto.
• O Time de Desenvolvimento é composto por 3 a 9 pessoas.
• O Time de Desenvolvimento é autônomo e determina a melhor maneira de realizar o trabalho.
• O Time de Desenvolvimento é multifuncional. Os membros do time de desenvolvimento devem possuir
coletivamente todas as habilidades necessárias para realizar o trabalho.
• Times de Desenvolvimento são auto-organizados e se autogerenciam. Ninguém diz ao Time de Desenvolvimento
como transformar o Backlog do Produto em incrementos de funcionalidade potencialmente entregáveis.
• O Time de Desenvolvimento é responsável pelo gerenciamento do progresso do trabalho durante uma Sprint.
• É responsável por estimar os itens do Backlog do Produto (Product Backlog).
• Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint.
Artefatos

• Backlog do Produto (Product Backlog)

• É uma lista priorizada de funcionalidades desejadas do produto.
• O Product Backlog é um artefato em constante evolução. Itens podem ser adicionados,
removidos ou revisados pelo Product Owner à medida que as condições de negócio mudem,
ou à medida que o entendimento da equipe sobre o produto aumente.
Artefatos

• Backlog da Sprint (Sprint Backlog)

• Lista de itens extraídos do Product Backlog e trazidos para a Sprint - frequentemente
expressados em termos de tarefas que são estimadas em horas ideais.
• O Sprint Backlog é criado durante o Planejamento da Sprint.
Artefatos
• Incremento Potencialmente Entregável do Produto (Potentially Shippable
Product Increment)
• É o resultado da Sprint.
• Produto ou funcionalidade concluída de acordo com a definição de pronto.
• Definição de Pronto (Definition of Done)
• Checklist de tipos de trabalho que se espera que a equipe tenha completado com
sucesso antes de declarar seu trabalho como potencialmente entregável.
Ferramentas

• Comunicação
• A maioria dos times de desenvolvimento utiliza como irradiador de informações uma
combinação de um Quadro de Tarefas e um Gráfico de Burndown.
Ferramentas
• Comunicação
• Quadro de Tarefas (Kanban Board)
• Quadro utilizado para tornar o trabalho visível e comunicar o progresso.
• O quadro tem por objetivo mostrar todo o trabalho que precisa ser feito, o que está
sendo feito e o que já foi feito.
Ferramentas
• Comunicação
• Gráfico de Burndown (Sprint Burndown Chart)
• Gráfico que mostra o andamento do Sprint através dos pontos que devem ser entregues
no final da Sprint (Planejado x realizado)
• Diariamente o Scrum Master calcula os números de pontos realizados e acrescenta essa
informação ao gráfico. O ideal é que haja uma linha íngreme descendo em direção a zero
ponto restante no último dia do Sprint.
• Utilizado para se assegurar que as Sprints estão sendo cumpridos dentro do prazo
previsto.
Simulados

1. Selecione nas alternativas abaixo como são chamadas as iterações ou ciclos de até um mês de
duração.

a. Sprint
b. Backlog
c. Scrum Diário (Daily Scrum)
d. Feedback
Simulados

2. Selecione nas alternativas abaixo a atividade na qual o Product Owner, o time de

desenvolvimento e o Scrum Master se reunem para determinar e priorizar os itens do Product
Backlog que serão desenvolvidos no Sprint que vai começar.

a. Retrospectiva do Sprint (Sprint Retrospective)

b. Execução do Sprint (Sprint Execution)
c. Revisão do Sprint (Sprint Review)
d. Planejamento do Sprint (Sprint Planning)
Simulados

3. Selecione nas alternativas abaixo a melhor definição para Product Backlog.

a. Uma atividade de inspeção e adaptação realizada ao final de cada sprint.

b. Uma lista priorizada de funcionalidades desejadas do produto.
c. Os testes realizados para verificar se os critérios de aceitação foram atendidos.
d. Ciclo de desenvolvimento.
Simulados

4. Selecione nas alternativas abaixo as saídas (outputs) da atividade Planejamento do Sprint (Sprint
Planning).

a. Incremento potencialmente entregável do produto e Meta do Sprint (Sprint Goal)

b. Meta do Sprint (Sprint Goal) e Sprint Backlog
c. Incremento potencialmente entregável do produto e Sprint Backlog
d. Conjunto de ações de melhoria e incremento potencialmente entregável do produto
Simulados

5. Selecione nas alternativas abaixo a saída (output) da atividade Execução do Sprint (Sprint
Execution).

a. Insight Backlog
b. Meta do Sprint (Sprint Goal)
c. Sprint Backlog
d. Incremento potencialmente entregável do produto
Simulados

6. Como são chamados os textos geralmente curtos e simples que descrevem as funcionalidade
desejadas de um produto na visão do usuário?

a. Histórias
b. Insights
c. Critérios
d. Regras
Simulados

7. Selecione nas alternativas abaixo o responsável por facilitar os eventos Scrum conforme
necessário.

a. Stakeholders
b. Product Owner
c. Gerente de Projeto
d. Scrum Master
Simulados

8. Retrospectiva da Sprint é uma oportunidade para a equipe se auto avaliar e criar um plano de
melhorias para a próxima Sprint.

a. Verdadeiro
b. Falso
Simulados

9. Selecione nas alternativas abaixo qual deve ser a duração máxima de uma Sprint de acordo com o
Guia Scrum.

a. 1 mês
b. 3 meses
c. 6 meses
d. 12 meses
Simulados

10. Selecione nas alternativas abaixo o papel responsável por transformar a visão do produto em
um Backlog do Produto (Product Backlog).

a. Time de Desenvolvimento
b. Scrum Master
c. Product Owner
d. Gerente de Projeto
Simulados

11. Selecione nas alternativas abaixo a duração de uma reunião de Revisão da Sprint.

a. 4 horas para uma Sprint de um mês de duração

b. 6 horas para uma Sprint de um mês de duração
c. 2 horas para uma Sprint de um mês de duração
d. 10 horas para uma Sprint de um mês de duração
Simulados

12. Pode-se afirmar que o Scrum Master atua como um Gerente de Projeto.

a. Verdadeiro
b. Falso
DevOps Essentials
Objetivo do módulo
• Este módulo tem por objetivo preparar estudantes e profissionais de TI para realizar o exame da
certificação ITC-021 DevOps Essentials.
Introdução a DevOps

• Desenvolvimento e Operações de TI são duas áreas tradicionalmente distintas com motivações

diferentes.

• A área de Desenvolvimento já evoluiu bastante com a adoção de metodologias ágeis e já está

mais alinhada ao negócio realizando entregas rápidas e constantes para atender a expectativa
dos clientes por novos recursos.

• A área de Operações de TI, por sua vez, deseja o mínimo de alterações possíveis no ambiente de
produção, a fim de gerar possíveis pontos de instabilidade.

• O objetivo da cultura DevOps é justamente remover as barreiras entre duas áreas

tradicionalmente separadas em silos: desenvolvimento e operações de TI.
Introdução a DevOps

• DevOps é uma abordagem que tem por objetivo promover maior alinhamento e colaboração
entre as áreas de desenvolvimento e operações de TI reduzindo o tempo no lançamento de
novas versões e funcionalidades.

• A cultura DevOps enfatiza melhor comunicação, maior colaboração e integração entre as áreas
de desenvolvimento e operações de TI.
Introdução a DevOps

• DevOps é um conceito no qual as tarefas desempenhadas pelas áreas de desenvolvimento e

operações de TI devem ser pensadas de uma maneira integrada.

• DevOps é resultado dos esforços das empresas para responder com rapidez às mudanças do
mercado, cada vez mais dinâmico e concorrido, sem que o relacionamento entre as áreas de
desenvolvimento e operações de TI seja prejudicado.

• Surgiu à partir de uma necessidade fundamental: simplificar os negócios por meio de esforços
coordenados e colaborativos.

• Em um cenário de mercado que exige cada vez mais agilidade, produtividade e eficiência nos
negócios, muitas empresas vêm implantando DevOps como forma de modernizar suas práticas de
TI.
Introdução a DevOps

• O foco é a integração contínua, o compartilhamento de atribuições e decisões entre as áreas de

desenvolvimento e operações de TI e também o emprego de ferramentas que promovam a
automação da configuração da infraestrutura de TI, além de controle de versão e automatização
do código para deployment.

• A cultura DevOps sustenta-se nos seguintes pilares:

• Integração Contínua: fácil transferência de conhecimento e experiências entre as áreas de
desenvolvimento e operações de TI.
• Implantação Contínua: liberação rápida e continua de novas versões de software ou serviços.
• Feedback contínuo: feedbacks frequentes das equipes envolvidas em todas as fases do ciclo
de vida do software ou serviço.
Introdução a DevOps
• História do surgimento do movimento DevOps
• Manifesto Ágil em 2001.
• Surgimento do termo Infraestrutura ágil em 2008.
• Realização da apresentação 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (John
Allspaw & Paul Hammond) durante a conferência O'Reilly Velocity em Junho de 2009.
• O termo DevOps foi cunhado por Patrick Debois, entusiasta do assunto e criador do evento
DevOpsDay – Ghent, Bélgica em Outubro de 2009.
• Nos anos seguintes foram realizadas novas edições do evento em diversas localidades
(Sydney, Mountain View, Hamburg, São Paulo, entre outras cidades). https://www.devopsdays.org
• Dissiminação da cultura DevOps ao redor do mundo (Meetups, conferências, blogs,
comunidades, grupos de discussão, etc...).
• Formalização de práticas e surgimento de ferramentas.
• Crescimento do interesse por parte das empresas.
• Publicação do relatório State of DevOps Report (Puppet Labs)
• Disponível em https://puppet.com/resources/whitepaper/state-of-devops-report
Características da cultura DevOps
• Em um dos seus artigos, John Willis, um dos precursores do DevOps, escreveu em 2010 dizendo
que, baseado em sua experiência e observação, DevOps era sobre CAMS, um acrônimo em Inglês
para Cultura, Automação, Medição/Avaliação e Compartilhamento.

• CAMS é basicamente os eixos do DevOps:

Culture Automation Measurement Sharing

Cultura Automação Avaliação/Medição Compartilhamento
Características da cultura DevOps
Cultura
• 4 eixos
• Cultura • Avaliação
• Colaboração; • Métricas; Avaliação Automação
• Medições; DevOps
• Fim das divisões;
• Relação saudável entre as áreas; • Performance;
• Mudança de comportamento. • Logs e integração;
Compartilhamento

• Automação • Compartilhamento
• Deploy; • O feedback é tudo;
• Controle; • Boa comunicação entre a equipe.
• Monitoração;
• Gerência de configuração;
• Orquestração.
Características técnicas de um ambiente DevOps

• Valores humanos (Pilares Cultura e Compartilhamento)

• Confiança no trabalho da equipe;
• Respeito pessoal e profissional por parte de todos os membros da equipe;
• Sinceridade sobre eventos e incidentes ocorridos;
• Honestidade sobre as causas dos incidentes;
• Entendimento de que o problema é responsabilidade de todos;
• Entendimento de que a solução dos problemas é responsabilidade de todos;
• Entendimento de que os resultados são o reflexo do trabalho de toda a equipe;
• Comunicação efetiva e dinâmica;
• Postura construtiva;
• Espírito de colaboração.
Características técnicas de um ambiente DevOps
• Infraestrutura como Código (IaC)
• Controle de versões compartilhado entre infraestrutura e desenvolvimento;
• Ambiente de desenvolvimento, teste e produção (no mínimo);
• Desenvolvimento deve possibilitar TDD (Test Driven Development) - Desenvolvimento Orientado a
Testes;
• Infra deve participar dos projetos desde o início;
• Infra deve participar das reuniões de desenvolvimento;
• Desenvolvimento deve participar das reuniões de infraestrutura;
• Os desenvolvedores devem conseguir fazer o deploy sem interferência da infraestrutura;
• Ambiente de entrega contínua;
• Monitoramento eficaz com processamento adequado dos eventos e métricas;
• Capacidade de resposta rápida a incidentes e problemas;
• Backup e restore confiável.
Infraestrutura Ágil / Infraestrutura como Código (IaC)
• Infraestrutura ágil faz parte da cultura DevOps;
• Virtualização e Computação em Nuvem possibilitaram o advento da prática de IaC
• A IaC é uma prática em que a infraestrutura é provisionada e gerenciada usando técnicas de
desenvolvimento de software.
• Modelo de Trabalho para Equipes que trabalham com IaC:
• Provisionamento Automático de Servidores / Gerência de Configurações e Orquestração;
• Versionamento do código e arquivos de configuração (Git);
• Organização de atividades (fluxo de trabalho) de forma visual (Kanban Board);
• Automação de Testes;
• Pipeline de entrega contínua;
• Rollback Automatizado
• Divisão das atividades em sprints;
• Reuniões ágeis diárias e periódicas (retrospectiva e planejamento de sprints) ;
• Colaboração.
Integração Contínua, Entrega Contínua e Implantação Contínua

A Integração Contínua tem por objetivo identificar e corrigir erros mais

rapidamente, melhorar a qualidade do software e reduzir o tempo necessário
para validar e lançar novas atualizações de software. As alterações de código são
criadas, testadas e preparadas automaticamente antes de serem liberadas para a
produção.

A Entrega Contínua é um onjunto de práticas que tem como objetivo garantir

que alterações ou novas versões de software possam ser colocadas no ambiente
de produção a qualquer momento.

A Implantação Contínua é uma espécie de extensão da integração contínua, com

o objetivo de minimizar o lead time em produção realizando deploys automáticos
em produção.
Benefícios da adoção da cultura DevOps
• Melhor comunicação e maior colaboração entre as áreas de desenvolvimento e infraestrutura
(diminuição de conflitos);

• Aumento da produtividade com entregas de qualidades e com maior frequência;

• Mudanças passam a levar menos tempo entre a concepção e a produção reduzindo também as
falhas;

• Maior estabilidade e melhor desempenho com menor tempo de paradas;

• Diminuição de Incidentes, custos e riscos aumentando o valor do negócio.

• Empresas que adotam a cultura DevOps implantam atualizações com uma frequência muito
maior do que as que utilizam práticas de desenvolvimento de software tradicionais.
Benefícios da adoção da cultura DevOps

• Benefícios da adoção da filosofia DevOps para a área de infraestrutura

• Infraestrutura mais eficiente e rápida usando métodos ágeis;

• Equipe de Infraestrutura mais organizada e se comunicando melhor;

• Infraestrutura Ágil: Ambientes de gerência de configuração, orquestração e provisionamento

implantados;

• Deploys de infraestrutura (novos ambientes) mais rápidos e seguros => entrega rápida;

• Ambiente padronizado e sob-controle;

• Feedback rápido em todas as atividades de Infraestrutura.

Benefícios da adoção da cultura DevOps

• Benefícios da adoção da filosofia DevOps para a área de desenvolvimento

• Desenvolvimento passa a ter ambiente mais adequado para trabalhar
(desenvolvimento/teste/produção);

• Desenvolvimento passa a contar com ambiente de desenvolvimento contínuo;

• Desenvolvimento passa a contar com testes automatizados;

• Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida;

• Feedback rápido em todas as fases de desenvolvimento.

Ferramentas de Infraestrutura Ágil
• A adoção de ferramentas tem por objetivo automatizar tarefas manuais e ajudar as equipes a
gerenciarem ambientes complexos em escala. Principais ferramentas utilizadas:

• Sistemas de controle de versões

• Ferramentas que atuam como um repositório central de código e mantêm
um histórico de todas as mudanças feitas nos sistemas;
• Git (Sistema de controle de versão distribuído largamente utilizado).

• Integração Contínua
• Jenkins

• Gerenciador de containers
• Ferramentas criadas com o objetivo de facilitar o desenvolvimento,
a implantação e a execução de aplicações em ambientes isolados;
• Docker (Plataforma open source largamente utilizada).
Ferramentas de Infraestrutura Ágil

• Gerência de configuração e automação (também chamadas de ferramentas de orquestração)

• Puppet, Chef e Ansible

• Ferramentas de Monitoração
• As empresas monitoram métricas e logs para verem como o desempenho do aplicativo e da
infraestrutura afeta a experiência do usuário final do seu produto.
• Ao capturar, categorizar e analisar dados e logs gerados pelos aplicativos e pela infraestrutura, as
empresas compreendem como as alterações ou atualizações afetam os usuários, o que proporciona um
esclarecimento sobre a causa raiz dos problemas ou das alterações inesperadas.
• A criação de alertas ou a execução de análise em tempo real desses dados também ajuda as empresas a
monitorar de modo mais proativo seus serviços.
• Nagios e Zabbix
DevSecOps

• Evolução do movimento DevOps que visa envolver os times de segurança da informação em todas
as etapas do desenvolvimento de aplicações.
Outros conceitos importantes relacionados a DevOps

Mudar Melhor

Melhoria Contínua

Lean IT Scrum Kaizen

Outros conceitos importantes relacionados a DevOps
• Lean IT
• A filosofia Lean IT tem por objetivo eliminar atividades desnecessárias, reduzir custos,
agregar valor e aumentar a satisfação dos clientes, promovendo maior eficiência e a melhoria
contínua dos serviços de TI, com ênfase no envolvimento dos colaboradores na otimização
dos processos de negócios da organização.
• Principais benefícios da adoção da filosofia Lean IT:
• Simplicação dos processos;
• Processos mais enxutos;
• Redução dos desperdícios;
• Redução de silos de informação;
• Maior eficiência;
• Maior produtividade
• Melhoria contínua dos serviços de TI;
• Maior valor para os clientes;
• Maior satisfação dos clientes.
Outros conceitos importantes relacionados a DevOps

• Kaizen
• Palavra de origem japonesa que significa mudança para melhor;
• Melhoria contínua;
• Visa melhorar o fluxo de valor do produto como um todo e reduzir desperdícios.

• Scrum
• Metodologia ágil largamente utilizada no desenvolvimento de software.
Considerações finais

• DevOps está diretamente relacionado a uma melhor comunicação entre as áreas de

desenvolvimento e infraestrutura.
• DevOps é um movimento, uma filosofia e uma cultura.
• DevOps tem por objetivo estabelecer mudanças rápidas e eficientes sem que o relacionamento
entre as áreas de desenvolvimento e operações de TI seja prejudicado.
• DevOps é adoção de metodologia ágil tanto na área de desenvolvimento quanto na área de
infraestrutura.
• DevOps só funciona se as equipes de desenvolvimento e infraestrutura estiverem dispostas a
mudar e incorporar novos métodos de trabalho.
• DevOps não é um departamento dentro da organização, mas sim uma cultura.
• DevOps não está restrito somente às startups ou pequenas empresas.
• DevOps oferece inúmeras oportunidades de carreira.
Simulados

1. Selecione nas alternativas abaixo os quatro eixos do movimento DevOps.

a. Cultura, Automação, Medição e Falta de Colaboração

b. Cultura, Processos Manuais, Falta de Medição e Compartilhamento
c. Cultura, Automação, Medição e Compartilhamento
d. Cultura, Processos Manuais, Medição e Falta de Colaboração
Simulados

2. Selecione nas alternativas abaixo os principais tipos de ferramentas de infraestrutura ágil:

a. Orquestradores, Ferramentas de gerencia de configurações e Ferramentas de provisionamento

b. Processadores, Ferramentas de gerenciamento de conteúdo e Ferramentas de gerencia de redes
c. Orquestradores, Ferramentas de gerenciamento de projeto e Ferramentas de gerencia de
aprendizagem
d. Temporizadores, Ferramentas de gerenciamento de aprendizagem e Ferramentas de
provisionamento
Simulados

3. Selecione nas alternativas abaixo o nome das ferramentas que atuam como um repositório
central de código e mantêm um histórico de todas as mudanças feitas no seu sistema.

a. Sistemas distribuídos
b. Sistemas de controle de versões
c. Sistemas operacionais
d. Sistemas de informações gerenciais
Simulados

4. Selecione nas alternativas abaixo os elementos do eixo Automação do movimento DevOps.

a. Métricas, medições, performance, logs e integração

b. Deploy, controle, monitoração, gerência de configuração e orquestração
c. Colaboração, fim das divisões, relação saudável entre as áreas e mudança de comportamento
d. Feedback e comunicação
Introdução a Site Realibility Engineering (SRE)
Introdução a SRE

• Site Reliability Engineering (SRE) é um termo (e uma função) criado por Ben Treynor Sloss, VP de
Engenharia do Google.
• O foco do SRE está na confiabilidade do sistema (system reliability). Segundo Treynor,
confiabilidade é a característica mais importante de qualquer produto.
• Os SREs estão focados em encontrar maneiras de melhorar o design e a operação dos sistemas
para torná-los mais escaláveis, mais confiáveis e mais eficientes.
• “SRE is what happens when you ask a software engineer to design an operations team.” Ben
Treynor Sloss
Introdução a SRE

• Em geral, um time de SRE é responsável pela disponibilidade, latência, desempenho, eficiência,

gerenciamento de mudanças, monitoramento, resposta de emergência e planejamento da
capacidade de seus serviços.
• Tradicionalmente, os times de SRE gastam 50% do tempo resolvendo tickets e atuando em
atividades operacionais e 50% do tempo desenvolvendo ferramentas para automatizar as
atividades.
 7 Princípios (7 Principles)
• Aceitar o risco (Embracing Risk)
• Gestão de Risco (Managing Risk)
• Tolerância ao risco de serviço (Risk Tolerance of Services)
• Meta do nível de disponibilidade (Target level of availability)
• Objetivos do Nível de Serviço (Service Level Objectives (SLOs))
• Indicadores e métricas para medir o serviço prestado
• SLIs (Service Level Indicators)
• SLOs (Service Level Objectives)
• SLAs (Service Level Agreements)
• Error Budget
• Eliminar trabalho repetitivo ou desnecessário (Eliminating Toil)
• Tarefas manuais (manuals), repetitivas (repetitives), automatizáveis (automatable), táticas
(tactical) e sem valor a longo prazo (no enduring value).
 7 Princípios (7 Principles)
• Monitorar Sistemas Distribuídos (Monitoring Distributed Systems)
• Monitoring, White-box monitoring, Black-box monitoring, Dashboard, Alert, Root cause, Node and
Machine e Push.
• Quatro sinais de ouro (The four Golden signals)
• Latência (Latency)
• Tráfego (Traffic)
• Erros (Errors)
• Saturação (Saturation)
• Automação (Automation)
• Valor da automação (The value of automation)
• Consistência (Consistency)
• Uma Plataforma (A Platform)
• Reparos mais rápidos (Faster repairs) - Mean Time to Repair (MTTR)
• Ação mais rápida (Faster action)
• Economia de tempo (Time saving)
 7 Princípios (7 Principles)
• Engenharia de Release (Release Engineering)
• Princípios (Principles)
• Self-service model
• Alta velocidade (High velocity)
• Builds Herméticos (Hermetic Builds)
• Execução de Políticas e Procedimentos (Enforcement of Policies and Procedures)
• Simplicidade (Simplicity)
• Confiabilidade
 Práticas (Practices)
• Monitoração (Monitoring)
• Respostas a Incidentes (Incident Response)
• Being On-Call
• Effective Troubleshooting
• Emergency Response
• Incident Management
• Postmortem e Análise de Causa-Raiz (Postmortem and Root-Cause Analysis)
• Postmortem Culture: Learning from Failure
• Documentar o incidente, seus impactos, as ações tomadas para resolvê-lo, bem como suas causas-raízes
e as ações tomadas para se evitar que o incidente ocorra novamente.
• Testes (Testing)
• Planejamento da Capacidade (Capacity Planning)
• Desenvolvimento (Development)
• Produto (Product)
• Reliable Product Launches at Scale
Hierarquia da Confiabilidade de Serviços
(Service Reliability Hierarchy)
Para saber mais

• Site Reliability Engineering

• Edited by Betsy Beyer, Chris Jones, Jennifer
Petoff and Niall Richard Murphy
• https://landing.google.com/sre/books/
Referências bibliográficas
• BELL, S.C.; ORZEN, M.A. Capacitando e sustentando sua transformação lean. Lean Institute Brasil, 2013.
• Cloud Security Alliance Guidance v3. Disponível em
https://chapters.cloudsecurityalliance.org/brazil/files/2017/02/Guia-CSA-v-3.0.1-PT-BR-Final.pdf
• KIM, G.; BEHR, K.; SPAFFORD, G. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business
Win. Editora IT Revolution Press, 2014.
• KIM, G.; DEBOIS, P.; HUMBÇE, J.; WILLIS, J. The DevOps Handbook: How to Create World-Class Agility,
Reliability, and Security in Technology Organizations.Editora IT Revolution Press, 2016.
• LOUKIDES, M. What is DevOps? Editora O'Reilly Media, 2012.
• NIST Special publication 800-144 (Guidelines on Security and Privacy in Public Cloud Computing). Disponível
em http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf
• RUBIN, K.S. Scrum Essencial - Um Guia Prático Para o Mais Popular Processo Ágil. Editora Alta Books, 2017.
• SUTHERLAND, J. Scrum - A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. Editora Leya, 2016.
• WALLS, M. Building a DevOps Culture. Editora O'Reilly Media, 2013.