DevOps Trilhando a sua jornada

Prévia do material em texto

Trilhando a sua jornada DevOps 
Como boa coincidência, tivemos nesse mês a publicação do relatório State of DevOps 
Report 2018 do instituto de pesquisa e avaliação DevOps – o DORA. Ele trouxe nessa 
edição um modelo evolucionário para o aumento da sua maturidade DevOps. E esse 
modelo foi compilado através da análise do que milhares de empresas tem feito por todo 
o planeta. Faço um resumo do relatório abaixo para ajudá-lo a desenhar a sua jornada 
DevOps. 
Estágio 0 – Construir a Base 
A análise dos dados da pesquisa do estado de DevOps de 2018 revelou as práticas 
fundamentais empregadas pelas equipes bem-sucedidas. Essas práticas se correlacionam 
tão fortemente com o sucesso do DevOps que o instituo DORA recomenda que elas são 
essenciais em todos os estágios do desenvolvimento do DevOps. Em outras palavras, as 
práticas que devem ser adotadas em qualquer estágio para progredir para o próximo 
estágio permanecem importantes até mesmo para aquelas organizações que evoluíram 
mais longe em sua jornada DevOps e que já mostraram o maior sucesso. 
As práticas fundamentais estão listadas abaixo: 
 O monitoramento e alertas são configuráveis pelas equipes que operam os 
serviços em produção. 
 Os padrões de implantação para a criação de aplicativos ou serviços são 
reutilizados. 
 Os padrões de teste para a criação de aplicativos ou serviços são reutilizados. 
 As equipes contribuem com melhorias nas ferramentas fornecidas por outras 
equipes. 
 As configurações são gerenciadas por uma ferramenta de gerenciamento de 
configuração. 
Estágio 1: Normalize a pilha de tecnologia 
A maioria das organizações que usam grandes quantidades de tecnologia está lidando 
com muita complexidade, diminuindo seus esforços para avançar nos negócios. 
Portanto, não é surpreendente que os primeiros esforços em uma transformação DevOps 
(ou qualquer tipo de transformação de negócios) se concentraria na redução da 
complexidade. 
As duas práticas que definem o estágio 1 funcionam para reduzir a complexidade: 
 As equipes de desenvolvimento de aplicativos usam controle de versão. 
 Equipes fazem a implantação de aplicações em um conjunto padrão de sistemas 
operacionais. 
Estágio 2: Padronize e reduza a variabilidade 
No estágio 1, vemos organizações normalizando suas tecnologias 
e processos. Quando chegam ao estágio 2, as organizações já começaram o processo de 
padronização de um conjunto de tecnologias; configurações de aplicativos separados 
dos dados, uso consistente de controle de versão e também um processo consistente 
para testes de infraestrutura e um padrão de compartilhamento de código-fonte. 
No estágio 2, as organizações estão trabalhando para padronizar e reduzir a 
variabilidade, um tema que prevalece em todos os estágios da evolução do DevOps. 
Toda organização tem variação, que pode derivar de várias causas diferentes, 
incluindo: 
 Adoção de novas tecnologias para substituir muitas funções de tecnologias 
antigas. E ao mesmo tempo, as tecnologias mais antigas nunca são removidas. 
 Produtos caseiros que não seguem padrões comuns do setor e não possuem 
interfaces comuns. 
 Uma proliferação de ferramentas que se sobrepõem e não foram racionalizadas. 
 Fusões e aquisições, que trazem ainda mais tecnologias legadas para casa. 
No estágio 2, a reutilização de tecnologias e padrões se torna importante. Isso leva os 
times de Dev e Ops a colaborar e tomar decisões de arquitetura que afetam a 
capacidade de implementação e testabilidade dos aplicativos. Por causa do 
direcionamento para esses padrões comuns, as equipes começam a inventar maneiras de 
aumentar a velocidade na adoção de padrões e reduzir ainda mais a variação. Isso 
impulsiona a inovação no nível de equipe para otimizar processos e fluxos de trabalho 
em torno das pilhas de tecnologia abençoadas. 
Um antipadrão primário a ser observado neste estágio é que cada equipe se normalize 
em seus próprios padrões. Isso levará a um maior grau de variação global e é 
exatamente a direção errada. 
Em essência, as práticas de definição para o estágio 2 são: 
 Construa em um conjunto padrão de tecnologias. 
 Implante em um sistema operacional padrão único. (ou em um conjunto mínimo, 
se um apenas não for possível) 
Os principais benefícios da organização dos padrões e tecnologias de uma equipe 
de TI são: 
 Velocidade de entrega mais rápida. 
 Mais flexibilidade para a equipe de desenvolvimento trabalhar em novos 
aplicativos, serviços ou componentes. 
 Área de superfície reduzida para vulnerabilidades de segurança. 
 Menos partes móveis para manter, atualizar e aprender. E isso reduz a 
complexidade essencial e acidental. 
Etapa 3: Expandir as práticas do DevOps por toda a 
TI e além 
Os estágios 1 e 2 reduzem a complexidade geral da pilha de tecnologia para que as 
equipes possam obter resultados mais repetitivos com variação limitada. O estágio 3 é 
sobre a expansão das práticas de DevOps para o grupo mais amplo de equipes de TI e 
prestação de serviços. 
No estágio 3, as práticas de DevOps se espalham para além das equipes de 
desenvolvimento e operações, onde primeiro criaram suas raízes. À medida que a 
colaboração aumenta e a organização se concentra em melhorias em torno do 
gerenciamento de serviços, implantação, redução de tempos de espera e minimização de 
aprovações, esses esforços afetam as áreas além dos departamentos de tecnologia. O 
compartilhamento de ferramentas, aplicativos e serviços aprimorados – assim como o 
conhecimento – com outras áreas funcionais da empresa agora se torna fundamental 
para expandir o sucesso anterior do DevOps e dimensionar o DevOps em toda a 
organização. 
As pesquisa do instituto DORA mostraram que o estágio 3 é onde as iniciativas de 
DevOps mudam de pequenos grupos de sucesso em algumas equipes para uma onda que 
se espalha e eventualmente transforma toda a organização. 
Foi também observado em achados do grupo que o Estágio 2 (reduzindo a variação 
na pilha de tecnologia) e a Etapa 3 pode ocorrer em ordem direta, em ordem inversa ou 
ao mesmo tempo. Mas ambos precisam acontecer antes de progredir para o estágio 4 
(automatizar a entrega da infraestrutura). 
Ou seja, faz mais sentido concentrar-se na redução da variabilidade nos estágios iniciais, 
de modo que haja menos ocorrências para gerenciar, economizando tempo e distração 
de sua equipe. Mas se isso não for possível porque algumas dessas coisas estão fora do 
seu controle, trabalhe primeiro nas coisas que você pode controlar. O mais importante é 
que a equipe de gerenciamento de serviços de TI e quaisquer outras equipes que 
dependem de serviços trabalhem juntas durante esse estágio. 
As práticas definidoras no estágio 3 são: 
 Os indivíduos tem autonomia para poder trabalhar sem aprovação manual de 
fora da equipe (ex. gerentes e áreas de negócio). E isso foi alcançado através da 
confiabilidade obtida na busca das práticas do estágio 2. 
 Padrões de implantação para criar aplicativos e serviços são reutilizados. 
Outras práticas importantes para estágio são: 
 Os indivíduos conseguem fazer alterações com tempos de espera reduzidos (lead 
times). 
 Mudanças de serviço podem ser feitas durante o horário comercial. 
 Revisões pós-incidente ocorrem e os resultados são compartilhados. 
 Equipes constroem código em um conjunto padrão de tecnologias. 
 Equipes usam integração contínua. 
 As equipes de infraestrutura usam também controle de versão. 
Etapa 4: Automatizar a entrega da infraestrutura 
O estágio 4 é onde as equipes de infraestrutura estão no centro da atenção. As práticas 
definidoras neste estágio são sobre automatizar a entrega de infraestrutura – o que 
muitos pensamcomo o início de uma iniciativa de DevOps. 
Essas práticas de automação de infra-estrutura aparecem mais tarde na jornada 
evolucionária do que podemos esperar. Isso porque são ativadas por coisas que 
caracterizam estágios anteriores: normalização, redução de variáveis e expansão da 
evolução do DevOps para além das equipes de tecnologia nos negócios. Sucesso em 
estabelecer esses fatores em estágios iniciais torna muito mais fácil alcançar o sucesso 
no Estágio 4. 
E isso não quer dizer que a automação de infraestrutura não está acontecendo em 
estágios anteriores. Já no Estágio 0: Construir a base, a prática de gerenciar 
configurações de infraestrutura com uma ferramenta de gerenciamento de configuração 
rapidamente se instala desde o início, quando as equipes de operações estão buscando 
padronizar para resolver suas próprias necessidades. 
A principal diferença no estágio 4 é que o objetivo de conduzir a automação de 
infraestrutura nesse estágio é proporcionar maior agilidade a todo o negócio, não apenas 
para uma única equipe. 
Embora esse estágio seja gratificante – parece que você está realmente fazendo o 
DevOps agora – é importante reconhecer que os estágios anteriores possibilitam a 
automação da infraestrutura. O instituto DORA viu organizações tentando saltar 
imediatamente para este 
estágio sem passar pelos estágios anteriores. E o resultado é a frustração. É preciso que 
essas organizações demorem mais do que o esperado para fazer qualquer progresso real 
com a automação da infraestrutura. 
As equipes de infra-estrutura nesse estágio da jornada de DevOps começam a adotar 
práticas de desenvolvimento ágil, como o uso de controle de versão para configuração 
do sistema e configurações de aplicativos, e adotam ferramentas usadas pelas equipes de 
desenvolvimento de aplicativos. As equipes, nesse estágio, também automatizam as 
configurações de políticas de segurança dentro de sua esfera de influência. 
As práticas centrais para o estágio 4 são: 
 As configurações do sistema são automatizadas. 
 O provisionamento é automatizado. 
E algumas práticas associadas são: 
 Configurações de aplicativo estão no controle de versão. 
 As equipes de infraestrutura usam o controle de versão. 
Estágio 5: Fornecer recursos de autoatendimento 
Para passar para o Estágio 5, uma organização deve ter os seus vários departamentos 
comprometidos em fornecer recursos de TI como um serviço para a empresa, em vez de 
tratar a TI como um centro de custo que executa ordens de serviço. Esses departamentos 
incluem desenvolvimento, qualidade, operações, segurança, ITSM e outras áreas 
funcionais. 
Neste último estágio da evolução do DevOps, os benefícios para a organização 
multiplicarem-se enormemente à medida que a colaboração bem-sucedida entre os 
limites funcionais se acelera. 
Esses ganhos são vistos em várias áreas distintas: 
 A arquitetura de aplicativos vai além da padronização de tecnologias e começa a 
evoluir no sentido de trabalhar e suportar a migração na nuvem, a adoção de 
contêineres e a proliferação de microsserviços. 
 A automação da política de segurança passa de atender as necessidades de uma 
equipe para se tornar a linha de base de como a segurança e a conformidade são 
medidas em todo o departamento, ou mesmo em toda a organização. Além disso, 
o provisionamento automatizado avança para o provisionamento de ambientes 
completos para desenvolvedores, testadores e outras equipes técnicas. 
Uma vez que você comece a ter sucesso em múltiplos limites funcionais, os pilares do 
DevOps – (CAMS) Cultura, Automação, Mensuração e Compartilhamento – tornam-se 
mais difundidos em toda a organização. 
As duas práticas de definição para o estágio 5 são: 
 Respostas a incidentes são automatizadas. 
 Recursos de TI (ex. máquinas ou conteineres) estão disponíveis via 
autoatendimento. 
As duas práticas associadas neste estágio são: 
 Aplicativos de arquitetura com base nas necessidades de negócios. 
 As equipes de segurança estão envolvidas no design e na implantação de 
tecnologia. 
Resumo do relatório 
Em resumo, os dados coletados pelo instituto DORA mostraram que embora existam 
muitos caminhos individuais por meio de uma transformação DevOps, há maneiras de 
atingir e dimensionar o sucesso mais rapidamente. As organizações têm uma escolha: 
elas podem escolher ser sistemáticas sobre como elas evoluem ou podem adotar uma 
abordagem mais dispersa. É claro que é possível que até mesmo uma abordagem ad-hoc 
funcione, mas o que foi observado nas organizações que atingiram os níveis mais altos 
da evolução do DevOps é que elas não chegaram lá por acaso. 
 
O Todo Poderoso Gráfico do Fluxo Cumulativo 
de Valor 
Figuras brilhantes da administração moderna, como Peter Drucker, já diziam que é 
inútil tentar gerenciar um sistema de trabalho sem um sistema consistente de medições e 
métricas. Se você já trabalha com métodos ágeis isso é ainda mais importante pois 
métodos ágeis são baseados nos princípios de transparência radical, feedbacks e 
replanejamentos contínuos. Sem números apropriados, não conseguimos avançar na 
maturidade do uso de métodos ágeis. 
Felizmente, existe um gráfico simples e superpoderoso que pode ser facilmente usado 
por times ágeis. Esse gráfico lhe dará muitas informações valiosas, tais como: 
1. A representação das entregas realizadas no fluxo de valor do seu sistema de 
trabalho. 
2. O tempo médio que o seu sistema de trabalho demora para processar um novo 
pedido ou requisito. (lead time ou tempo de atravessamento). 
3. O tempo médio que cada papel ou área do seu sistema de trabalho demanda para 
processar novos itens. (cycle time ou tempo de ciclo). 
4. A quantidade de itens que estão sendo processados em um determinado 
momento do tempo (WIP ou trabalho em progresso). 
5. Observar mudanças de escopo ao longo do tempo 
6. Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. 
(throughput) 
7. Observar gargalos 
8. Estimar quando o seu projeto irá terminar 
Ferramentas normalmente usadas por times ágeis, como por exemplo o Microsoft 
VSTS/TFS, JIRA Agile, Redmine ou o Trello com plugins, já constroem 
automaticamente esse gráfico e liberam o nosso tempo para a análise intelectual das 
informações. Ao mesmo tempo, você pode criá-los em ferramentas de planilhas simples 
como o Google Sheets ou o Excel. Irei fazer isso ao longo desse post para que você 
possa entender como construir e interpretar esse gráfico. 
Construindo o Gráfico do Fluxo Cumulativo de Valor 
O nome do nosso super-gráfico é fluxo cumulativo de valor e é também chamado de 
CFD ou Burn-Up. 
Os passos essenciais para a construção desse gráfico são: 
1. Decidir que tipo de informação será medida. 
2. Decidir a frequência da análise. 
3. Decidir que etapas do fluxo de valor serão medidas. 
Vamos trabalhar com um primeiro exemplo onde queremos analisar os incidentes que 
são atendidos por uma área de suporte de um produto. A nossa análise nesse exemplo 
será semanal e iremos analisar as seguintes etapas: novos incidentes, incidentes em 
tratamento e incidentes fechados. 
Primeiro monte uma tabela com as informações dos incidentes em cada estado ao longo 
de cada semana. 
 
Depois você deve somar os dados em cada semana, i.e, em cada semana iremos ver 
todos os incidentes naquele estado. Na semana 2, portanto, teremos 17 incidentes no 
estado aberto, 10 em execução e 7 fechados. Isso irá gerar uma planilha simples 
conforme mostrado abaixo. 
 
Agora iremos representar isso visualmente em um gráfico de área 2D (Area Chart Non 
Stackable no Google Sheets ou Área 2D no Excel). O resultado abaixo será mostrado. 
 
 
Extraindo Informaçõesdo Gráfico Cumulativo de 
Valor 
Vamos agora interpretar as informações trazidas por esse gráfico. 
A representação das entregas realizadas no fluxo de valor do seu sistema de 
trabalho. 
O primeiro fato a ser extraído do gráfico é como o seu sistema de trabalho está se 
comportando conforme o seu fluxo de valor, que é a coleção de etapas ou estados 
através dos quais podemos observar o sistema de trabalho. 
Podemos observar que nas 4 primeiras semanas tivemos 52 incidentes abertos, 33 itens 
em execução e 19 fechados. Já na semana 6 observamos 78 itens abertos, 51 em 
execução e 40 itens fechados. E isso indica que o sistema na semana 6 está menos 
saudável que na semana 4 pois existe um acúmulo maior de itens nos estados aberto ou 
em execução. Colocado de outra forma, podemos ver que na semana 4 existe um 
acúmulo de 33 itens (52 itens abertos – 19 itens fechados). Já na semana 6 temos 38 
itens acumulados (78 itens abertos – 40 itens fechados). 
Se observamos a figura, podemos observar como a barriga da área azul. Visualmente 
podemos ver que a barriga na semana 6 se tornou maior que a barriga da semana 4. E 
isso indica que a saúde do sistema piorou. 
Sistemas de trabalho saudáveis devem manter conseguir processar itens em taxas 
similares às suas chegadas. Isso evita filas, troca de contexto e defeitos no 
processamento de pedidos, requisitos, demandas ou encomendas. 
O tempo médio de processamento de pedidos (lead time ou tempo de 
atravessamento) 
Um dos motivos que leva a que métodos ágeis tenham esse nome é que eles buscam 
garantir que um pedido aberto não fique muito tempo dentro do seu sistema de trabalho, 
i.e., um novo pedido ou requisito deveria ser rapidamente construído, verificado e 
liberado para os seus clientes. Chamamos essa métrica global de tempo de 
atravessamento ou lead time. 
Vamos examinar como o lead time pode ser examinado pelo gráfico do fluxo 
cumulativo de valor. Ele pode ser lido através da diferença horizontal entre os itens 
fechados e os itens abertos. 
 
Por exemplo, na semana 5 estamos vendo que os itens fechados correspondem aos itens 
que foram abertos na semana 2. O lead time da semana 5 está perto de 4 semanas, que 
indica que um incidente fica perto de um mês no seu sistema antes de ser finalizado. 
Se observarmos a semana 10, vemos um o sistema ficou ainda menos saudável. Os 
itens fechados na semana 10 foram abertos entre a semana 5 e a semana 6, que indica 
que o lead time médio agora está em cerca de 4 semanas e meia. 
Nos métodos ágeis, buscamos minimizar o lead time. Quanto menor o lead time, mais 
rápida é a capacidade do seu time de processar pedidos. E portanto a medição do lead 
time é em minha opinião a mais importante métrica a ser observada em sistemas 
baseados em métodos Scrum, Kanban e afins. 
O tempo médio de processamento de pedidos por papel ou área (cycle time) 
Se o lead time mostra o tempo total de atravessamento no nosso sistema de trabalho, 
podemos usar o mesmo racional para examinar como uma etapa do trabalho (papel ou 
área) está se comportando. Considere o gráfico abaixo como exemplo. 
 
Aqui estamos observar o tempo de ciclo da etapa de execução, i.e, o tempo médio que 
um incidente demorou para ser efetivamente resolvido uma vez que ele começou a ser 
tratado pela equipe. Podemos ver que o tempo de ciclo na semana 5 era de um pouco 
mais de 1 semana. Já na semana 10 o tempo de ciclo já era de 3 semanas, indicando que 
o time de execução claramente não está conseguindo liberar incidentes na mesma taxa 
que eles estão chegando. 
Veja ainda que o tempo de ciclo pode ser analisado em outras etapas. Por exemplo, no 
gráfico abaixo podemos observar o tempo de ciclo da etapa de Novos Incidentes. 
 
Aqui podemos ver que na semana 3 um incidente demorava, em média, uma semana e 
meia até começar a ser tratado pelo time. Já na semana 10 um item ficava aberto quase 4 
semanas até começar a ser tratado pelo time. 
Longos tempos de ciclo para uma etapa indicam que a área associada aquele trabalho 
está com dificuldades. E isso indica que a gestão deve buscar formas de apoiar aquele 
time para reduzir nos gargalos. Ao invés de permitir a chegada de novos itens de foram 
desenfreada (ilusão de controle) ou fazer ameaças (management 1.0) a gestão ágil deve 
promover enxames de ajudantes de outras áreas e funções para desafogar o time com 
dificuldades e com isso reestabilizar o sistema. 
A quantidade de itens que estão sendo processados em um determinado momento 
do tempo (WIP ou trabalho em progresso). 
Esse gráfico é tão legal que podemos observar também como os itens estão se 
acumulando no sistema de trabalho. A isso chamamos de trabalho em progresso ou WIP 
(Work In Progress). Valores altos do WIP indicam que o seu sistema não está saudável 
pois indica que as pessoas estão tentando fazendo muita coisa ao longo de uma semana. 
Isso leva a interrupções no trabalho, trocas de contexto e esgotamento mental pelo seu 
time. 
No gráfico abaixo, podemos observar que o WIP da semana 10 é claramente pior que o 
WIP da semana 02, mostrando como o sistema está se degradando ao longo do tempo. 
 
De fato, se você observar os dados da planilha fornecida no exemplo você irá observar 
que o WIP da semana 02 era de 19 itens (26 – 7). Já o WIP na semana era de 37 itens 
(119 – 72). 
Observar mudanças de escopo ao longo do tempo 
Vamos considerar o contexto de um time que precise construir um produto e fez um 
levantamento inicial dos requisitos do produto. Esse time trabalha em um fluxo de valor 
com os estados: Backlog, Em Análise, Em desenvolvimento, Em testes, Em 
homologação e Fechado. 
O gráfico mostrado abaixo mostra que houve um intenso esforço na descoberta de 
requisitos nas semanas 2 e 3. E o gráfico também mostra que houve mudanças de 
escopo ao longo da semana 8 (12 novos itens surgiram). E se o projeto foi baseado em 
premissa de escopo fechado, isso indica um sinal gerencial amarelo que sinaliza que 
novos sprints talvez sejam necessários para completar o escopo recem-descoberto. 
 
Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. 
(throughput) 
Podemos observar ainda um aspecto bem importante na saúde de um sistema que é a 
sua vazão, ou taxa de produção de itens no tempo. Por exemplo, considere o seguinte 
gráfico. 
 
Explicitei nesse gráfico a vazão dos responsáveis pelo desenvolvimento nas semanas 4, 
5, 6 e 7. Observe que quanto maior a inclinação da seta, maior é a vazão. E então 
podemos observar que o time de desenvolvimento teve um problema mais sério entre a 
semana 5 e 6. A inclinação da seta aqui está muito baixa nesse região do gráfico. Talvez 
algum dos desenvolvedores tenha sido alocado em outro projeto ou algum aspecto 
técnico da arquitetura ainda não explorado do produto tenha surgido e atrasado o 
trabalho de todos eles. 
A análise da vazão ao longo de cada etapa é um instrumento importante para o Scrum 
Master, Agile Coach e time analisar a saúde e estabilidade do sistema de trabalho. 
Observar gargalos 
Um outro superpoder desse gráfico é permitir que você analise gargalos. E para isso 
vamos habilitar as linhas de tendência das etapas inicial e final desse sistema de trabalho 
(novos requisitos no backlog e requisitos fechados). As linhas de tendência são criadas 
pela opção Trend Lines no Google Sheets e Excel e são observadas pelas linhas 
vermelha e preta nesse exemplo. 
 
Se a inclinação das linhas é igual isso indicaria que o sistema está saudável. No caso 
aqui, estamos vendo que a inclinação da linha vermelha é maior que a inclinação da 
linha preta. E isso indica que mais itens estão chegando do que itens saem do sistema de 
trabalho.Podemos fazer essa análise comparando quaisquer duas etapas (ex. desenvolvimento 
versus testes ou análise versus testes), para todo o intervalo de tempo ou para um 
período de análise. As inclinações das retas nos permitem analisar se gargalos estão 
sendo formados. 
E se você observar um gargalo, é o momento de ligar um sinal amarelo e analisar como 
podemos pensar coletivamente e apoiar área que está apresentando dificuldades. 
Estimar quando o seu projeto irá terminar 
Por último, mas não menos importante, esse gráfico lhe dá também uma oportunidade 
de estimar quando o projeto provavelmente irá terminar. Vamos considerar o gráfico 
mostrado abaixo, onde explicito a quantidade de itens fechados ao longo do tempo e 
também a quantidade de itens que devem ser realizados ao longo do projeto. 
 
Uma heurística simples que podemos usar aqui é a regra de três sobre os itens fechados 
até o momento. No nosso exemplo temos 28 itens que foram fechados em 10 semanas. 
E como temos 117 itens a serem realizados, o tempo total para finalizarmos todos os 
itens no escopo seria calculado como: 117/28 *10 = 41 semanas. 
Essa abordagem, pois mais simplista que pareça, trabalha com o princípio básico que a 
velocidade passada é um excelente preditor da velocidade futura em um sistema. E isso 
se torna cada vez mais verdade quando você tem um bom número de observações ao 
longo do tempo. 
Erros Comuns no uso do Fluxo Cumulativo de Valor 
Embora esse gráfico seja extremamente poderoso, devemos ter atenção a alguns pontos 
para não usarmos a ferramenta de forma errada. Alguns erros incluem: 
1. Começar com um fluxo de valor complexo. Recomendo começar com um fluxo 
simples (A Fazer, Em execução, Finalizado) e incluir mais estados a medida que 
você e o seu time se acostumarem com o instrumento. 
2. Possui uma definição fraca de Finalizado. Finalizado é algo que está pronto para 
os seus usuários finais. Se você trabalha com entrega de livros, Finalizado 
significa que o seu livro está na casa do seu cliente. Se você trabalha com uma 
cozinha, Finalizado significa que o seu cliente está almoçando o prato que ele 
pediu há 30 minutos atrás. E se você trabalha com desenvolvimento de software, 
Finalizado implica que o aquela funcionalidade está nas mãos dos seus usuários 
no ambiente de produção. 
3. Não possuir Critérios de Aceite para mover um item ao longo do fluxo de 
valor. É fundamental que o time defina critérios objetivos que permitam avaliar 
se um item pode transitar de um estado para outro no fluxo de valor. Isso evita 
falsos positivos e a maquiagem de dados. 
4. Não comunicar o gráfico. Esse gráfico deve ser afixado em base periódica nas 
paredes do local de trabalho do seu time ou exibido na TV da sua sala. Esconder 
esse gráfico em alguma planilha obscura na rede não irá ajudar ao seu time, nem 
você. 
5. Ter uma frequência baixa de atualização. O poder do gráfico cumulativo de 
valor vem das interpretações que conseguimos obter das medidas ao longo do 
tempo. (WIP, Lead Time, Taxas e Gargalos). E isso depende de um ciclo de 
amostragem regular. Recomendo um ciclo mínimo de uma semana. mas se você 
coletar os números em base ainda menor você terá insumos ainda melhores. 
6. Adotar esse gráfico apenas para um único tipo de informação. Todo sistema 
complexo deve ser examinado em diferentes níveis. E cada nível lhe dar 
perspectivas diferentes de análise. Por exemplo, na construção de produtos 
podemos analisar Épicos, Features ou Histórias. E podemos ter gráficos CFD 
para cada um desse itens, que permite que você observe a saúde do sistema em 
níveis distintos e possa extrair interpretações mais robustas. 
 
A planilha mostrada nesse exemplo está compartilhada aqui para seus estudos sobre o 
CFD. 
 
 
 
 
Organizando o Trabalho em Squads 
Morrem os projetos e nasce o fluxo contínuo 
de produtos 
Na maioria das empresas que possuem áreas de TI, existe uma dicotomia muito bem 
estabelecida entre pessoas que entregam produtos de software através de projetos e 
pessoas que sustentam esses softwares, cuidando das manutenções corretivas, 
adaptativas e pequenas demandas evolutivas. 
Muitas pessoas que trabalham na TI nunca viram um outro modelo e acreditam que isso 
é a forma natural de organizar o trabalho. Se você é uma dessas pessoas, pare e pense 
na consequência desse desenho organizacional. Provavelmente você deve lidar com 
alguns problemas tais como: 
 Os seus times de projetos nunca se tornam especialistas em anda pois eles estão 
continuamente mudando de assunto devido a orçamentação centrada em projetos 
e a consequente alocação e deslocação das pessoas dos projetos tão logo eles 
terminem. 
 Os times de projetos são incentivados a entregar seus projetos no prazo, custo e 
com o escopo acordado. E ao tentar fazer isso, eles são naturalmente 
incentivados a “flexibilizar” a qualidade do produto. “Testes de unidade 
automatizados? Não tenho tempo para isso. Código limpo? Então. Também não 
tenho tempo. BDD. Nem pensar.. estou atrasado!”. 
 A área de projetos não se responsabiliza pela qualidade do produto. Como o seu 
papel é entregar software o mais rápido possível nos ambientes de produção. a 
qualidade é “problema” da sustentação e da infraestrutura. 
 Existe um gasto enorme de dinheiro com incidentes em sustentação. Acompanho 
empresas com TIs enormes e ainda fico impressionado com o montante 
financeiro gasto em incidentes e defeitos. 
 Começam a surgir conflitos entre times de desenvolvimento, times de 
sustentação e times de infraestrutura. Dedos são apontados de lado a lado e as 
atribuições de culpa pelos software de baixa qualidade pipocam. O desenho da 
organização, e não as pessoas, cria esse conflito. 
 Existem times distintos que alteram o código fonte do produto e isso provoca a 
criação de complexidade acidental na forma de branches desnecessários, 
sistemas de lotes e filas, que reduzem o tempo total de entrega e baixa a 
percepção de valor para os usuários finais. 
As Squads como alternativas para a cultura projetizada 
Uma Squad deve ser estruturado como um time coeso que esteja alocado no 
desenvolvimento e sustentação de um produto ou fluxo de valor de uma organização. 
Ao fazer isso você redesenha o sistema tático da sua TI e provoca o seguinte: 
 Todos são agora responsáveis pela qualidade. Se você codificou mal e não 
testou, é sua responsabilidade. E você vai pagar por isso daqui a algumas 
semanas em produção. Quando você, enquanto líder, desenha a sua cozinha para 
fazer com que os cozinheiros comam a comida que eles estão cozinhando, você 
muda a percepção deles sobre o impacto dos atalhos. 
 Não existem mais dedos apontados para fora. A Squad, inclusive com o seu 
líder, é responsável pelos eventos que ocorrem. Incidentes vão ocorre, 
obviamente, mas é papel da Squad rodar suas retrospectivas para lidar com o 
aprendizado e melhorar continuamente. 
 O aprendizado e a produtividade aumentam. Se você mantém pessoas juntas 
durante um longo tempo com ritos kaizen periódicos, isso habilita o aprendizado 
organizacional e com isso a produtividade desses times na implementação de 
novas funcionalidade. 
 Você incentiva o estabelecimento da cultura de times. Times são estruturas 
poderosas para lidar em ambientes complexos. Atribuir metas a times e reforçar 
a cultura de times promove um senso de equipe e permite também atenuar as 
nossas fraquezas individuais. 
Squads sim, mas do jeito correto 
O conceito de fluxo contínuo de valor é fundamental para implementarmos Squads da 
forma correta. E isso significa que: 
 Você tem um PO e pessoas da área de negócio que estão permanentemente 
priorizando o que é valor denegócio. Fixar o escopo por 6 meses porque o 
gerente mandou não é mais a forma apropriada de trabalhar. Ao invés, você tem 
um backlog que é permanentemente repriorizado e o item de maior valor é 
puxado pelo time quando o item que estava em trabalho foi entregue em 
produção. No Lean, chamamos isso de sistemas puxados (Pull Systems). 
 Você deve medir continuamente o retorno de valor de negócio trazido pela sua 
Squad. E isso é fundamental para avaliar se o investimento que está sendo 
realizado na sua Squad faz sentido. E, na prática, se o seu produto de negócio ou 
fluxo de valor não tem tração no mercado, a Squad é reduzida ou desmobilizada. 
 Você deve entregar em produção em ciclos curtos. Entregas semestrais ou anuais 
em produção, portanto, não fazem mais sentido. E portanto os “itens” de 
trabalho, na forma de histórias ou features, devem ser pequenos. Idealmente, 
cada história deveria caber em uma semana (ou duas). E as tarefas do time 
devem ser estruturadas em não mais que 6 horas diária. No mundo Toyota/Lean, 
chamamos isso de “One Piece Flow” e foco implacável no “Lead Time”. 
 A qualidade contínua se torna parte do processo. Para isso, você usa técnicas 
diversas hoje estruturadas em corpos de conhecimento DevOps tais como: 
Automação de Testes de Unidade, Automação da Verificação do Código, Smoke 
Tests, Automação de Builds, Integração Contínua e Entrega Contínua. Esses 
conceitos DevOps são a forma moderna da TI implementar o conceito 
Lean/Toyota chamado de Jidoka. 
 Qualquer decisão de otimização deve avaliar o efeito sobre todo o fluxo de valor 
de negócio. Metas locais para o time de testes como remoção de defeitos perdem 
sentido. E esse também um dos princípios Lean. 
Ao fazer isso, você ganha um desenho da sua TI que irá lidar melhor em um mundo 
complexo, não determinístico e imprevisível. 
O Manifesto Ágil das Squads 
Se houvesse uma manifesto ágil das Squads, ele seria parecido com isso. 
Fluxo de valor e produtos de negócio mais que projetos de software. 
Entregas contínuas mais que longos ciclos de desenvolvimento e homologação. 
Qualidade contínua nos produtos de negócio mais que foco míope em prazos. 
Otimização do fluxo de valor mais que sub-otimização do trabalho de 
desenvolvimento, testes ou infraestrutura. 
Mas… e o meu escritório de projetos? 
Você pode estar pensando. Isso parece legal, mas o meu escritório não me deixa fazer 
isso. 
Confesso que isso realmente é tenso. Em várias implementações que participei, temos 
que destacar tempo de qualidade para evangelizar o escritório de projetos. E em várias 
vezes, não funciona mesmo. 
O que tenho observado são abordagens diversas para lidar com isso, tais como: 
1. Operar abaixo do radar do PMO (mais conservadora e provavelmente mais 
inteligente). 
Quando você tem um PMO arcaico ou resistente, pode ser impossível buscar 
uma mudança de abordagem. Operar abaixo do radar implica que você possui 
Squads internamente dentro da sua TI com o propósito de evoluir produtos de 
negócio, mas a linguagem de comunicação com a empresa e interessados de 
negócio ainda será a linguagem de projetos. Isso exige que você faça uma 
prospecção ativa de projetos para conseguir garantir a orçamentação do seu 
Squad ou de pelo menos uma parte das pessoas do seu Squads. E isso pode 
implicar em que sua Squad precise cuidar de mais de um produto para que seja 
possível financiá-la. 
2. Negociar a orçamentação anual por produtos de negócio, mas estabelecer 
uma lógica de desembolso centrada em projetos.Nessa abordagem o PMO 
tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer 
mudar a lógica de funcionamento de um PMO, que poderia gerar muita 
resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite 
orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será 
investido através de projetos do PMO que irão financiar uma Squad durante esse 
ano fiscal.Observe que nessa abordagem não basta medir o sucesso financeiro 
baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e 
medir o retorno financeiro trazido para a organização no investimento em um 
produto de negócio. Squads devem ser medidas, primordialmente, pelos 
resultados de negócio que seus produtos trazem. 
 
3. Transcender o conceito de projetos, introduzir o conceito de fluxo de valor e 
orçamentação relativizada e convencer o seu escritório dissoAlgumas 
empresas sublimaram o conceito de projetos e trabalham com o conceito de 
fluxo continuado de valor de negócio. Nessa abordagem você estabelece em 
base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza 
os itens mais importantes do bacilo que cabem naquele período de tempo. E 
você mede periodicamente como foi a agregação de valor de negócio por essa 
Squad. Se a agregação de valor foi frutífera, você coloca mais investimento 
naquela Squad. Se os resultados na perspectiva de negócio são ruins, você reduz 
ou desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido. 
O método ágil em escala organizacional chamado SAFE trabalha com 
essa abordagem e tem sido muito usado em algumas grandes empresas para 
facilitar a transição para esse modelo. 
 
Referências Adicionais: 
 Cultivando Squads – Dicas Práticas para Gerentes de Projeto e Líderes Técnicos 
 Afinal, o que faz o gerente na minha Squad? 
 Como operacionalizar Squads na minha empresa? 
 
 
 
Os três princípios fundamentais dos métodos ágeis 
e do DevOps 
Muitos times já aprenderam que fazer Scrum não é (apenas) colocar um conjunto de 
pessoas em uma sala e executar ritos como um planejamento de sprint ou uma 
retrospectiva. Se observamos por exemplo que o gerente determina as tarefas do time e 
interrompe as falas de um colaborador que traz uma sugestão, sabemos que não estamos 
vivendo um ambiente ágil. É como se estivéssemos observado um animal que possui 
penas e bota ovos, mas você percebe que não se trata de um pássaro verdadeiro ao olhar 
a boca dele. 
Acompanhei um caso em uma empresa em 2016 onde um determinado analista, muito 
bem intencionado, me disse que eles possuíam o DevOps muito bem implementado. E 
então ele me mostrou todo um conjunto de pipelines de gestão de builds e releases 
implementados no Visual Studio Team System. Ele também me mostrou painéis 
técnicos dos vários projetos no Sonar Source e muitas estatísticas geradas. 
E então eu perguntei como os times estavam usando isso para melhorar suas práticas. E 
a resposta foi que ele não tinha autorização do seu gerente para buscar intervenções de 
melhoria nos times. (!?) E mais um bicho estranho me veio à cabeça – um animal com 
bico de pato, que bota ovos, nada muito bem, mas que não é um pássaro. 
Um dos maiores riscos à adoção do ágil e do DevOps é que as pessoas não 
compreendam os princípios que levaram à criação dessas práticas. Isso porque os times 
e os resultados não irão melhorar realmente sem que os princípios fundamentais 
da agilidade sejam internalizados. E então podemos ter conclusões precipitadas na 
esfera gerencial que podem levar ao descrédito nos métodos e o retorno ao modo 
anterior de trabalho. 
A Origem dos Princípios Ágeis e DevOps – Sistemas de 
Produção Lean 
Um dos conceitos fundamentais no Lean é o fluxo de valor (Value Streams). Vamos 
defini-lo primeiro no contexto da manufatura e depois extrapolar como ele se aplica ao 
DevOps e ao fluxo de valor de TI. Podemos definir o fluxo de valor como “a sequência 
de atividades que uma organização empreende para atender a uma solicitação do 
cliente” ou “a sequência de atividades necessárias para projetar, produzir e entregar um 
bem ou serviço a um cliente,incluindo os fluxos de informação e material. 
Nas operações de manufatura, o fluxo de valor é geralmente fácil de ver e observar. Ele 
começa quando um pedido do cliente é recebido e as matérias-primas são liberadas no 
chão-de-fábrica. Para permitir tempos de execução rápidos e previsíveis em qualquer 
fluxo de valor, normalmente há um foco implacável na criação de um fluxo leve e 
uniforme de trabalho, usando técnicas como pequenos tamanhos de lote e redução do 
trabalho em progresso (WIP). Buscamos também evitar o retrabalho para garantir que 
não transmitamos defeitos para as próximas etapas do processo. Finalmente, buscamos 
otimizar continuamente nosso sistema em direção aos nossos objetivos globais. 
Os mesmos princípios e padrões que permitem o fluxo rápido de trabalho em processos 
físicos são igualmente aplicáveis ao trabalho de tecnologia de informação ou qualquer 
outro trabalho de natureza de conhecimento. No mundo Agile e DevOps, normalmente 
definimos nosso fluxo de valor de tecnologia como o processo necessário para converter 
uma hipótese de negócios em um serviço habilitado por tecnologia que agregue valor ao 
cliente. 
A entrada para o nosso processo é a formulação de um objetivo de negócio, conceito, 
ideia ou hipótese. El começa quando aceitamos o trabalho em Desenvolvimento, 
adicionando-o ao nosso backlogde trabalho. A partir daí as equipes de desenvolvimento 
que seguem um processo ágil ou iterativo típico provavelmente transformarão essa ideia 
em histórias de usuários e em algum tipo de especificação de recurso, que é 
implementada em código no aplicativo ou serviço que está sendo construído. O código é 
então guardado no repositório de controle de versão, onde cada alteração é integrada e 
testada com o restante do sistema de software. 
Como o valor é criado somente quando nossos serviços estão sendo executados na 
produção, devemos garantir que não apenas fornecemos fluxo rápido, mas que nossas 
implantações também podem ser realizadas sem causar caos e interrupções, como 
interrupções de serviço ou deficiências de atendimento a requisitos de performance, 
segurança e usabilidade, entre outros. 
O Foco Implacável no Tempo de Entrega 
Em implantações Ágeis DevOps, nossa atenção deve estar no tempo total de entrega dos 
itens do backlog a até a produção (Lead Time). Esse fluxo de valor começa quando 
qualquer analista em nosso fluxo de valor verifica uma alteração no controle de versão e 
termina quando essa alteração é executada com êxito na produção, fornecendo valor ao 
cliente e gerando feedback útil e telemetria. 
Em empresas tradicionais muitas vezes nos encontramos em situações em que os prazos 
de implantação exigem meses. Isso é especialmente comum em organizações grandes e 
complexas que trabalham com aplicativos monolíticos muito acoplados, geralmente 
com ambientes de teste de integração escassos, longos períodos de teste nos 
departamentos de qualidade, alta dependência de testes manuais e muitos processos 
manuais de aprovação. 
Quando temos longos tempos de implantação, precisamos de super-heróis em quase 
todos os estágios do fluxo de valor. Podemos descobrir que nada funciona no final do 
projeto quando integramos todas as alterações da equipe de desenvolvimento, 
resultando em códigos que não são mais compilados corretamente ou que não passam 
em nossos testes. A correção de cada problema requer dias ou semanas de investigação 
para determinar quem quebrou o código e como ele pode ser corrigido e ainda resulta 
em resultados insatisfatórios para os clientes. 
Ao falar de ágil e DevOps, os desenvolvedores recebem feedback rápido e constante 
sobre seu trabalho, o que permite que implementem, integrem e validem seu código de 
maneira rápida e independente e com isso implantem o código no ambiente de produção 
sem efeitos colaterais. 
Conseguimos isso verificando continuamente pequenas alterações de código em nosso 
repositório de controle de versão, realizando testes automatizados e exploratórios e 
implementando-o na produção. Isso nos permite ter um alto grau de confiança de que 
nossas alterações funcionarão conforme projetado na produção e que quaisquer 
problemas podem ser rapidamente detectados e corrigidos. Isso é mais facilmente 
alcançado quando temos uma arquitetura modular, bem encapsulada e fracamente 
acoplada, para que as pequenas equipes possam trabalhar com alto grau de autonomia, 
com falhas pequenas e contidas, sem causar interrupções globais. 
De fato, times DevOps desenvolvem um sistema de trabalho que os permitem entregar 
software em produção em base diária. Exemplos de empresas que publicados relatos 
impressionantes dessa agilidade de negócio incluem a Amazon, Netflix, WalMart, 
Target, Nordstorm, Facebook, Adobe e Sony, entre outras. 
Mas, afinal, que princípios são esses que permeiam o ágil e o DevOps e o que eles 
dizem de tão importante? 
“Os três princípios deve você usar para habilitar a força dos métodos ágeis e DevOps” 
Princípio #1 – Fluxo Contínuo 
No fluxo de valor de TI, o trabalho normalmente flui de Desenvolvimento para 
Operações. O primeiro princípio demanda o fluxo rápido e suave do trabalho desde o 
Desenvolvimento até as Operações para entregar valor aos clientes rapidamente. Nós 
otimizamos esse objetivo global mais que metas locais, como taxas de conclusão de 
tarefas de desenvolvimento, taxa de correção de testes ou medidas de disponibilidade de 
operações. 
Aumentamos o fluxo tornando o trabalho visível, reduzindo o tamanho dos lotes e os 
intervalos de trabalho e criando qualidade, evitando que os defeitos sejam transmitidos 
aos estágios anteriores de trabalho. Ao acelerar o fluxo através do fluxo de valor da 
tecnologia, reduzimos o tempo de espera necessário para atender às solicitações dos 
clientes internos e externos, aumentando ainda mais a qualidade do nosso trabalho, 
tornando-nos mais ágeis e capazes de superar a concorrência. 
Nosso objetivo aqui é diminuir o tempo necessário para que as mudanças sejam 
implantadas na produção e aumentar a confiabilidade e a qualidade desses serviços. 
Dicas sobre como fazemos isso no fluxo de valor da tecnologia podem ser obtidas a 
partir de como os princípios do Lean foram aplicados ao fluxo de valor na indústria e 
incluem: 
 Tornar o trabalho visível; 
 Limitar o trabalho em progresso; 
 Reduzir o trabalho em lotes; 
 Reduzir os repasses; 
 Identificar e limpar impedimentos e 
 Reduzir a dificuldade do trabalho diário. 
 
Princípio #2 – Feedbacks Frequentes 
O segundo princípio descreve os mecanismos que permitem feedbacks rápidos da 
direita para a esquerda em todos os estágios do fluxo de valor. Como exemplo, feedback 
dos times de operações para implantadores e feedbacks dos analisas de testes para 
implementadores. O nosso objetivo é criar um sistema de trabalho cada vez mais seguro 
e resiliente. 
Na TI, o trabalho acontece quase inteiramente dentro de sistemas complexos com risco 
alto de defeitos e paradas em produção. Como na manufatura, geralmente descobrimos 
problemas apenas quando ocorrem grandes falhas, como uma interrupção de produção 
em massa ou uma violação de segurança que resulta no roubo de dados do cliente. 
Iremos tornar o nosso sistema de trabalho mais seguro através da criação de fluxo de 
informações rápido, frequente e de alta qualidade em todo o fluxo de valor e em nossa 
organização, o que inclui feedback frequente entre toas as pessoas e funções. Isso 
permite detectar e corrigir problemas enquanto eles são menores, mais baratos e mais 
fáceis de consertar; evitar problemas antes que causem catástrofe; e criar aprendizado 
organizacional que integramos no trabalho futuro. Quando fracassos e acidentesocorrem, devemos trata-los como oportunidades de aprendizado, em oposição a uma 
causa de punição e culpa. 
Uma das características que define um sistema complexo é que ele desafia a capacidade 
de qualquer pessoa de ver o sistema como um todo e entender como todas as partes se 
encaixam. Os sistemas complexos normalmente possuem um alto grau de 
interconectividade de componentes fortemente acoplados, e o comportamento no nível 
do sistema não pode ser explicado meramente em termos do comportamento de cada 
componente individual do sistema. 
Falhas são inerentes e inevitáveis em sistemas complexos. E então devemos projetar um 
sistema de trabalho seguro onde possamos executar o trabalho sem medo, confiantes de 
que quaisquer erros serão detectados rapidamente, muito antes de causarem resultados 
catastróficos como danos aos trabalhadores, defeitos no produto ou impacto negativo no 
cliente. 
Projetar sistemas perfeitamente seguros está além da capacidade de qualquer time, mas 
podemos tornar mais seguro trabalhar em sistemas complexos quando as quatro 
condições a seguir são atendidas: 
 O trabalho complexo é gerenciado para que os problemas no design e nas 
operações sejam revelados; 
 Os problemas são tratados coletivamente e resolvidos, resultando na rápida 
construção de novos conhecimentos; 
 Novo conhecimento local é explorado globalmente em toda a organização; 
 Os líderes criam outros líderes que continuamente aumentam as capacidades da 
organização. 
Em um sistema de trabalho seguro, devemos testar constantemente nossas premissas de 
projeto e operação. Nosso objetivo é aumentar o fluxo de informações em nosso sistema 
de tantas áreas quanto possível, mais cedo, mais rápido, mais barato e com tanta clareza 
entre causa e efeito quanto possível. Quanto mais suposições possamos invalidar, mais 
rápido podemos encontrar e corrigir problemas, aumentando nossa resiliência, agilidade 
e capacidade de aprender e inovar. 
No fluxo de valor de TI, muitas vezes obtemos resultados ruins devido à ausência de 
feedback rápido. Por exemplo, em um projeto de software em cascata, podemos 
desenvolver código por semanas ou meses e não obter feedback algum sobre qualidade 
até começarmos a fase de testes – ou, pior ainda, quando lançamos nosso software para 
os clientes. Quando o feedback é atrasado e pouco frequente, é pouco eficaz para 
permitir evitar resultados indesejáveis. 
No mundo DevOps, o nosso objetivo é criar feedback rápido em todos os estágios do 
fluxo de valor de tecnologia, abrangendo Gerenciamento, Desenvolvimento, Controle 
de Qualidade, Segurança da Informação e Operações do Produto. Isso inclui a criação 
de processos automatizados de criação, integração e teste, para que possamos detectar 
imediatamente quando uma alteração foi introduzida que nos tire de um estado de 
funcionamento e implementação corretos. 
Também criamos telemetria abrangente para que possamos ver como todos os nossos 
componentes de sistema estão operando no ambiente de produção, para que possamos 
detectar rapidamente quando eles não estão operando conforme o esperado. A telemetria 
também nos permite medir se estamos atingindo nossas metas pretendidas e, 
idealmente, é irradiada para todo o fluxo de valor, para que possamos ver como nossas 
ações afetam outras partes do sistema como um todo. 
Os loops de feedback não apenas permitem a rápida detecção e recuperação de 
problemas, mas também nos informam sobre como evitar que esses problemas ocorram 
novamente no futuro. Isso aumenta a qualidade e a segurança de nosso sistema de 
trabalho e cria aprendizado organizacional. 
O Terceiro Princípio – Aprendizado Organizacional 
Enquanto o Primeiro Caminho aborda o fluxo de trabalho da esquerda para a direita e o 
Segundo Caminho aborda o feedback rápido e constante recíproco da direita para a 
esquerda, o Terceiro Caminho foca na criação de uma cultura de aprendizagem e 
experimentação contínua. Esses são os princípios que permitem a criação constante de 
conhecimento individual, que é então transformado em conhecimento de equipe e 
organizacional. 
Diversas empresas tem aprendido que a formação de times de alta performance depende 
da promoção da segurança psicológica e do estabelecimento de clareza de 
propósitos. A segurança psicológica é a crença compartilhada pelos membros de uma 
equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é 
uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, 
questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 
Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em 
equipes com maior segurança psicológica são menos propensos a sair do Google, são 
mais propensos a aproveitar o poder de ideias diversas de seus companheiros de equipe, 
trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes. 
Empresas de TI de alto desempenho exigem e promovem ativamente o aprendizado. Em 
vez de o trabalho ser rigidamente definido, o sistema de trabalho é dinâmico, com os 
times realizando experimentos em seu trabalho diário para gerar novas melhorias, 
possibilitadas pela rigorosa padronização dos procedimentos de trabalho e 
documentação dos resultados. 
No fluxo de valor de TI, nosso objetivo é criar uma cultura de alta confiança, reforçando 
que somos todos aprendizes ao longo da vida que devem assumir riscos em nosso 
trabalho diário. Ao aplicar uma abordagem científica para a melhoria de processos e o 
desenvolvimento de produtos, aprendemos com nossos sucessos e fracassos, 
identificando quais ideias não funcionam e reforçando aquelas que funcionam. Além 
disso, qualquer aprendizado local é rapidamente transformado em melhorias globais, de 
modo que novas técnicas e práticas possam ser usadas por toda a organização. 
Reservamos tempo para a melhoria do trabalho diário e para acelerar ainda mais e 
garantir a aprendizagem. Nós constantemente introduzimos estresse em nossos sistemas 
para forçar a melhoria contínua. Podemos até simularmos e injetamos falhas em nossos 
serviços de produção sob condições controladas para aumentar nossa resiliência. E ao 
criar esse sistema contínuo e dinâmico de aprendizado, possibilitamos que as equipes se 
adaptem rápida e automaticamente a um ambiente em constante mudança, o que, em 
última análise, nos ajuda a vencer no mercado. 
Quando trabalhamos dentro de um sistema complexo, por definição, é impossível 
prevermos perfeitamente todos os resultados de qualquer ação que tomemos. É isso que 
contribui para resultados e acidentes inesperados, ou mesmo catastróficos, em nosso 
trabalho diário, mesmo quando tomamos precauções e trabalhamos com cuidado. 
Quando esses acidentes afetam nossos clientes, procuramos entender por que isso 
aconteceu. A causa raiz é muitas vezes considerada como erro humano, e a resposta 
gerencial muito comum é “nomear, culpar e envergonhar” a pessoa que causou o 
problema. E, de forma sutil ou explícita, a gerência sugere que a pessoa culpada 
cometer o erro será punido. Em seguida, eles criam mais processos e aprovações para 
evitar que o erro ocorra novamente. No fluxo de valor da TI, estabelecemos as bases de 
uma cultura generativa, esforçando-nos para criar um sistema de trabalho seguro. 
Quando acidentes e falhas ocorrem, em vez de procurar por erro humano, 
procuramos como podemos redesenhar o sistema para evitar que o acidente 
aconteça novamente. 
Por exemplo, podemos realizar uma análise post-mortem após cada incidente para obter 
o melhor entendimento de como ocorreu o acidente e definir quais são as melhores 
contramedidas para melhorar o sistema, evitando de maneiraideal que o problema volte 
a ocorrer e permitindo uma detecção e recuperação mais rápidas. 
O resultado de eliminar a culpa e colocar o aprendizado organizacional em seu lugar é 
que as organizações se tornam cada vez mais autodiagnosticas e auto aperfeiçoadas, 
hábeis em detectar problemas e resolvê-las”. 
Muitos desses atributos também foram descritos pelo autor Peter Senge como atributos 
das organizações que promovem aprendizado continuado. No excelente livro chamado 
A Quinta Disciplina, ele escreveu que essas características ajudam os clientes, garantem 
a qualidade, criam vantagem competitiva e uma força de trabalho comprometida e 
motivada. 
Resumo dos Três Princípios 
Os métodos ágeis e o DevOps não são processos fechados ou um conjunto de 
ferramentas. Ao invés, eles são uma cultura baseada nos sistemas Lean e que busca 
reduzir o tempo da entrega de valor em produção, aumentar o feedback entre o 
time e fornecer um ambiente seguro para experimentações e inovações de negócio. 
Ao realizar o seu próximo planejamento de sprint, ao pensar em automações de testes, 
ao criar pipelines DevOps ou contêineres Docker, pare e pense: 
 Como estou ajudando o meu time a entregar software mais rapidamente em 
ambiente de produção? 
 Como estou melhorando os feedbacks entre os membros do time e também o 
time e os nossos clientes? 
 Como o nosso ambiente está ficando mais seguro para habilitar que as pessoas 
aprendam e melhorem continuamente? 
Se você identificou as relações, muito bom! Ajude o seu time a internalizar os 
princípios ágeis e DevOps e prospere continuamente no aumento da maturidade do 
Scrum, XP, Kanban e DevOps na sua empresa. 
 
 
 
O trem ágil chegou! Em qual estação você 
vai embarcar? 
Gosto muito do conceito da difusão de inovações de Rogers, que mostra como 
inovações são adotadas ao longo do tempo por uma audiência potencial. A figura, 
reproduzida abaixo a partir do trabalho original de Everett Rogers de 1962, traz a 
hipótese que existem cinco perfis no ciclo de adoção de uma nova tecnologia, processo 
ou produto. 
 
Fonte: blog.cicloagenciadigital.com.br 
Os dois primeiros públicos, ou mercado inicial, são os perfis desbravadores que 
experimentam um novo processo, produto ou tecnologia. Se os seus relatos e resultados 
obtidos forem bons, a inovação vence o abismo e avança para a maioria inicial e com 
nova confirmação de sucesso ela avança posteriormente para a maioria tardia. 
Por curiosidade, comparei a tendência de pesquisa de termos comuns na esfera gerencial 
como PMBOK, Scrum e Lean. Os resultados estão abaixo mostraram ao longo dos 
últimos anos uma inversão da procura ao longo dos últimos anos. Os números mostram 
um que o Scrum ou o Lean trazem mais curiosidade que o PMBOK no Brasil. 
 
Fonte: Google Trends 
Baseado também no que tenho observado na minha rede de gestores, arrisco dizer que o 
método ágil já venceu o abismo da incredulidade no Brasil no público gerencial. A 
aceitação dos métodos ágeis está cada vez maior e mesmo aqueles que ainda não estão 
usando estão querendo se informar. 
Ao mesmo tempo, não devemos confundir métodos ágeis com Scrum. Existem muitos 
tipos de métodos ágeis e cada empresa pode se beneficiar de um tipo distinto de método 
para a sua realidade. Não é porque o método ágil venceu o abismo que ele vai ser aceito 
pela maioria tardia, que é um público muito mais cético. 
Para lançar alguma luz nos diversos métodos ágeis, compilei um mapa ferroviário com 
as linhas onde correm alguns três ágeis populares no mercado. 
O mapa está abaixo e disponível aqui em alta resolução, que você pode baixar e abrir 
em uma janela própria do seu computador. Eles contém mais de 70 conceitos usados 
dentro do mundo ágil em escolas diversas de pensamento. 
 
Cada linha é representada por uma cor distinta e contém conceitos, papéis ou termos 
fundamentais para o entendimento daquele trilho. O objetivo é lhe dar um mapa para 
você navegar no mundo ágil, reconhecer e correlacionar conceitos comuns falados nos 
corredores e times ágeis de todo o Brasil. 
Destaco aqui pontos importantes do mapa: 
 Linha Vermelha – Representa o trem do Scrum, o método mais popular do 
mercado ágil no Brasil, Aqui você vai encontrar termos como Backlog do 
Sprint, Planejamento de Sprint, Revisão ou Retrospectiva 
 Linha Amarela – Representa o trem do dono do produto e do desenvolvimento 
de produtos. Contem termos importantes como Backlog do Produto, VPD, 
Design Sprint e Design Thinking. 
 Linha Laranja – Representa a metodologia Kanban, que vai além do quadro 
Kanban. A linha laranja evolui para a linha do Lean, a linha Roxa. 
 Linha Roxa – Representa a linha dos métodos lean e traz conceitos 
fundamentais como a redução de lotes, redução do tempo de ciclo, teoria de fila 
e controle empírico de processo. 
 Linha Azul – Representa a linha dos times ágeis e traz ideias poderosas como 
Squads e o Management 3.0. 
 Linha Preta – Aqui temos a agilidade para dezenas ou centenas de pessoas, 
chamada de agilidade em escala. Escolhi representar aqui os principais conceitos 
de um dos métodos mais poderosos para a agilidade em escala no mercado, que 
é o SAFE. 
 Linhas Verde Escura, Verde Clara e Azul. Se você é de TI, vai gostar dessas 
linhas. Elas trazem os conceitos de DevOps, Automação de Testes e 
Arquiteturas Ágeis. 
O mapa é uma abstração apenas e deve ser enriquecido ao longo do tempo com novos 
termos, conceitos e relações. Se você já trabalha com métodos ágeis, sugestões são 
muito bem vindas. 
E como me aprofundo em cada trilha? 
Se você quer navegar com mais profundidade por uma dessas trilha, tomo a liberdade de 
lhe recomendar alguns livros essenciais para iniciar ou reforçar o seu aprendizado em 
um dos trens do mundo ágil. 
Linha Vermelha – Scrum 
 
Linha Amarela – PO – Dono do Produto 
 
Linha Laranja – Kanban 
 
Linha Roxa – Lean 
 
Linha Azul 
 
Linha Preta 
 
Linhas Verde e Azul – Para você que é de TI e estava se sentido esquecido 
 
 
A fábula dos porcos assados (e os sistemas 
de informação) 
Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram 
passados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e 
acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco 
assado, incendiavam um bosque. O tempo passou, e o sistema de assar porcos 
continuou basicamente o mesmo. 
Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados 
demais ou parcialmente crus. As causas do fracasso do sistema, segundo os 
especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante 
natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, 
ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o 
lugar, o momento e a quantidade das chuvas. 
As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar 
porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário 
diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os 
anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor 
de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de 
Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas 
Alimentícias e o Bureau Orientador de Reforma Igneooperativas. 
Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam 
incendiados. Havia especialistas estrangeiros estudando a importação das melhores 
árvores e sementes, fogomais potente etc. Havia grandes instalações para manter os 
porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento 
oportuno. 
Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era 
fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e 
cortando adequadamente o animal, colocando-o então sobre uma armação metálica 
sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne. 
Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento 
mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está 
correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. 
O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a 
sua teoria? E com os acendedores de diversas especialidades? E os especialistas em 
sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com 
suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano 
têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua 
solução resolver tudo? Hein?.” 
“Não sei”, disse João, encabulado. 
“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que 
necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já 
teriam encontrado a solução há muito tempo?.” 
“O senhor, com certeza, compreende que eu não posso simplesmente convocar os 
anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que 
o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores 
não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos 
engenheiros em porcopirotecnia? Vamos, diga-me!”. 
“Não sei, senhor.” 
“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí 
que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, 
entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer 
problemas para o senhor no seu cargo.” 
João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, 
meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de 
fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões 
de Reforma e Melhoramentos, que falta o Bom-Senso.” 
Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito 
mais frequência do que imaginaria na área de Tecnologia de Informação. 
Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras 
operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, 
barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa 
fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta 
distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi 
entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas 
fábricas que participaram deste processo. 
Também tive a oportunidade de ver um time de produto que herdou uma arquitetura 
Web absurdamente complexa de um “arquiteto super inteligente” de uma fábrica de 
software. O efeito desta arquitetura é o que time demora 3 semanas para implementar 
um cadastro de complexidade média. 
Estas histórias reais me lembram do conceito de complexidade acidental e 
complexidade essencial, popularizado na TI por Neal Ford. 
A complexidade essencial representa a dificuldade inerente a qualquer problema. Na 
nossa fábula acima, acender fogo era necessário para assar os porcos. A complexidade 
decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é 
diferente. Consiste em todas as formas imposta externamente de que o software se torne 
complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade 
acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não 
podem ser pronunciados são exemplos de complexidade acidental na TI. 
Tomo a liberdade aqui de expandir a definição original do autor, pensada para 
arquiteturas de software, para arranjos essenciais e arranjos acidentais. 
Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de 
projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e 
times de desenvolvedores que trabalham em salas separadas e com processos cascatas 
são exemplos de arranjos acidentais. E os “gerentes de projetos” que ficam atrás das 
suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando 
aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos 
acidentais. 
Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a 
aplicação de práticas do Lean Software Development, um corpo de práticas muito 
legais para você descomplicar a sua TI e a forma como entrega e mantém software. 
“Simplicity is a great virtue but it requires hard work to achieve it and education to 
appreciate it. And to make matters worse: complexity sells better.” 
― Edsger W. Dijkstra 
 
Maturidade DevOps – Gestão de Releases, 
Implantação e Entrega Contínua 
Este é o nosso quarto post da série sobre maturidade em práticas DevOps. E aqui vamos 
discutir como podemos melhorar a maturidade no processo de gestão de releases, 
implantação contínua e entrega contínua. 
Quando estamos discutindo Releases, estamos falando em como mover com velocidade 
e segurança um build nos diversos ambientes da sua empresa (exemplo – testes, 
homologação e produção). 
Os princípios orientadores da gestão de releases 
1. Construa qualidade contínua 
2. Trabalhe em pequenos lotes 
3. Os computadores executam tarefas repetitivas, as pessoas resolvem problemas 
4. Procure melhoria contínua, obsessivamente 
5. Todos devem ser responsáveis 
Construa qualidade contínua 
Edwards Deming, figura-chave na história do movimento Lean e influenciador do 
movimento DevOps, ofereceu 14 princípios fundamentais para a gestão. O terceiro 
princípio diz – “Eliminar a dependência da inspeção para alcançar a qualidade. 
Elimine a necessidade de inspeção em massa, construindo qualidade no produto em 
primeiro lugar “. 
É muito mais barato solucionar problemas e defeitos se os encontrarmos imediatamente 
– idealmente antes de serem verificados no controle de versão, executando testes 
automatizados localmente. Encontrar defeitos através da inspeção (como o teste 
manual) é demorado e caro. 
Criar e evoluir loops de feedback para detectar problemas o mais cedo possível é 
essencial na entrega contínua. Se encontrarmos um problema em nossos testes 
exploratórios, não devemos apenas corrigi-lo, mas depois perguntar: como 
poderíamos ter captado o problema com um teste automatizado de aceitação? Quando 
um teste de aceitação falha, devemos perguntar: Poderíamos ter escrito um teste de 
unidade para capturar esse problema? 
Trabalhe em pequenos lotes 
Em abordagens tradicionais para o desenvolvimento de software as transferências de 
desenvolvimento para teste ou teste para produção de TI consistem em lançamentos 
completos: semanas ou meses de trabalho por equipes e fábricas com muitas pessoas. E 
a razão pela qual muitos times trabalham em grandes lotes é devido ao grande custo fixo 
de entregar as mudanças. 
Na entrega contínua tomamos a abordagem oposta e buscamos obter todas as mudanças 
no controle de versão até o final da liberação, obtendo feedback o mais rápido 
possível. Um dos principais objetivos da entrega contínua é mudar a economia do 
processo de entrega de softwarepara tornar economicamente viável trabalhar em 
pequenos lotes para que possamos obter os muitos benefícios dessa abordagem. 
Trabalhar em pequenos lotes tem muitos benefícios. Isso reduz o tempo necessário para 
obter feedback sobre o nosso trabalho, facilita a triagem e a reação a problemas e 
aumenta a eficiência e a motivação. 
Computadores executam tarefas repetitivas, as pessoas resolvem problemas 
Uma das primeiras idéias filosóficas da tradição de Toyota é o jidoka, às vezes 
traduzido como “automação com um toque humano”. O objetivo é que os computadores 
executem tarefas simples e repetitivas, como testes de regressão para que os humanos 
possam se concentrar na resolução de problemas . Assim, computadores e pessoas se 
complementam. 
Muitas pessoas se preocupam que a automação os afastará de um emprego. Este não é o 
objetivo. Nunca haverá escassez de trabalho em uma empresa de sucesso. Em vez disso, 
as pessoas são liberadas do trabalho de trabalho despreocupado para se concentrar em 
atividades de maior valor. Isso também tem o benefício de melhorar a qualidade, uma 
vez que os seres humanos estão mais propensos a erros ao executar tarefas insensatas. 
Procure melhoria contínua, obsessivamente 
A melhoria contínua, ou kaizen em japonês, é outra idéia-chave do movimento Lean. 
Taiichi Ohno, uma figura-chave da história da empresa Toyota, disse uma vez, 
“As oportunidades de Kaizen são infinitas. Não pense que você tenha feito as coisas 
melhores do que antes e esteja à vontade … Isso seria como o aluno que se torna 
orgulhoso porque superou seu mestre duas vezes em três na esgrima. Uma vez que você 
escolhe as idéias kaizen, é importante ter a atitude correta em nosso trabalho diário 
porque depois de uma ideia Kaizen existe uma outra ideia Kaizen a ser descoberta.” 
Não trate a transformação como um projeto que será iniciado e depois concluído para 
que possamos retornar ao negócio como de costume. As melhores organizações são 
aquelas em que todos tratam o trabalho de melhoria como parte essencial do seu 
trabalho diário e onde ninguém está satisfeito com o status quo. 
Todos devem ser responsáveis 
Em organizações de alto desempenho, nada é “problema de outra pessoa”. Os 
desenvolvedores são responsáveis pela qualidade e estabilidade do software que eles 
criam. As equipes de operações são responsáveis por ajudar os desenvolvedores a 
desenvolver qualidade. Todos trabalham juntos para atingir os objetivos de nível 
organizacional, em vez de otimizar o que é melhor para sua equipe ou departamento. 
Quando as pessoas fazem otimizações locais que reduzem o desempenho geral da 
organização, muitas vezes são devido a problemas sistêmicos como sistemas de 
gerenciamento pobres, ciclos orçamentários anuais ou incentivos que recompensam os 
comportamentos errados. Um exemplo clássico é recompensar os desenvolvedores por 
aumentar sua velocidade ou escrever mais código ou recompensar testadores com base 
no número de erros que eles encontram. 
A maioria das pessoas quer fazer o que é certo, mas eles vão adaptar seu 
comportamento com base em como eles são recompensados. Portanto, é muito 
importante criar loops de feedback rápido das coisas que realmente importam: como os 
clientes reagem ao que construímos e o impacto em nossa organização. 
Estabelecido esta base conceitual, vamos apresentar aqui uma escala de maturidade para 
a gestão de releases. 
1. Maturidade 1 – Inicial – Aqui não existe uma cultura de gestão de releases. A 
entrega de um release nos ambientes de testes, homologação e produção é 
sempre feita de forma manual e sem o auxílio de ferramentas. Neste nível 
observamos que os desenvolvedores precisam trocar manualmente os 
apontamentos de banco de dados e editar arquivos de configuração (exemplos – 
WebConfig em .NET ou web.xml e Java). Muitas vezes observamos rebotes e 
atritos com o time de infraestrutura e erros em produção devido a falhas 
humanas. 
2. Maturidade 2 – Consciente – Aqui a cultura de releases começa a ser 
instalada. Ferramentas como Ansible ou Microsoft PowerShell começam a ser 
utilizadas para automatizar os passos de publicação. Embora o processo ainda 
exija intervenção humana, os passos estão documentados em scripts que podem 
ser disparados sob demanda. 
3. Maturidade 3 – Gerenciado – Aqui os releases começam a ser publicados em 
intervalos regulares em ambientes controlados. Ferramentas como o Jenkins, 
GitLab, IBM Racional Team Concert, Microsoft TFS ou Microsoft VSTS 
entram em cena para pegar um build que já tenha sido produzido e mover este 
build para os ambientes de testes, homologação e produção. Neste nível 
informações sobre senhas de produção não são mais conhecidas pelo time de 
desenvolvidos. Os arquivos com estas informações são usados pelos ambientes 
de gestão de release de forma transparente. E aqui também existem smoke tests 
automatizados que verificam se o ambiente de testes, homologação ou produção 
não foram quebrados. 
4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de 
implantação de builds e também na capacidade de desfazer publicações 
automaticamente. Os builds começam a ser implantados com frequência diária 
em ambientes de testes e homologação e as publicações em produção ocorrem 
conforme os calendários acordados com áreas de negócio. E um aspecto crítico 
observado neste nível também é a capacidade de desfazermos publicações caso 
alguma instalabilidade tenha sido observada em ambiente de produção. Esta 
capacidade de desfazer publicações, obviamente, é controlada por ferramentas 
para evitar erros humanos. 
5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que 
começa a experimentar a prática da implantação contínua (continuous 
deployment) e entrega contínua (continuous delivery). A primeira prática lida 
com a capacidade de publicar automaticamente builds nos ambientes de testes e 
homologação toda vez que um novo build tiver sido gerado pelo time. E a 
segunda prática lida com a capacidade de entregar builds em produção de forma 
automatizada e com governança toda vez que um build tiver sido aprovado no 
ambiente de homologação. Aqui vemos também os times experimentando com 
testes e ambientes canários (também chamados de testes A/B). 
 Observe que esta escala de qualidade trabalha com dois fatores: o esforço humano 
necessário para a publicação de builds e a frequência de publicação. Times pouco 
maduros tem muita dificuldade para fazer publicações e normalmente dependem de 
intervenções humanas para publicar uma aplicação. Já times com maturidade alta tem o 
seu processo totalmente controlado por robôs, que não ficam cansados, e conseguem 
gerar publicações com grande frequência. 
 
Recursos de Aprendizado 
Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui 
um conjunto importante de livros que são hoje referência para desenvolvedores 
profissionais. Os primeiros é específico sobre o processo de implantaçao e entrega 
contínua e conta também um excelente sítio Web com várias práticas documentadas. 
Temos ainda dois outros livros sobre DevOps que mostram em contexto os processos de 
implantação e entrega contínua 
 
 
 
DevOps para Criar Progresso Real em Projetos 
e Produtos 
A abordagem tradicional de gerenciamento de desenvolvimento de software adia para 
os momentos finais a verificação se uma funcionalidade está realmente funcionando. 
Uma funcionalidade realmente pronta deveria atender um conjunto significativo de 
critérios tais como: 
 Operar no ambiente real (ou de homologação) do cliente; 
 Operar em uma base de dados real (ou similar) a do cliente; 
 Operar de forma integrada com os sistemas legados