Práticas Devops - Desenvolvimento e Operação (PDDO)

DevOps
Junilson Pereira Souza

Contexto Organizacional
Objetivos
Propiciar o entendimento do contexto de

aplicação da abordagem DevOps.
Tópicos
Contexto de negócio.
Muro da confusão.
Espiral da morte.
Débito técnico.
Contexto de Negócio
O contexto de negócios atual

parece não deixar mais
alternativas.
Há uma percepção generalizada

de que se deseja tudo melhor,
mais barato e entregue com
mais rapidez.
https://www.applerock.com/blog/post/faster-better-or-cheaper-pick-two
Pressão Organizacional
https://br.freepik.com/vetores-premium/fabrica-urbana-da-cidade-3d-isometrica_5088840.htm
https://www.fermaquinas.com.br/compressor-de-ar-25-pes-250-litros-alta-pressao-onix-trifasico-pressure-on25-250/p
https://www.applerock.com/blog/post/faster-better-or-cheaper-pick-two
Fluxo de Entrega de Soluções
Fluxo de entrega de soluções
Negócio Desenvolvimento Operações
https://www.accenture.com/us-en/blogs/blogs-reshma-shinde-devops-transformations-operations
Perspectivas diferentes em cada silos
Abordagens ágeis
Satisfazer clientes Responder as Manter estabilidade

Evoluir produtos demandas de
negócio
Objetivos Específicos em Cada Silo
Como fica esta parte?
Satisfazer clientes Responder as Manter estabilidade

demandas de
Evoluir produtos negócio
Muro da Confusão
Objetivo Objetivo
Responder as constantes Prover serviços estáveis,

mudanças confiáveis e seguros
Desenvolvimento Operações
Objetivos específicos por silos inibem que sejam alcançados os

objetivos organizacionais [Lee Thompson e Andrew Shafer]
Espiral da Morte
Pressão por
entregar
funcionalidades
Processos Menos tempo para

operacionais se requisitos não
tornam mais onerosos funcionais
Aumento do Aumento da
tamanho dos fragilidade do
lotes sistema
[Kim, Humble, Willis, Debois]

Espiral da Morte e Débito Técnico
https://www.blogcmmi.com.br/engenharia/o-preco-das-gambiarras
Espiral da Morte e Débito Técnico - Custos
Horas-extras,
impotência,fadiga U$ bilhões/ano.
burnout, cinismo,
desesperança.
https://santosbancarios.com.br/artigo/burnout-quando-o-esgotamento-profissional-vira-doenca
http://simi.org.br/noticia/Startup-incubada-na-INCIT-ajuda-a-reduzir-desperdicio-de-recurso-publico
E qual a realidade de sua empresa?
Cite exemplos reais das pressões em sua

organização oriundas do contexto de demandas
por soluções melhores, mais baratas e
entregues mais rapidamente.
Identifique na sua organização

objetivos distintos entre as áreas de
desenvolvimento e operações que
fomentem o Muro da Confusão.
Identifique pelo menos três episódios da

ocorrência da Espiral da Morte que
acarretaram o crescimento do Débito Técnico.
Referências
[Kim, Humble, Willis, Debois] Kim, Gene; Humble, Jez; Willis, John;
Debois, Patrick. The DevOps HandBook. IT Revolution Press, 2016.
[Humble, Farley] Humble, Jez; Farley, David. Continuous Delivery:

Reliable Software Releases through Build, Test, and Deployment
Automation. Addison Wesley, 2010.
[Kim, Behr, Spafford] Kim, Gene; Behr, Kevin; Spafford, George. The
Phoenix Project: a novel about IT, DevOps and helping your business win.
IT Revolution Press, 2013.
[Bass, Weber, Zhu] Bass, Len; Weber, Ingo; Zhu, Liming. DevOps: A
Software Architect’s Perspective. Addison Wesley, 2015.
Obrigado!
[email protected]
DevOps
Conceito de DevOps
Objetivos
Permitir entender os motivos, conceitos,

histórico e pilares do DevOps.
Tópicos
Por que DevOps.
Conceito de DevOps.
Modelo CALMS.
Princípios DevOps (Three ways).

Por que DevOps?
Fluxo de entrega de soluções
Endereçar o
Muro da Confusão e
objetivos entre áreas.
Por que DevOps?
Endereçar
Espiral da Morte,
Pressão por enfatizando aspectos
entregar não funcionais
funcionalidades
Processos Menos tempo para

operacionais se requisitos não
tornam mais onerosos funcionais
Aumento do Aumento da
tamanho dos fragilidade do
lotes sistema
[Kim, Humble, Willis, Debois]

Por que DevOps?
Atentar continuamente
para o débito técnico
https://www.blogcmmi.com.br/engenharia/o-preco-das-gambiarras
Por que DevOps?
Forsgren, Nicole; Humble, Jez; Kim; Gene. Accelerate: State of DevOps 2018. Strategies for a New Economy.
O que é DevOps?
“DevOps é um movimento profissional emergente que

preconiza a um relacionamento de trabalho
colaborativo entre equipes de Desenvolvimento e
Operações, resultando no fluxo rápido do trabalho
planejado, com altas taxas de entrega, enquanto de
forma simultânea incremental a confiabilidade,
estabilidade, resiliência e segurança do ambiente de
produção”
[Gene Kim]
Histórico
2008. Agile Conference. “Agile Infrastructure & Operations” (Patrick Debois).
2009. O’Reilly Velocity Conference. “10+ Deploys per Day: Dev and Ops
Cooperation at Flickr” (John Allspaw e Paul Hammond).
2009. 1º DevOpsDays. Termo “DevOps” (Patrick Debois).
2010. DevOpsDays Mountain View. Termo “CAMS” (John Willis e Damon
Edwards).
2010. Continuous Delivery.
2013. Phoenyx Project.
2016. DevOps Handbook.
Hall da Fama DevOps
Damon Edwards
Patrick Debois
John Allspaw Paul Hammond
John Willis Gene Kim Jez Humble

Modelo CALMS
(*)Termo criado por John Willis e Damon Edwards e incrementado por Jez Humble (L).
https://www.softserveinc.com/en-us/blog/assess-devops-structure-through-calms/
Modelo CALMS
Cultura
Respeito as pessoas
Medição
Ponte entre Dev e Ops Telemetria
Aceitar mudanças Monitoração
Lean Melhorias
Valor para cliente
Lotes pequenos
Fluxo contínuo
Reduzir WIP Sharing
Automação
Colaboração
Integração/liberação contínua Feedback
Infra como código Comunicação
Pipeline de implantação Transparência
Princípios DevOps (Three ways)
Fluxo
(Pensamento sistêmico)
Laços de feedback
Cultura de experimentação e
aprendizagem contínuos
Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project: a novel about IT, DevOps and helping your business win. IT Revolution Press: USA
Portland, 2013.
Pesquise na Internet pelo menos cinco

definições distintas de DevOps. Identifique
em cada uma os pontos mais alinhados com o
que foi apresentado. Identifique pontos
divergentes/parciais.
Analise o "grau de aderência" de sua

organização com relação ao DevOps usando
como base o modelo CALMS.
Analise o "grau de aderência" de sua

organização com relação ao DevOps usando
como base os princípios DevOps (Three
Ways).
Referências
[Kim, Humble, Willis, Debois] Kim, Gene; Humble, Jez; Willis, John; Debois, Patrick. The
DevOps HandBook. IT Revolution Press, 2016.
[Humble, Farley] Humble, Jez; Farley, David. Continuous Delivery: Reliable Software
Releases through Build, Test, and Deployment Automation. Addison Wesley, 2010.
[Kim, Behr, Spafford] Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project: a
novel about IT, DevOps and helping your business win. IT Revolution Press, 2013.
[Debois] Debois, Patrick. “Agile Infrastructure & Operations”. Agile Conference. 2008.
https://docplayer.net/23874035-Agile-infrastructure-operations.html.
[Allspaw, Hammond] Allspaw, John; Hammond, Paul. O’Reilly Velocity Conference. “10+
Deploys per Day: Dev and Ops Cooperation at Flickr”.
https://www.youtube.com/watch?v=LdOe18KhtT4.
Obrigado!
[email protected]
DevOps
Princípios e Práticas
DevOps (Three ways)
Objetivos
Entender os princípios e práticas DevOps

Tópicos
Princípios de Fluxo (Pensamento sistêmico).
Princípios de Laços de Feedback.
Princípios de Cultura de
Aprendizagem e Experimentação contínuos.
Fluxo
(Pensamento sistêmico)
Laços de feedback
Cultura de experimentação e
aprendizagem contínuos
Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project: a novel about IT, DevOps and helping your business win. IT
Revolution Press: USA Portland, 2013.
Princípios de Fluxo
Objetivo: reduzir o tempo necessário para as mudanças serem

disponibilizadas em produção, garantindo a qualidade e confiabilidade
das soluções.
Exemplo de princípio: mapear fluxo de valor.
Exemplo de prática: criar as fundações do pipeline de deployment

Deployment pipeline
https://stackoverflow.com/questions/28608015/continuous-integration-vs-continuous-delivery-vs-continuous-deployment
Definição de done
“Ao final de cada intervalo de desenvolvimento, deve haver

código testado, integrado, em funcionamento,
potencialmente entregue.”
Definição de done na perspectiva DevOps
“Ao final de cada intervalo de desenvolvimento, deve haver

código testado, integrado, em funcionamento,
potencialmente entregue, demonstrado em ambiente
análogo ao de produção, criado do ramo principal de
desenvolvimento, usando um processo de “apenas
um clique” e validado com testes automatizados”.
Princípios de Laços de Feedback
Objetivo: criar um sistema de trabalho cada vez mais resiliente e

seguro.
Exemplo de princípio: ver os problemas quando ocorrem
Exemplo de prática: criar telemetria para habilitar ver e resolver

problemas
Framework de monitoração
Princípios de Cultura de
Aprendizagem e Experimentação contínuos
Objetivo: criar uma cultura de alta confiança, reforçando a condição

de aprendizes para toda a vida (lifelong learners) que devem assumir
riscos no trabalho diário.
Exemplo de princípio: institucionalizar a melhoria do trabalho diário

Exemplo de prática: habilitar e injetar aprendizagem no trabalho
diário
A organização percebe um fluxo único de

valor ou opera em silos, cada um com seu
objetivo? Há o entendimento e a
implementação de um pipeline de
implantação?
Quais os recursos usados para a monitoração

do pipeline de implantação e qual o nível de
feedback é provido durante o processo?
Qual o alinhamento entre o planejamento

estratégico e as ações de melhoria contínua
diária das equipes? Há uma cultura que
favoreça a experimentação ou uma cultura de
punição aos erros?
Referências

Obrigado!
[email protected]
DevOps - Kanban
Kanban – Visão Geral
Objetivos
A exigência por entregas cada vez melhores, mais
baratas e de maneira antecipada é a norma nos
tempos atuais.
Ter um arcabouço que permita gerenciar os

serviços e propicie uma melhoria contínua é
fundamental nesse contexto.
Tópicos
Definição do Método Kanban.
Princípios Kanban.
Práticas Gerais Kanban.
Métricas e Previsões.
Escalabilidade com Kanban.
Avaliação de Maturidade.
Ajuste ao Propósito do Cliente.

Por que Kanban?
Demanda Fluxo de Serviço Solução
Discovery (descoberta) Delivery (entrega)

Requisição Triagem Preparação Implementação Testes Validação Entrega
Uma organização pode ser pensada como uma rede de

serviços.
Método Kanban
Método evolucionário para:
- definição,
- gerenciamento e
- melhoria
de serviços que entregam trabalho do conhecimento
tais como serviços profissionais, indústria criativa e entrega
de produtos de software.
Princípios Kanban
Princípios de gerenciamento de mudanças:

- Começar com o que se tem no momento;
- Perseguir melhoria por meio de mudanças evolucionárias;
- Encorajar atos de liderança em todos níveis.
Princípios de entrega de serviços:

- Entender e focar nas necessidades e expectativas dos clientes;
- Gerenciar o trabalho, deixar as pessoas se auto-organizem;
- Fazer com que as políticas guiem e restrinjam a entrega de serviços.
Práticas Gerais Kanban
Visualizar fluxo de trabalho.
Limitar trabalho em progresso.
Gerenciar fluxo.
Tornar políticas explícitas.
Implementar laços de feedback.
Melhorar colaborativamente, evoluir experimentalmente.

Ecossistema Kanban
Métricas e Previsões
[Anderson]
Escalabilidade com Kanban
[Anderson]
https://www.kanbanmaturitymodel.com/
Ajuste ao Propósito do Cliente
https://www.fitterforpurpose.com/
Referências
[Anderson, Carmichael] Anderson, David; Carmichael, Andy. Essential

Kanban Condensed. 2016.
https://www.kanbanmaturitymodel.com/.
https://www.fitterforpurpose.com/.
Obrigado!
[email protected]
DevOps - Kanban
Visualizar o Fluxo
Objetivos
A exigência por entregas cada vez melhores,
mais baratas e de maneira antecipada
impõe que um gerenciamento efetivo dos
serviços.
A visualização é o primeiro passo rumo a

esse gerenciamento.
Tópicos
Mapeamento do fluxo de trabalho.
Quadro Kanban.
Sistema Kanban.
Itens de trabalho.
Métricas Fundamentais Kanban.

Mapeamento do fluxo
Kanban é uma abordagem que conduz mudança no
processo existente pelo aperfeiçoamento.
Deve-se resistir a tentação de mudar estruturas, fluxos

de trabalho, papéis e práticas de trabalho específicas.
Deve-se mapear o fluxo de valor real, ou seja, aquele

que é executado na organização, não um fluxo
desenhado ou idealizado.
Quadro Kanban
O método Kanban não prescreve uma forma de
visualizar o trabalho.
O quadro Kanban é uma forma típica de visualização.
Nele as colunas representam os passos ou atividades no

processo.
É usual modelar para as atividades o trabalho que está

em andamento e o trabalho finalizado.
Quadro Kanban

Sistema Kanban
Para se ter um sistema Kanban real, é necessário definir o
escopo do mapeamento, delimitado por dois pontos no fluxo de
trabalho:
- ponto de compromisso;
- ponto de entrega.
Sistema Kanban
Ponto de Ponto de
compromisso entrega
Itens de Trabalho
Exemplos de itens de trabalho que fluem no sistema:
✔ requisito;
✔ funcionalidade;
✔ história de usuário/caso de uso;
✔ solicitação de mudança;
✔ defeito;
✔ manutenção;
✔ refactoring;
✔ sugestão de melhoria;
✔ item bloqueante.
Itens de Trabalho
Tipos de item de trabalho tendem a ser definidos por:
- fonte do trabalho,
- fluxo do trabalho, ou
- tamanho do trabalho.
O sistema Kanban deve representar o trabalho do time,

portanto, não faz sentido ter sistemas diferentes conforme o
tipo.
Podem ser usados recursos visuais para distinguir os tipos

de itens de trabalho.
Sistema Kanban
Ponto de Ponto de
compromisso entrega
Métricas Fundamentais Kanban
Work In Progress (WIP)
Trabalho contido entre o ponto de compromisso e o ponto de
entrega.
Lead Time
Período de tempo de um item de trabalho entre os pontos de
compromisso e entrega.
Delivery Rate
Taxa de entrega ou vazão. Razão entre WIP e Lead Time médios.
Métricas Fundamentais Kanban
WIP
Lead time
Delivery Rate
Como é feita a visualização do trabalho
em progresso em sua organização?
Como é feito o controle de itens de

trabalho?
Quais métricas são coletadas?

Referências

Kanban Condensed. 2016
[Anderson] Anderson, David. Kanban – Mudança Evolucionária de

Sucesso Para Seu Negócio de Tecnologia. Blue Hole Press. 2011.
Obrigado!
[email protected]
DevOps - Kanban
Limitar WIP
Objetivos
serviços que.
Um dos principais aspectos para eficiência

do processo é limitar o trabalho em
progresso.
Tópicos
Ocupação do sistema.
Tamanho das filas e lotes.
Sistema puxado vs empurrado.
Efeitos do WIP elevado.
Lei de Little.
Cumulative Flow Diagram (CFD).
Quadro Kanban com Limite de WIP.
Ocupação do sistema
É uma visão gerencial recorrente focar em maximizar a
utilização de pessoas e recursos tentando garantir que
todos estejam ocupados e com um suprimento de
trabalho pronto de forma a não ocorrer tempo de
ociosidade.
Como resultado as pessoas se sentem sobrecarregadas

com o volume de trabalho e aceitam apenas tarefas para
as quais foram explicitamente instruídas a fazer.
Tamanho da fila vs utilização da capacidade
Utilização vs Lead Time vs Tamanho do Lote
Lead time
Utilização
https://scalingsoftwareagility.wordpress.com/2009/12/14/an-agile-illusion-how-that-nice-backlog-is-actually-decreasing-your-team%E2%80%99s-agility/
Sistema puxado vs empurrado
Introduzir e respeitar limites de WIP muda o sistema de
“empurrado” para “puxado”.
Com isso, novos itens não são iniciados até que o

trabalho em progresso seja concluído.
Sistema puxado vs empurrado
2.a?
2.b?
1
Qual a alternativa mais indicada?

Efeitos do WIP elevado
Aumento do desperdício.
Aumento do lead time.
Redução do delivery rate.
Redução da qualidade.
Redução da capacidade em responder aos clientes.

Lei de Little
A Lei de Little mostra que uma redução no

WIP leva a uma redução no lead time.
Cumulative Flow Diagram (CFD)
[Anderson]
Quadro Kanban com Limite de WIP
4 2 2
Aspectos de limitação de WIP
Limites para tarefa/itens de trabalho.
Limites para filas.
Retenção de gargalos.
Tamanho da fila de entrada.
Alocação da capacidade.
Qual o comportamento gerencial com
relação a alocação da equipe?
Existe algum mecanismo de limitação de

WIP?
Quais impactos você já presenciou sem a

limitação de WIP?
Referências


[Reinertsen] Reinertsen, Don. The Principles of Product Development

Flow: Second Generation Lean Product Development. 2009.
Obrigado!
[email protected]
DevOps - Kanban
Gerenciar Fluxo
Objetivos
serviços.
O gerenciamento do fluxo garante a

efetividade das entregas, com base em
critérios de priorização adequados.
Tópicos
Objetivos do fluxo de trabalho.
Custo por Atraso (CoD).
Classes de Serviço.
Arquétipos de Classes de Serviço.

Objetivos do fluxo de trabalho
O fluxo de trabalho em um sistema kanban deve
maximizar a entrega de valor, reduzir o lead time e ser o
mais previsível quanto possível.
Esses são objetivos as vezes conflitantes e, dada a

complexidade usual das entregas, um controle empírico é
necessário por meio de transparência, inspeção e
adaptação.
Custo por Atraso (CoD)
Um conceito chave para ser entendido e maximizar o
fluxo de valor é o custo por atraso dos itens de trabalho.
O custo por atraso é a quantidade de valor que é

perdida pelo atraso na entrega de um item de trabalho
em um período de tempo específico.
Custo por Atraso (CoD)
https://www.ontheagilepath.net/2017/03/cost-of-delay-a-key-metric.html
Classes de Serviço
Para tornar efetiva a priorização e o gerenciamento do
fluxo, é importante distinguir os itens de trabalho.
Uma Classe de Serviços é agrupamento de itens de

trabalho organizado conforme a mudança no valor de
cada item é afetada com o atraso.
Classes de serviço são tipicamente definidas baseando-

se no impacto do negócio e cada uma traz seu conjunto
de políticas próprio que afeta a priorização.
Arquétipos de Classes de Serviço
Expedição Data Fixa Padrão Intangível
[Anderson]
Classes de Serviço
Sonya Siderova
https://getnave.com/blog/kanban-classes-of-service/
Classe de Serviço Expedição
Demandas típicas da alta gestão, com curto espaço de
tempo e valor estratégico.
Afetam de maneira negativa a cadeia de fornecedores e os

sistemas, aumentam o lead time de outras demandas.
Escolhe-se gerar valor numa demanda específica ao custo de

atrasar outras e incorrer em custos adicionais.
O valor gerado a partir da expedição deveriam exceder

os custos do lead time maior e potencial de perda de
negócio.
Classes de Serviço Data Fixa
Geralmente associadas a obrigações contratuais,
requisitos de regulamentação (usualmente do governo
federal) ou demandas sazonais (escolas, faculdades etc.)
Trazem um custo de atraso significativo e podem trazer

custos diretos em termos de penalizações, multas ou
impostos cobrados.
Classes de Serviço Padrão
Geralmente associados a itens urgentes.
As políticas e o acordo de nível de serviço (SLA) podem

variar de acordo com o tipo de item de trabalho.
É usual separar os tipos de trabalho por tamanho,

como pequeno, médio e grande, com diferentes SLAs.
Tendem a ter um custo de atraso tangível que pode ser

calculado. O custo de atraso tende a ser imediato: se
temos esta função hoje, os benefícios virão amanhã.
Classes de Serviço Intangível
Podem ser importantes e valiosos, mas não há um custo
de atraso tangível associado a eles num futuro próximo.
Não há custo de atraso dentro do prazo de entrega do

item.
Requisições que atendem a esse padrão são as entregas

que possuem uma data fixa de entrega em potencial,
mas num futuro distante, como
uma substituição de plataforma, por exemplo.
Quais os mecanismos utilizados para
gerenciar e priorizar as demandas em sua
organização?
Quais a frequência e impacto da

ocorrência de demandas legais, urgentes
ou “da diretoria”?
Referências


[Reinertsen] Reinertsen, Don. The Principles of Product Development

Flow: Second Generation Lean Product Development. 2009.
Obrigado!
[email protected]
DevOps - Kanban
Explicitar Políticas
Objetivos
serviços que, por sua vez, inicia-se pela
visualização do trabalho.
Explicitar políticas ajuda a gerenciar a

complexidade do fluxo.
Tópicos
Políticas Explícitas.
Efeito das Políticas Explícitas.
Quadro Com Políticas Explícitas.
Tipos de Políticas Explícitas.
Exemplos de Políticas Explícitas.

Políticas Explícitas
Políticas explícitas são uma forma de articular e definir
um processo que vai além da definição do fluxo de
trabalho.
Elas ajudam a criar restrições nas ações e resultam em

características emergentes que podem ser ajustadas pela
experiência.
Políticas explícitas devem ser simples, bem definidas,

visíveis, sempre aplicáveis e facilmente alteráveis.
Efeito das Políticas Explícitas
O comportamento de sistemas complexos pode ser
guiado por políticas explícitas, apesar de não ser
predizível.
Explicitar políticas é um mecanismo visível e direto para

questionar e mudar as políticas quando elas forem
consideradas contraprodutivas ou não aplicáveis.
Quadro Com Políticas Explícitas
Definição Definição
de ready de done

Exemplos de Temas de Políticas Explícitas
Limite de WIP.
Capacidade Alocada.
Definições de ready e done.
Critérios para realizar eventos de reabastecimento

(replenishment) policies.
Utilização de classes de serviço.

Exemplos de Políticas Explícitas
Definição de Done
“O incremento implementado de ser incorporado a

produto existente”.
“Documentação da especificação atualizada na entrega”.
“Sucesso de 100% na execução dos testes de unidade”.
“Cobertura de 70% dos itens de backlog para os testes de

integração e sistema”.
Exemplos de Políticas Explícitas
Utilização de Classe de Serviço Expedição
“Requisições de expedição usam cartões brancos.”
“Uma classe de serviço de Expedição tem um limite de

WIP igual a 1.”
“Em qualquer ponto do fluxo de trabalho, o limite WIP

pode ser excedido para acomodar uma requisição de
expedição.”
Quais os mecanismos utilizados para
descrever os detalhes ou regras do
trabalho a ser realizado? Qual o nível de
acesso a essas informações?
Quais a frequência de revisão e

atualização desses detalhes ou regras?
Referências


Obrigado!
[email protected]
DevOps - Kanban
Implementar
Laços de feedback
Objetivos

serviços.
As cadências propiciam laços de feedback

efetivos para a entrega de serviços e a
melhoria evolutiva.
Tópicos
Strategy Review.
Operations Review.
Risks Review.
Service Delivery Review.
Delivery Planning Meeting.
Replenishment Meeting.
Kanban Meeting.
Laços de Feedback
Laços de feedback são parte essencial que qualquer
processo gerenciado e são especialmente importantes
para mudanças evolucionárias.
Cadências são reuniões e revisões cíclicas que

direcionam a mudança evolucionária e entrega efetiva de
serviços, como uma oportunidade de feedback.
Cadências podem também se referir ao período de tempo

entre as revisões, um dia de trabalho ou um mês, por
exemplo. A cadência adequada depende do contexto.
Cadências do Kanban
Conjunto para
melhoria
evolucionária
Conjunto para
entrega de
serviços
Strategy Review
Tem por objetivo realizar a seleção dos serviços a serem
providos e para definir para tais serviços, o conceito de Fit
for Purpose.
Também serve para avaliar como o ambiente externo

está se modificando de forma a prover direção aos
serviços.
A cadência típica é trimestral.

Operations Review
Tem como objetivo entender o balanço entre os serviços,
entregando recursos para maximizar a entrega de valor
alinhada às expectativas dos clientes.
A cadência típica é mensal.

Risks Review
Tem como objetivo entender e responder aos riscos para
a entrega efetiva de serviços.
Usualmente é aplicada uma técnica chamada blocker

clustering que usa registros de questões que tem
bloqueado itens de trabalho, agrupados por causas
comuns.
A cadência típica é mensal.

Service Delivery Review
Tem como objetivo examinar e melhorar a efetividade de
um serviço.
Verifica se as entregas estão sendo feitas de acordo com

as expectativas do cliente.
Compara a capacidade corrente com as métricas de

ajuste e busca balancear a demanda conforme a
capacidade, além da mitigação de riscos.
A cadência típica é quinzenal.

Delivery Planning Meeting
Tem como objetivo monitorar e planejar as entregas aos
clientes.
A cadência típica depende de cada entrega ao cliente.

Replenishment Meeting
Tem como objetivo selecionar itens de trabalho do pool
de opções, efetivar o compromisso com a próxima
entrega e reabastecer o buffer de entrada do sistema
Kanban.
A cadência típica é semanal.

Kanban Meeting
Tem como objetivo realizar a coordenação, auto-
organização e revisão do planejamento para os
colaboradores que entregam o serviço.
Geralmente usa um formato “stand-up” para encorajar

uma reunião curta e enérgica com foco nos itens de
trabalho concluído e questões bloqueantes.
A cadência típica é diária.

Quais os eventos utilizados prover laços
de feedback em sua organização? Quais
os relacionamentos entre tais eventos ?
Quais ações de melhoria foram

promovidos recentemente em cada um
desses eventos?
Referências


Obrigado!
[email protected]
DevOps - Kanban
Evoluir experimentalmente
Objetivos
impõe um gerenciamento efetivo dos
serviços.
Promover mecanismos de melhoria contínua,

colaborativa e evolutiva dos serviços é
fundamental nesse contexto.
Tópicos
Melhoria Incremental vs Radical.
Curva da Mudança.
Oportunidades de Melhoria.
Teoria das Restrições.
Abordagem Lean para combate ao desperdícios.
Redução da variabilidade.
Melhoria Incremental vs Radical
Frequentemente, programas de transformação são
iniciados com a meta de mudar processos para
abordagens novas e pré-definidas.
Kanban inicia da organização como está agora e usa o

paradigma de fluxo Lean para perseguir melhoria
contínua e incremental.
Não há ponto de chegada para os processos de mudança

desde que perfeição em um panorama de ajustes de
constante mudança é inatingível.
Curva da Mudança
Geralmente aqui,
ocorrem as falhas e
o processo é abortado
https://imasters.com.br/devsecops/voce-conhece-diferenca-entre-o-sistema-kanban-e-o-metodo-kanban
Oportunidades de Melhoria
Teoria das Restrições.
Abordagem Lean para combate ao desperdícios.
Redução da variabilidade.
Teoria das Restrições (TOC)
Abordagem que foca no tratamento das restrições de um
sistema como forma de evoluí-lo.
Uma restrição é qualquer coisa numa empresa que a

impede ou limita seu movimento em direção aos seus
objetivos.
Teoria das Restrições (TOC)
https://narendrabhandavasblog.wordpress.com/2017/03/28/critical-chain-project-management-in-toc-way/
TOC - Five Focusing Steps
1. Identifique a restrição.
2. Decida como explorar a restrição.
3. Subordine tudo o mais no sistema à decisão tomada

no Passo 2.
4. Eleve a restrição.
5. Evite inércia; identifique a próxima restrição e retorne

ao Passo 2.
Variabilidade
https://profsilviocvalentini.blogspot.com/2013/10/gestao-da-qualidade-total-para-afinar.html
Fontes de Variabilidade
Fontes internas
Tamanho do Item de Trabalho.
Mesclas de Tipos de Item de Trabalho.
Mesclas de Classes de Serviço.
Fluxo Irregular.
Rework.
Fontes externas
Ambiguidade de Requisitos.
Requisições de Expedição.
Fluxo Irregular.
Disponibilidade do Ambiente.
Dificuldades em Agendar Atividades de Coordenação.
Pensamento Lean para Desperdício
O Pensamento Lean separa as atividades em dois grupos:
- atividades que agregam valor;
- atividades não agregam valor (desperdício - muda em

japonês).
Tipos de Desperdício
Trabalho parcial.
Processos extras.
Funcionalidades extras.
Chaveamento de contexto.
Espera.
Handoff.
Defeitos
Trabalho manual ou não padronizado.
Heroísmo.
Modelo Econômico para o Lean
Percepção do desperdício como custo:
Custo de coordenação
Qualquer atividade que envolve
comunicação e agendamento (ex.:
responder e-mails, participar de reuniões
etc.)
Custo de transação
Atividades que não agregam valor e [Anderson]
servem como preparação (ex.:
planejamento de sprint, seleção de
backlog etc.)
Considere o fluxo de trabalho em sua
organização.
Quais as principais restrições?
Quais são as principais causas de

variabilidade?
Quais são as principais fonte de

desperdício?
Referências

Obrigado!
[email protected]
Ambiente DevOps
Serviços Externos
Objetivos
Explicar os passos necessários para configurar todos

serviços externos ao ambiente DevOps.
Atividades
Criar conta no http://aws.com.

Obter credenciais de acesso.
Criar conta no http://dockerhub.com.

Criar repositório de imagens.
Criar conta no http://gitlab.com.

Fazer fork do repositório geral.
Visão Geral do Ambiente
Checkout Build Test/QA Image Deploy

Ambientes local e web
Serviços Externos
Ambiente local
Ambiente web (Play With Docker)

Amazon Web Services (AWS)
Acessar http://aws.com.
Realizar cadastro.
Criar usuário via IAM.
Obter credenciais de acesso AWS.

DockerHub
Acessar http://dockerhub.com.
Criar conta.
Criar repositório conchayoro.

Gitlab
Acessar http://gitlab.com.
Criar conta.
Fazer fork do repositório valuedriven/conchayoro.

Ambientes local e web
Serviços Externos
Ambiente local

Obrigado!
[email protected]
Ambiente DevOps
Ambiente Local
Atividades
Pré-requisito: preparar AWS, DockerHub e Gitlab.
Obter cópia do repositório remoto via Git.
Configurar credenciais.
Iniciar contêineres via Docker Compose.


Alternativas de Ambiente
Serviços Externos
Ambiente local

Ambiente Local
Pré requisitos:
✔
Docker e Docker Compose instalados.
✔
Git instalado (ou baixar arquivo compactado).
Ambiente Local
Acessar linha de comando.
$ git clone http://gitlab.com/<labuser>/conchayoro.git
$ cd conchayoro/ambiente
$ nano .credenciais
$ ./init-local.sh
Ambiente DevOps
Jenkins Sonar Nexus

Alpine Alpine Alpine
Docker
Host OS
Infraestrutura
Obrigado!
[email protected]
Ambiente DevOps
Ambiente Web
Atividades
Pré-requisito: configurar AWS, DockerHub e Gitlab.
Criar instâncias no Play With Docker.
Obter cópia do repositório remoto via Git.
Alterar configurações.
Iniciar contêineres via Docker Compose.

Visão Geral do Ambiente DevOps

Configuração do Ambiente
Ambiente Local
Ambiente Web (Play With Docker)

Play With Docker
Acessar http://labs.play-with-docker.com
Criar três instâncias (node1, node2 e node3).
Acessar linha de comando da instância 1.

Play With Docker
$ git clone http://gitlab.com/<labuser>/conchayoro.git
$ apk add nano
$ cd conchayoro/ambiente
$ nano .credenciais
$ nano .env
$ nano init-remoto.sh
$ ./init-remoto.sh
Ambiente DevOps
Jenkins Nexus Sonar

Docker Docker Docker
node1 node2 node3
Play With Docker
Obrigado!
[email protected]
Práticas Técnicas DevOps
Fundação do
Pipeline de Deployment
Objetivos
Prover uma visão do conceito de pipeline.
Tópicos
Princípios de Fluxo.
Práticas.
Deployment pipeline.
Visão Geral do Ambiente.
Ações.
Fluxo (Pensamento sistêmico)
Laços de feedback
Cultura de experimentação
contínua e aprendizagem
Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project: a novel about IT, DevOps and helping your business win. IT
Revolution Press: USA Portland, 2013.
Princípios de Fluxo
Têm como objetivos reduzir o tempo necessário para as

mudanças serem disponibilizadas em produção,
garantindo a qualidade e confiabilidade das soluções.
Requer um fluxo de trabalho rápido e suave entre

desenvolvimento e operações.
Preconiza a otimização para o objetivo global ao invés de locais.

Práticas
Criar as fundações do pipeline de deployment.
Habilitar e praticar integração contínua.
Habilitar testes automatizados rápidos e confiáveis.
Definir uma arquitetura para liberações de baixo risco.
Automatizar e habilitar e liberações de baixo risco.
Criar Fundações do Pipeline
O objetivo é criar todo ambiente de produção de forma

completamente automatizada a partir de dados
disponíveis no controle de versões.
Deployment Pipeline
Mecanismo em que todo código incluído no controle de

versões é automaticamente construído e testado
em ambientes similares ao de produção.
O objetivo é prover o feedback mais rápido

possível, para todos no fluxo de valor, de que uma
mudança retirou o sistema de um estado passível de
deploy.
Deployment Pipeline
Deployment Pipeline

Quais práticas ligadas ao fluxo são
aplicadas em sua organização?
Existe um pipeline de deployment

estruturado?
Referências

Obrigado!
[email protected]
Controle de versões e
automação de “tudo”
Objetivos
Mostrar como o controle de versões e

automação mais abrangentes permitem tornar
efetivo o funcionamento do pipeline de
deployment.
Tópicos
Mantenha tudo sob controle de versões.

Automatize “tudo”.
Ambiente
git clone http://gitlab.com/<gituser>/conchayoro.git

cd conchayoro/ambiente
apk add nano
nano .credenciais
nano .env
nano init-remoto.sh
sh init-remoto.sh
Mantenha tudo sob controle de versões
https://techbeacon.com/devops/7-steps-choosing-right-devops-tools
Automatize “tudo”


Git
Git é um sistema de controle de versões distribuído.
https://jrebel.com/rebellabs/git-commands-and-best-practices-cheat-sheet/attachment/github-cheat-sheet-graphic-v1/

Maven
Ferramenta para gerenciamento de projetos com os objetivos de
prover um sistema de build uniforme e informações sobre a
qualidade do projeto.
https://stackoverflow.com/questions/16205778/what-are-maven-goals-and-phases-and-what-is-their-difference

Docker
Docker é uma plataforma para desenvolvimento,

deploy e execução de aplicações com contêineres.
Um contêiner é uma unidade de software que

empacota o código e todas suas dependências de forma
que as aplicações sejam executadas de forma rápida é
confiável de um ambiente para outro.
Docker
https://docs.docker.com/get-started/overview/

Terraform
Terraform é uma ferramenta para construir, mudar e

versionar infraestrutura, que pode gerenciar provedores
externos ou próprios.
Pertence a categoria de softwares para IaC (Infrastructure

as Code) que consiste em uma configuração escrita em
linguagem de alto nível.
Terraform
https://thorsten-hans.com/terraform-the-definitive-guide-for-azure-enthusiasts

Ansible
Ansible é uma ferramenta de provisionamento,
gerenciamento de configurações e implantação de
aplicativos.
Ansible
https://geekflare.com/ansible-basics/
Quais itens de trabalho são mantidos sob
controle de versões?
Qual o nível de automação de tarefas em

seu ambiente?
Quais ferramentas são utilizadas no

pipeline de deployment?
Referências

Obrigado!
[email protected]
Integração Contínua
Objetivos
Apresentar o conceito de integração contínua

e sua relação com o pipeline de deployment.
Tópicos
Integração Contínua.
Ambiente de Integração Contínua.
Maven.
Nexus.
Sonar.
Integração contínua
“Pratica de desenvolvimento de software onde os membros de um time

integram seu trabalho frequentemente, geralmente cada pessoa integra
pelo menos diariamente – podendo haver múltiplas integrações por dia.
Cada integração é verificada por um build automatizado, incluindo

testes, para detectar erros de integração o mais rápido possível. Muitos times
acham que essa abordagem leva a uma significante redução nos problemas
de integração e permite que um time desenvolva software coeso mais
rapidamente.”
http://www.martinfowler.com/articles/continuousIntegration.html

Ambiente de Integração Contínua
Notificações
workspace
Compile
Build
Unit test
Commit Checkout Quality
Dependências Relatório
Armazenamento
Maven
Maven
Nexus
Nexus é um gerenciador de repositórios que permite
armazenar e distribuir componentes.
https://www.sonatype.com/product-nexus-repository
Sonar
SonarQube é uma ferramenta para revisão automática de
código para detecção de defeitos, vulnerabilidades e “maus
cheiros” de código.
Sonar
https://docs.sonarqube.org/latest/architecture/architecture-integration/
Existe um processo de integração
contínua em sua organização?
Com qual frequência o código é

integrado?
Quais ferramentas são utilizadas?

Referências

Obrigado!
[email protected]
Gerenciamento de
branches
Objetivos
Permitir entender a importância do versionamento semântico para clara identificação de

versões.
Permitir analisar estratégias de branching alinhadas ao conceito de DevOps.

Tópicos
Versionamento semântico.
Trunk-based development.
Release branching.
Versionamento semântico
Versionamento semântico é um esquema em que as

mudanças na numeração de versões apresentam
informações associadas do que foi alterado de uma
versão para a próxima.
Consiste em um conjunto simples de regras que

ditam como os números de versões são atribuídos e
incrementados.
https://semver.org/
Versionamento Semântico
Dado um número de versão MAJOR.MINOR.PATCH:
MAJOR: versão com mudanças de API (novos serviços).

MINOR: versão com adição de funcionalidades garantindo a
compatibilidade retroativa com a API.
PATCH: versão com foco em correção de defeitos.
https://pt.slideshare.net/DrupalizeMe/semantic-versioning-51928996/5
https://n8d.at/blog/how-to-version-new-sharepoint-framework-projects/semantic-version
Branching
Os mecanismos de branching suportados pelos sistemas de controle

de versões permitem divergir do fluxo principal de desenvolvimento e
continuar o trabalho de maneira independente.
Estratégias de Branching
Física. Arquivos, componentes e subsistemas.

Funcional. Funcionalidades, mudanças lógicas, correção de
defeitos, melhorias e outras unidades de funcionalidade
entregue.
Ambiente. Aspectos de construção e plataformas de runtime –
tais como compiladores, sistemas de janelas, bibliotecas,
hardware e sistema operacional.
Organizacional. Atividades, subprojetos, papeis e grupos.
Procedural. Suportam políticas, processos e estados.
Exemplo de estratégia de branching
Problemas com estratégias “criativas” de branching
Levam a otimizações locais.

Inibem a colaboração.
Isolam o conhecimento.
Reduzem a capacidade de refatoração.
Atrasam o feedback.
Não geram valor pois tratam de partes isoladas.
Alimentam o “merging hell”.
Merging hell
Merging hell
=
muitos branches
+
demora no merge
Trunk-based Development
Modelo de branching de código-fonte onde os desenvolvedores

colaboram no desenvolvimento de código em um branch único
chamado trunk, resistindo a pressões para criar branches
duradores por meio de uso de técnicas efetivas.
Assim evita-se o merging hell e outros efeitos colaterais de
múltiplos branches.
https://trunkbaseddevelopment.com/
Trunk-based Development
Utilidade de Branching
Release branching
https://www.autorabit.com/branching-strategies-for-salesforce-version-control/
Como é feita a identificação de versões
nos projetos de sua organização?
Quais estratégias de branching são

utilizadas?
Referências

Obrigado!
[email protected]
Testes de Software
Objetivos
Prover uma visão geral dos testes de software.
Tópicos
Definição de Testes de Software.
Objetivos dos Testes de Software.
Princípios de Testes de Software.
Dimensões de Testes de Software.
Pipeline e Testes.
Práticas técnicas de Fluxo
Criar as fundações do pipeline de deployment.

Habilitar testes automatizados rápidos e confiáveis.
Habilitar e praticar integração contínua.
Automatizar e habilitar e liberações de baixo risco.
Definir uma arquitetura para liberações de baixo risco.
Definição de Testes de Software
Processo que consiste em todas atividades do ciclo de vida
Tanto estáticas quanto dinâmicas
Voltadas para o planejamento, preparação e avaliação
de produtos de software e produtos de trabalho relacionados.

Objetivos dos Testes de Software
Encontrar/evitar defeitos e falhas.
Verificar se todos os requisitos especificados foram cumpridos.
Verificar se o objeto de teste está completo.
Validar se funciona como os usuários e stakeholders esperam.
Criar confiança no nível de qualidade do objeto de teste.
Fornecer informações suficientes para tomada de decisões.
Cumprir requisitos normativos, contratuais, legais ou regulamentares.
Princípios de Testes de Software
Teste demonstra a presença de defeitos.
Ilusão da ausência de erros.
Teste exaustivo é impossível.
Teste antecipado.
Agrupamento de defeitos.
Paradoxo do pesticida.
Teste depende do contexto.
Inteligência emocional
Dimensões de Testes de Software
Objetivo (por que?)
Tipo
Nível
Momento (quando?)
Técnica
Forma (como?)
Pipeline e Testes de Software
Commit Verificação Sistema Validação Entrega
Testes de unidade Testes de integração Testes de sistema Testes de aceitação
Testes estrutural Testes funcionais
Revisão Testes não funcionais
Análise estática Baseada em experiência
Baseada em estrutura Baseada em especificação
Nível (quando?)
Tipo (por que?)
Técnica (como?)
Pirâmide de Testes
Maior integração
Mais lentos Testes
Testes Manuais Manuais
Testes de
Testes de
GUI
GUI
Testes de Testes de
integração integração
Testes de
Testes de
unidade
unidade
Maior isolamento
Pirâmide de testes não ideal Mais rápidos

Pirâmide de testes ideal
Fonte: Martin Fowler

Referências
[ISTQB] ISTQB. Certified Tester Foundation Level Syllabus. 2018.

Disponível em
https://www.bstqb.org.br/uploads/syllabus/syllabus_ctfl_2018br.pdf
Obrigado!
[email protected]
Testes de Unidade
Objetivos
Prover uma visão do conceito de testes de unidade.
Tópicos
Contexto dos testes – pontos de falha.
Necessidade de testes de unidade.
Princípios da automação de testes.
Propriedades de um teste de unidade.
XUnit – Características comuns.
Ciclo xUnit.
Padrões xUnit.

Contexto dos testes – pontos de falha
Necessidade de testes de unidade
Permitem maior cobertura que os demais testes.
Habilitam a cooperação do time.
Garantem regressões.
Limitam a necessidade de depuração.
Propiciam coragem em refatorar.
Incrementam o desenho da implementação.
Servem como documentação.
Inteligência emocional
Princípios da automação de testes
Escreva o teste antes.
Desenhe para testabilidade.
Use a porta da frente antes.
Garanta cobertura de código.
Deve ser automatizável e repetível.
Deve ser fácil decidir quando remover um teste.
Propriedades de um teste de unidade
Manutenibilidade.
Independência.
Simplicidade.
Facilidade de leitura.
Perfil comportamental - resultado
xUnit
Termo genérico para frameworks de teste que apoiam a

realização de testes automatizados.
Perfil comportamental- análise
XUnit – Características comuns
Especificam um teste como um método de teste.
Especificam os resultados esperados na forma de chamadas a métodos de
asserção.
Agregam os testes em suítes de testes que podem ser executadas em uma
operação única e simples.
Executam um ou mais testes para obter um relatório com os resultados.
Ciclo xUnit
Padrões xUnit
Assertiva.
Fixture.
Fixture externa.
Método de teste.
Teste de exceção.
Todos testes.
Quais tecnologias e frameworks são
utilizados para a realização de testes de
unidade nos projetos em que você atua?
Referências
Grahan, D., Veenendaal, E., Evans, I., Black, R., Foundation of Software
Testing, ISTQB Certification, 2º edition, 2008.
Black, R., Pragmatic Software Testing: Becoming an Effective and Efficient

Test Professional, John Wiley & Sons 2007.
Hass, A., Guide to Advanced Software Testing, Artech House, 2008.
BECK, Kent. Test-driven development: by example. Addison Wesley, 2003.
Meszaros, Gerard. xUnit Test Patterns: Refactoring Test Code. Addison,

Wesley, 2007.
Obrigado!
[email protected]
Testes de Software
Objetivos
Tópicos
Práticas.
Ações.

Isolamento
Isolamento
Quando usar dublês
Objeto real tem comportamento não determinístico.
Objeto real é difícil de preparar.
Objeto real tem comportamento difícil de gerar.
Objeto real é lento.
Objeto real é uma interface gráfica.
Objeto real não tem retorno disponível.
Objeto real não existe ainda...
Quando não usar dublês
Geralmente classes que representam:
- entidades;
- serviços;
- utilitários.
Qualquer outra coisa que encosta em infraestrutura básica

São tipicamente classes das API padrão da linguagem.

estruturado?
Referências

Obrigado!
[email protected]
Testes de Software
Objetivos
Tópicos
Práticas.
Ações.

O que é TDD?
Test Driven Development, TDD, Desenvolvimento orientado a testes, é um estilo

de desenvolvimento originado nas práticas de “test-first” da XP, disseminado
originalmente por Kent Beck.
Qual o objetivo do TDD?
“Código limpo que funcione”

Ciclo TDD
http://lewandowski.io/2017/02/thre-levels-of-tdd-1/
Características do TDD
• Código de testes é escrito antes dos demais.

• Código novo somente é escrito caso um teste automatizado falhe.
• Duplicações são eliminadas durante o ciclo.
• Manutenção de um conjunto abrangente de testes.
• Os testes determinam qual código precisa ser escrito.
Implicações técnicas do TDD
• Desenho dever ser orgânico, com código provendo feedback entre as decisões.
• Os desenvolvedores devem escrever seus próprios testes, porque não podem
esperar a disponibilidade de outros.
• O ambiente de desenvolvimento deve prover respostas rápidas para pequenas
mudanças.
• O desenho deve consistir em muitos componentes, altamente coesos e
fracamente acoplados.
TDD e desenho
• Incentiva a produção de código simples.

• Obriga a pensar no comportamento antes da implementação.
• Ajuda a definir melhor as interfaces e comunicações.
• Produz código fácil de ser invocado.
• Permite encontrar padrões emergentes no código.
• Incentiva a remoção de código duplicado.
• Diminui acoplamento, aumenta coesão.

estruturado?
Referências

Obrigado!
[email protected]

Práticas Devops - Desenvolvimento e Operação (PDDO)

Enviado por

Direitos autorais:

Formatos disponíveis

Práticas Devops - Desenvolvimento e Operação (PDDO)

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Práticas Devops - Desenvolvimento e Operação (PDDO)

Enviado por

Direitos autorais:

Formatos disponíveis

DevOps

Junilson Pereira Souza

Propiciar o entendimento do contexto de

O contexto de negócios atual

Há uma percepção generalizada

Fluxo de entrega de soluções

Negócio Desenvolvimento Operações

Satisfazer clientes Responder as Manter estabilidade

Negócio Desenvolvimento Operações

Como fica esta parte?

Satisfazer clientes Responder as Manter estabilidade

Negócio Desenvolvimento Operações

Responder as constantes Prover serviços estáveis,

Objetivos específicos por silos inibem que sejam alcançados os

Processos Menos tempo para

[Kim, Humble, Willis, Debois]

Cite exemplos reais das pressões em sua

Identifique na sua organização

Identifique pelo menos três episódios da

[Humble, Farley] Humble, Jez; Farley, David. Continuous Delivery:

Permitir entender os motivos, conceitos,

Por que DevOps.

Princípios DevOps (Three ways).

Fluxo de entrega de soluções

Negócio Desenvolvimento Operações

Processos Menos tempo para

[Kim, Humble, Willis, Debois]

“DevOps é um movimento profissional emergente que

John Willis Gene Kim Jez Humble

Pesquise na Internet pelo menos cinco

Analise o "grau de aderência" de sua

Analise o "grau de aderência" de sua

Entender os princípios e práticas DevOps

Princípios de Fluxo (Pensamento sistêmico).

Princípios de Laços de Feedback.

Objetivo: reduzir o tempo necessário para as mudanças serem

Exemplo de princípio: mapear fluxo de valor.

Exemplo de prática: criar as fundações do pipeline de deployment

“Ao final de cada intervalo de desenvolvimento, deve haver

“Ao final de cada intervalo de desenvolvimento, deve haver

Objetivo: criar um sistema de trabalho cada vez mais resiliente e

Exemplo de princípio: ver os problemas quando ocorrem

Exemplo de prática: criar telemetria para habilitar ver e resolver

Objetivo: criar uma cultura de alta confiança, reforçando a condição

Exemplo de princípio: institucionalizar a melhoria do trabalho diário

A organização percebe um fluxo único de

Quais os recursos usados para a monitoração

Qual o alinhamento entre o planejamento

[Humble, Farley] Humble, Jez; Farley, David. Continuous Delivery:

Ter um arcabouço que permita gerenciar os

Práticas Gerais Kanban.

Escalabilidade com Kanban.

Ajuste ao Propósito do Cliente.

Demanda Fluxo de Serviço Solução

Discovery (descoberta) Delivery (entrega)

Uma organização pode ser pensada como uma rede de

de serviços que entregam trabalho do conhecimento

tais como serviços profissionais, indústria criativa e entrega