DevOps Professional

Módulo 2 - Adoção do DevOps

Adoção do DevOps 2
Negócio 2
Cliente 2
Fluxo 2
Feedback 3
Aprendizado e experimentação contínua 3
Como Aplicar as 3 práticas 3
A Primeira maneira: Fluxo (Flow) 3
Acelerar o Fluxo 4
Tornar o trabalho visível 5
Quadro kanban / tarefas 5
Gerenciar o trabalho em progresso (WIP - Working in progress) 6
Pequenos Lotes de trabalho - Reduzir o tamanho dos lotes e intervalos de
trabalho 6
Lotes pequenos e fluxo 7
Reduzir o número de transferência de trabalho (handoffs) 8
Exemplos para Reduzir o número de Transferências de trabalhos (handoffs) 8
Aplicar a teoria das restrições (gargalos) 8
Cinco etapas para remover restrições 9
Restrições típicas para uma transformação DevOps 10
Remover desperdícios 10
Exercício 11
A Segunda maneira: Feedback 12
Sistemas complexos 13
Conceitos 13
Ambiente de TI especificamente desenvolvimento e entrega de software
residem no conceito Complexo 13
Criando ambientes seguros 14
Revelando problemas à medida que ocorrem 15
Objetivo 15
Swarning 17
Resolvendo problemas coletivamente 18
Sistema Andon, da Toyota 18
Manter o controle de qualidade próximo da origem do trabalho 19
Otimizar o trabalho pensando nas próximas etapas 20
Aprendizado e experimentação contínua (continuous learning and experimentation) 21
O que mais impede a experimentação e aprendizagem organizacional? 21
As práticas da terceira maneira incluem: 22
Adoção do DevOps
Peso no exame: 3,75%
As três maneiras (three ways)
● Fluxo (Flow)
● Feedback
● Aprendizado e experimentação contínua (continuous learning and experimentation)

Negócio
Fornece os requisitos, desejos e problemas para serem criados software

Cliente
Se beneficia dos software que são criados

Fluxo
Permite o fluxo rápido da esquerda para a direita do trabalho de Desenvolvimento
para Operações e para o Cliente

Feedback
Permite o fluxo rápido e constante de feedback da direita para a esquerda em todos
os estágios do fluxo de valor
 Aprendizado e experimentação contínua
Possibilita a criação de uma cultura generativa e de alta confiança que suporta uma
abordagem dinâmica, disciplinada e científica para a tomada de riscos na
experimentação, facilitando a criação da aprendizagem organizacional

Como Aplicar as 3 práticas

Para que as 3 maneiras funcione precisa de:
● Mudança cultural e liderança
● Automatização

A Primeira maneira: Fluxo (Flow)

● O principal ponto por trás desse primeiro princípio é ter o trabalho fluindo da
esquerda para a direita o mais rápido possível
● A primeira maneira enfatiza o desempenho de todo o sistema, ao contrário do
desempenho de um silo específico de trabalho ou de um departamento
● Metas globais devem ser otimizadas em vez de metas locais
● O foco está em todos os fluxos de valor de negócio que são executados pela TI
Acelerar o Fluxo
Para acelerar o Fluxo, algumas práticas podem ser utilizadas:
● Tornar o trabalho visível
● Gerenciar o trabalho em progresso (WIP - Working in progress)
● Reduzir o tamanho dos lotes e intervalos de trabalho
● Reduzir o número de transferência de trabalho
● Aplicar a teoria das restrições (TOC)
● Remover desperdícios
Tornar o trabalho visível
Manufatura -> Trabalho é Visível
● Fábrica de carro você vê o carro sendo criado por exemplo
Software -> Trabalho é invisível
● Já no software você não tem a mesma visibilidade
○ Difícil visualizar o andamento dos trabalhos
○ Gargalos não são vistos com facilidade (filas se formam)
○ Trabalhos incompletos não são facilmente identificados
○ Retrabalhos e problemas de qualidade ficam “escondidos”
Para nos ajudar a ver onde o trabalho está fluindo bem e onde está na fila ou parado,
precisamos tornar nosso trabalho o mais visível possível

Quadro kanban / tarefas

● O trabalho se torna visível
● É possível gerir o fluxo de trabalho e leadtime
● Filas se tornam visíveis
● Quadro Kanban deveria exibir todo o fluxo de valor
● Stakeholders podem priorizar mais facilmente o trabalho no contexto de metas
globais
Gerenciar o trabalho em progresso (WIP - Working in progress)
● Multitarefa é nociva, pois causa perda de qualidade e de produtividade
● É possível limitar a multitarefa usando limites de WIP (Work in progress)
● WIP por si só não fornece nenhum valor
● É desejável ter pequenos pedaços de trabalho passando pelo fluxo da esquerda
para a direita o mais rápido possível (gerando valor)

No exemplo acima:
● Não é possível adicionar nenhuma nova tarefa em refinamento
● Podia mover 1 de refinamento para Desenvolvimento mas Desenvolvimento também
está no limite
● É possível trabalhar nos Em Testes, ajustar esse gargalo, mover para testado e aí
sim mover os anteriores
● Nesse exemplo, Ponto para Deploy está com gargalo, ou seja, mais do que deveria
estar.
○ Neste caso, é importante pensar em como corrigir. Usar o Infra As Code para
acelerar o deploy
Quando há o limite de WIP, você pode descobrir que não terá nada para fazer por que está
esperando outra pessoa
● Neste caso, é melhor tentar identificar onde está o gargalo e tentar ajudar a resolver
o problema.
● Trabalhar nas atividades em progresso é a melhor maneira de atuar quando não há
atividades na sua coluna

Pequenos Lotes de trabalho - Reduzir o tamanho dos lotes e intervalos de trabalho

● Lote de trabalho é a quantidade de trabalho que é passada de uma única vez para a
próxima etapa do processo. Tipicamente um fluxo interrompido trabalha com lotes
grandes
● Fluxo Interrompido - Trabalha com Lotes Grandes
 ○ Entre Análise dos Requisitos x Programação dos Requisitos e Teste dos
Requisitos 1 grande fica esperando para passar de uma Etapa para outra
○ Gerando gargalo e interrupção no processo
● Fluxo Contínuo - Trabalha com lotes pequenos
○ Fluxo contínuo consiste de identificar e eliminar as interrupções e os
estoques dentro do fluxo
○ Reduzir o trabalho em progresso (WIP)
○ Diminuir os Lotes de trabalho
○ Dessa forma a Redução do Lead Time é expressiva

Lotes pequenos e fluxo

Diferença entre utilizar Lotes pequenos x Lotes grandes
Cenário: Cada peça demora 1 minuto para ser processada por etapa
O objetivo é finalizar as 10 peças (passar pelas 5 etapas)
● Lotes Tradicionais
○ No Lote tradicional as 10 peças passam por etapas juntas
○ Se a cada etapa 10 minutos se passam, somando as etapas, 41 minutos
foram necessário para concluir a 1a peça
● One Piece Flow
○ No One Piece Flow, 1 lote corresponde a 1 peça, sendo assim não é
necessário esperar as 10 peças finalizarem cada etapa.
○ Nesse processo a 1a peça ficaria pronta em 5 minutos
○ As 10 peças ficam prontas em 14 minutos
○ Com lotes menores, o tempo de espera diminui e o tempo aceleram de forma
incrível
Reduzir o número de transferência de trabalho (handoffs)
● Handoff = quando um agente do processo passa o trabalho a outro agente
● Pesquisas mostram que as transações passam mais de 70% do tempo
simplesmente à espera de serem processadas
● As filas se formam em handoffs geralmente por que:
○ Os agentes não sincroniza o seu trabalho
○ Há inadequação da capacidade produtiva
○ Usa-se mais de um sistema de TI e não há integração entre eles
Ou seja
● Passar do Desenvolvimento para Teste
● Ou passar para equipe de Deploy
● OU passar para equipe de redes
● Transferências são potenciais filas
● Reduzir o número de transferências diminui evitar esperas

Exemplos para Reduzir o número de Transferências de trabalhos (handoffs)

● Automatização de processos
● Reorganização das equipes para que tenham autonomia e não dependam de outros
times

Aplicar a teoria das restrições (gargalos)

● Para reduzir o leadtime e aumentar a taxa de entrega (throughput), precisamos
identificar e remover continuamente as restrições do sistema
○ Supor que no Desenvolvimento de Software Teste está sendo o gargalo
○ O Desenvolvimento de novas funções e muita mais rápida que os testes
feitos
○ Não adianta desenvolver mais se não tratar o atraso nos Testes
● Em qualquer fluxo de valor, há sempre uma direção de fluxo e sempre á uma e
apenas uma restrição; qualquer melhoria feita que não seja feita nessa restrição é
uma ilusão
○ Ou seja, se não resolver o problema e lentidão do Teste, o fluxo continuará
travado
 ● Veja que a 3a etapa é o gargalo
● Uma etapa anterior tem até mais possibilidade de produção, porém, se você colocar
esforço ali você só aumenta o gargalo
● Observe onde está sua restrição/gargalo e atue nela

Cinco etapas para remover restrições

Para ajudar a remover as restrições, o Dr. Eliyahu Goldratt definir um método que ele
chamou de 5 passos de focalização
São diretrizes para impulsionar a melhoria contínua
1. Identificar a restrição
2. Explorar a restrição
3. Subordinar tudo à restrição
4. Aumentar a capacidade da restrição
a. Fazer investimento é nessa fase, contratar pessoas, etc
5. Não pare! Procure a próxima restrição
Restrições típicas para uma transformação DevOps
Em transformações típicas de DevOps, conforme a empresa progride de liberações de
muitos meses para poucas semanas, dias ou minutos, algumas restrições típicas surgem e
devem ser tratadas
● Restrição: Longo tempo para criação de ambientes
● Contramedida: Criar ambiente sob demanda e completamente “self-service”

● Restrição: Longo tempo deploy do código em produção

● Contramedida: Automatizar os deploys (tarefas envolvidas) tanto quanto possível

● Restrição: Longo tempo para configurar ambientes e testar as features

● Contramedida: Automatizar os testes

● Restrição: Arquitetura fortemente acoplada / monolítica

● Contramedida: Criar uma arquitetura modular, encapsulada e fracamente acoplada

Remover desperdícios
Desperdício refere-se a qualquer atividade que consome recursos ou tempo sem criar valor
para o cliente
1. Trabalho Parcialmente Pronto
a. Trabalho não concluído ou parado em filas
2. Processos Extras
a. Trabalho adicional que esteja sendo executado sem agregar valor ao cliente
3. Recursos Extras
a. Recursos incorporados que não são necessários (“gold plating”)
4. Multitarefa
 a. Pessoas são atribuídas a vários projetos e fluxos de valor
5. Espera
a. Parada ou desaceleração esperando que um trabalho chegue
6. Movimentação
a. Movimento desnecessário
7. Defeitos
a. Retrabalho para corrigir erros, inspeções e refugo
8. Trabalho manual
a. Dependência de trabalho manual ou não padronizado
9. Atos heroicos
a. Para atingir metas, a empresa necessita de esforços heróicos

Exercício
● Na sua Opinião, o tamanho do Lote está adequado? Por que?
○ Não
○ Existe uma espera grande para analisar o Lote completo, gerando fila em
todo o lugar que o Lote chega

● Qual o tamanho ideal de Lote que você sugeriria para a SuperDevOps?

○ 1

● Considerando o tamanho do Lote atual (10 histórias) e que o gasto atualmente é

proporcional (Ex. se são gastas 40 horas para analisar um lote, significa que são
gastas então 4 horas por história. O mesmo vale para os tempos de espera), como
ficaria o lead time se o tamanho de lote fosse reduzido para 1 história? Redesenhe o
fluxo de valor para melhor visualização

● Na sequencia, compare a sua resposta com uma possível solução

● O tempo estimado para esse exercício é de 30 minutos

A Segunda maneira: Feedback
● Descreve os princípios que permitem o feedback rápido e constante da direita para a
esquerda em todos os estágios do fluxo de valor
● A segunda maneira se concentra em aumentar os loops de feedback da direita para
a esquerda
● Um dos pontos que se busca é que o fluxo seja interrompido quando os erros forem
encontrados (que não haja a propagação dos erros e que haja qualidade na origem)
● Os outros pontos é que o feedback proveniente desse erro seja transmitido o mais
rápido possível para a origem (quem o causou), para que possa ser corrigido
Sistemas complexos

Conceitos
● Simples
○ Causa e efeito é evidente para todos
● Complicado
○ Domínio dos especialista
○ Causa e efeito exige uma análise especializada
● Complexo
○ Não são ordenados
○ Não há uma ligação aparente entre a causa e o efeito
○ Precisa fazer para ver o efeito/erro
● Caótico
○ Domínio da resposta causa
○ Não há relação entre causa e efeito a nível de sistema

Ambiente de TI especificamente desenvolvimento e entrega de software residem no

conceito Complexo
● Fazer a mesma coisa duas vezes não irá previsivelmente ou necessariamente levar
ao mesmo resultado
● É essa característica que torna checklist e as melhores práticas, embora valiosos,
insuficientes para evitar a ocorrência de problemas
● Como a falha é inerente e inevitável em sistemas complexos, devemos projetar um
sistema seguro de trabalho
Criando ambientes seguros

1. O trabalho complexo é gerenciado para que os problemas no

design e nas operações sejam revelados
a. Teste unitário é um exemplo de erros serem revelados
2. Problemas são analisados e resolvidos coletivamente (swarming),
resultando na rápida construção de novos conhecimentos
3. O novo conhecimento local é explorado globalmente em toda a
organização
4. Os líderes criam outros líderes que continuamente aumentam
esses tipos de recursos
Revelando problemas à medida que ocorrem
● Em um sistema seguro de trabalho, deve-se testar
constantemente as premissas de design e de operação
● Quanto mais premissas puderem ser invalidadas, mais rápido
pode-se encontrar e corrigir problemas, aumentando a resiliência,
a agilidade e a capacidade de aprender e inovar
● Muitas vezes, obtém-se resultados ruins devido à ausência de
feedback rápido

● Se houver longo período para entrega

○ Potencial de alto retrabalho
○ Oportunidades de melhoria perdidas
○ Produto obsoleto
○ Usuários dão feedback tardio, após eles receberem o
produto
○ Fatores externos, receptividade do mercado e premissas
também podem ter mudado
Objetivo
● O objetivo então é criar feedback rápido onde quer que o trabalho seja executado
● Práticas a seguir auxiliam a atingir estes objetivos. Essas práticas que detectam
“imediatamente” quando uma alteração feita “quebra” o código e o tira de um estado
correto e “implantável”
○ Builds automatizados (integração contínua)
○ Testes funcionais automatizados
○ Entrega contínua
○ Testes Unitários automatizados
○ Tests A/B
○ Revisão de código
● Outra prática é criar e utilizar telemetria, que permite o acompanhamento dos
ambientes, observando como os componentes de sistema estão operando
○ Acessos ao sistema/recurso
○ Utilização de recurso (disco, Memória processamento)
○ Mudanças de dados (adição, alteração, exclusão de dados)
○ lentidão / shutdown / instabilidade
Swarning

● Swarm é uma palavra de difícil tradução. Literalmente pode ser traduzida como
“enxame”, “multidão”, “formigueiro”
● Se conjugarmos a expressão “swarming with people”, teremos algo como
"fervilhando de pessoas”. “Intelligent swarming” pode ser traduzido como
"inteligência de enxames"
● Dentro do contexto ágil, termos algumas definições para swarming:
○ Swarming é simplesmente o ato de unir para resolver um problema ou fazer
algo rapidamente
○ Swarm é onde você coloca toda a equipe para se concentrar na solução de
um único problema
● Quando ocorrem problemas, é preciso atuar de forma coletiva (swarm), mobilizando
quem for necessário para resolver o problema
Resolvendo problemas coletivamente
● Quando ocorrem problemas, é preciso atuar de forma coletiva (swarm), mobilizando
quem for necessário para resolver o problema
● O objetivo de realizar o swarming é conter o problema antes que eles tenham a
chance de se espalhar
● Agir imediatamente - não esperar para "quando houver tempo"

Sistema Andon, da Toyota

● Com Andon, se algo está errado, não precisa ser escalado burocraticamente por
uma cadeia de comando. Qualquer trabalhador da linha de produção, seja qual for
seu grau ou experiência, tem o direito de puxar o cabo
○ Os líderes se mobilizam para resolver na hora
○ Se demorar muito para resolver, para a fábrica inteira e todos se unem para
resolver o problema que não irá cair no esquecimento

Ou seja, o sistema Andon da Toyota nos ensinam que:

● Em vez de contornar o problema ou deixar para corrigi - lo “quando temos mais
tempo”, devemos parar e corrigi-lo imediatamente
● Swarming é necessário pelo seguintes motivos
○ Evita que o problema progrida para as próximas etapas do fluxo de valor
○ Ao impedir que o problema progrida para a próxima etapa do fluxo de valor,
permitindo que novos trabalhos sejam iniciados
○ Se o problema não for resolvido, poderemos potencialmente ter o mesmo
problema na próxima operação, exibindo mais correções e trabalho
 ● É somente através da resolução coletiva de problemas cada vez menores,
descobertos mais cedo no ciclo de vida, que podemos desviar os problemas antes
que ocorra uma catástrofe

Manter o controle de qualidade próximo da origem do trabalho

● Pode-se perpetuar sistemas inseguros de trabalho devido à forma de reação
acidentes e incidentes
● Todos que trabalham no fluxo de valor encontrem e corrija problemas em sua área
de controle como parte do trabalho diário
● Ao fazer isso, as responsabilidade de qualidade e segurança e a tomada de
decisões são movidas para onde o trabalho é realizado, em vez de depender de
aprovações de “pessoas distantes” da origem do trabalho
○ Revisão por pares
○ Automatizar atividades (e testes)
Otimizar o trabalho pensando nas próximas etapas
● É necessário se preocupar com o cliente interno no processo. Cliente interno é a
próxima pessoa que irá trabalho no processo
● Otimizar o trabalho para eles exige que tenha-se empatia por seus problemas, a fim
de identificar melhor os problemas que impedem o fluxo rápido e suave
● No fluxo de valor de tecnologia, pode-se otimizar o trabalho pensando em
Operações, priorizando os requisitos não funcionais operacionais da mesma forma
que funcionalidades do usuário
● Ao fazer isso, criamos qualidade na fonte, provavelmente resultando em um
conjunto de código não funcionais codificados
● Utilize o %C/A (percentual complete and accurate)
Aprendizado e experimentação contínua (continuous learning
and experimentation)
A terceira maneira é sobre a criação de uma cultura que promove duas coisas:
1. Experimentação contínua, assumindo riscos e aprendendo com o sucesso e com o
fracasso

2. Compreende que a repetição e a prática são o pré-requisito para o domínio

a. Experimentação contínua não é uma coisa fácil de cultivar, uma vez que
requer correr riscos e aprender com sucessos e fracassos
b. Assumir riscos geralmente é algo que a empresa gostaria de evitar
i. Atuar na primeira e na segunda maneira permitirão correr alguns
riscos e isso torna a terceira maneira efetiva

O que mais impede a experimentação e aprendizagem organizacional?

● A cultura do Medo!
○ Empresas com cultura do medo e baixa confiança, são aquelas onde os
trabalhores que comentem erros são punidos, e aqueles que fazem
sugestões ou apontam problemas são vistos como delatores e causadores
de problemas
● É necessário criar um ambiente seguro para experimentação e aprendizagem
organizacional
○ Não procure culpados. Procure a causa-raiz do problema
○ Procure descobrir como redesenhar o sistema para que o erro não volte a
ocorrer
○ Aprenda com os erros
 ● Crie resiliência no sistema de trabalho

As práticas da terceira maneira incluem:

● Alocar tempo para melhorar o trabalho diário
○ Reservar tempo explicitamente para pagar a dívida técnica corrigir defeitos e
refatorar, e melhorar áreas problemáticas do código e ambiente (kaizen blitz)
○ Todos encontram e corrigem problemas em sua área de controle o tempo
todo como parte de seu trabalho diário
○ Kata Improvement
● Transformar descobertas locais em melhorias globais
○ Transformar novos conhecimentos locais, de tácitos para explícitos
○ Registrar lições aprendidas, procedimentos, dicas e truques, técnicas
○ Manter em local de fácil acesso e pesquisa
● Introduzir falhas no sistema para aumentar a resiliência
○ Melhorar a performance diária para fazer mais com menos )ou com o que se
tem)
○ Conceito de "antifrágil" (antifragility)
○ Promover estresse voluntário ao sistema para analisar como ele reage.
Aprender com as situações.
○ Game Day (Ex.: Netflix)
● Líderes devem reforçar uma cultura de aprendizado
○ O papel do líder é criar as condições para que sua equipe possa descobrir a
grandeza em seu trabalho diário
○ O relacionamento é necessário por que nenhum dos dois pode resolver os
problemas sozinho - os líderes não estão suficientemente próximo do
trabalho, o que é necessário para resolver qualquer problema, e os
trabalhadores da linha de frente não tem o contexto, organizacional, mais
amplo nem a autoridade para fazer mudanças fora de sua área de trabalho