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.