O que Yin-yang tem a ver com DevOps e você deveria saber à respeito

Na filosofia chinesa, o Yin-yang representa a dinâmica entre forças opostas complementares e interconectadas. O yin representa a força negativa, escura, e o yang representa a positiva, clara. Uma força não pode existir sem a outra, elas são inseparáveis.

O pequeno ponto dentro de cada metade do símbolo do Yin-yang representa a natureza relativa de cada força, o potencial de uma se transformar na outra. Ambas estão em constante oscilação, numa luta sem fim pelo equilíbrio. Elas formam um sistema em que o todo é maior que as partes reunidas.

O yin e o yang regem juntos tudo. O caos e a ordem, a noite e o dia, você pode encontrar ambos em todos os lugares. Eles representam o ritmo de tudo que experimentamos, num fluxo contínuo e harmônico. Tal movimento eterno reflete a essência do universo.

Ok, o que Yin-yang tem a ver com DevOps então?

Bem, assim como o Yin-yang, o DevOps também apresenta conflitos entre forças distintas, times especializados, através de todo o processo de desenvolvimento e entrega de software. À primeira vista, você poderia adivinhar quem seriam os vilões e os mocinhos da estória, e rotulá-los como yin ou yang. De todo modo, por mais incrível que pareça, a verdade é que todos são importantes, e se complementam.

Na teoria, regulação, conformidade, auditoria, segurança, estabilidade, estariam do lado yin, e inovação, evolução, mudança, autonomia, agilidade, estariam do lado yang. É muito comum que quem cuide de um aspecto ou outro tenda a reclamar do que os pares do outro lado fazem, mas a verdade é que todos tem a sua importância no todo.

O DevOps traz essa visão holística, e encoraja as empresas a fazerem mudanças globais nas usas correntes de valor, ao invés de mudanças localizadas, para ter aumento de performance. O segredo é colocar o peso correto em cada força, de uma forma tal que se tenha ganho de velocidade ao mesmo tempo que os riscos sejam devidamente controlados. Como no Yin-yang, as forças no DevOps são inseparáveis.

Imagine de outra maneira estabilidade sem mudança, por exemplo. Nesse cenário, não haveria espaço para crescimento, tudo ficaria paralisado. Por outro lado, mudança sem estabilidade seria arriscado demais. Cabe totalmente à empresa a busca contínua pelo equilíbrio correto entre as forças, para se ter o melhor da soma delas, ou não.

Adotar DevOps é não é uma tarefa simples, pois as empresas são forçadas a olhar para dentro e a lidar com o que elas tem de pior, e melhor. Elas podem escolher ou não dar o próximo passo, e minimizar o que as atrapalha a conseguir maiores níveis de performance. São elas que ditam o seu próprio ritmo, no final das contas. O mesmo ritmo que tanto o Yin-yang quanto o DevOps representam.

Conclusão

Se sua empresa está adotando DevOps, a transformação cultural também é sua responsabilidade. Tenha a cabeça aberta e se coloque no lugar dos outros. Tenha consciência do impacto que você provoca, e tenha atitudes colaborativas. Lembre-se que nada é totalmente ruim (yin), nem totalmente bom (yang), então esteja à disposição para aprender, e mudar. Nós estamos todos no mesmo barco.

Este texto foi traduzido de https://www.linkedin.com/pulse/what-yin-yang-has-do-devops-you-should-know-gustavo-muniz-do-carmo pelo próprio autor.

Como fazer todos definitivamente entenderem o que DevOps realmente é

Mesmo depois de anos da existência do conceito, por que ele ainda é tão incompreendido? Eu acredito já ter ouvido todas as explicações, mas pra mim existe uma explicação simples, a única delas, que captura a essência do significado:

O objetivo do DevOps é minimizar o time-to-market para entregar o quanto antes valor ao cliente.

Um chamado de alerta

Imagine então o quanto de esforço que uma empresa precisa ter para atingir este objetivo? Ok, este esforço está relacionado à utilização das ferramentas e das práticas corretas, mas além disso, e mais importante, está relacionado à construção da cultura correta. E isso não é responsabilidade da TI sozinha, o principal pré-requisito da adoção do DevOps é ter toda a empresa comprometida em alcançar o objetivo!

A menos que os executivos C-Level entendam isso, e promovam a transformação na empresa como um todo, ela só terá DevOps parcialmente. Pior, o objetivo pode não ser conquistado, caso todo o esforço esteja concentrado somente no departamento de TI. DevOps deve começar na TI? Certamente, e na verdade é o que geralmente ocorre. De todo modo, sem escalar a adoção para a empresa, não existe a garantia de se obter todos os benefícios.

Os três princípios do DevOps

Depois de fazer este tipo de chamado de alerta para posicionar DevOps como uma questão corporativa, deixe-me aprofundar um pouco no conceito. Bem, DevOps, influenciado pela filosofia Toyota Way e pelo movimento Lean, é suportado por três princípios, os três caminhos: otimização de fluxo (primeiro caminho), ciclos rápidos de feedback (segundo caminho) e aprendizado contínuo (terceiro caminho). A figura abaixo mostra os três caminhos:

O primeiro caminho, otimização de fluxo

O primeiro caminho, otimização de fluxo, objetiva eliminar desperdícios, gargalos no processo, transferências entre times funcionais especializados, tempos de espera. A automatização é chave, usada extensivamente na implementação de práticas tais como integração contínua, entrega contínua e implantação contínua. As necessidades dos clientes são atendidas o mais cedo possível, após identificadas pelo negócio.

Observe que o primeiro caminho é sobre o processo como um todo, desde a identificação da necessidade do cliente (esquerda) até o ponto em que ela é atendida (direita). Em outras palavras, desde o momento que a demanda nasce até a implantação da nova funcionalidade no ambiente de produção. Na verdade, a demanda percorre times diferentes de departamentos diversos, incluindo, de forma não exclusiva, a TI.

O segundo caminho, ciclos rápidos de feedback

O segundo caminho, ciclos rápidos de feedback, objetiva resolver problemas o quanto antes, medindo o processo inteiro, testando tudo, alertando assim que uma falha é detectada. A monitoração é chave, permitindo rápidos feedbacks à respeito da qualidade do software, assim como da sua entrega e, acima de tudo, do valor que ele traz para os clientes. O segundo caminho segue a ideia do andon cord da Toyota.

Observe que a qualidade é responsabilidade de todos através do processo, não apenas papel de um time de QA. A qualidade é medida desde o início e, depois de tudo, precisa representar valor para os clientes. Feedbacks ficam constantemente gerando informações relevantes para o sistema, incluindo aquelas que avaliam novas funcionalidades. Isto quer dizer que funcionalidades podem ser removidas do software, se não traduzirem valor real aos clientes. Com feedbacks rápidos, o negócio consegue falhar rápido, e logo retomar o rumo, caso necessário.

O terceiro caminho, aprendizado contínuo

O terceiro caminho, aprendizado contínuo, objetiva gerar conhecimento, através da experimentação. Ao invés de considerar que tudo está certo, hipóteses são formuladas, para serem comprovadas. O sistema inteiro é sujeito a melhoria, a adaptações. O terceiro caminho segue a ideia do processo científico.

Observe que o terceiro caminho requer uma boa dose de humildade, flexibilidade e coragem. Humildade porque a empresa precisa reconhecer que nem sempre está certa, flexibilidade porque a empresa precisa poder mudar, e coragem porque a empresa precisa assumir riscos. E isso tem tudo a ver com livrar-se da cultura da culpa e alavancar a colaboração e o compartilhamento de conhecimento.

Conclusão

Se alguém perguntar pra você o significado de DevOps, ou pedir pra você fazer uma apresentação à respeito, por favor conte a história completa. Não cometa o erro de deixar de lado a parte mais difícil, a que DevOps requer uma transformação cultural. Sim, eu sei, todos querem aprender as ferramentas e as práticas para ganhar agilidade, mas você deve mostrá-los que antes é preciso uma mudança de pensamento. Não há saída.

Este texto foi traduzido de https://www.linkedin.com/pulse/how-definitely-make-everyone-understands-what-devops-muniz-do-carmo pelo próprio autor.