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.

Colaboração

Resolvi fazer uma pausa na série de posts sobre ferramentas de testes para falar um pouco sobre colaboração. Esse assunto aparece cada vez mais nas empresas, mas ao mesmo tempo que vem como a solução de muitos problemas, não me parece ser bem compreendido, e por vezes parece assustar, e cria resistências.

Isso porque colaboração exige uma mudança de mentalidade, de comportamento, e a grande maioria das empresas brasileiras é muito hierarquizada, e dividida em silos. E isto faz com que geralmente as pessoas busquem se defender, mais do que se ajudarem. Pior ainda quando a ajuda é interpretada como ameaça.

Quando se colabora, de verdade, os muros deixam de existir. São construídas pontes. Todos entendem que estão no mesmo barco e, no fim, o que importa mesmo é o cliente, e só. Os problemas passam a ser de todos, qualquer um pode se envolver na solução. Ninguém espera demanda, todos trabalham para entregar valor.

Não é à toa que muitas empresas tem buscado criar uma cultura colaborativa. Normalmente, a colaboração é a saída para sobreviver, em mercados cada vez mais competitivos. Quando o negócio corre risco, a colaboração vem para agilizar processos, inovar, e até criar negócios novos, se reinventar, com o foco exclusivo no cliente.

Numa cultura colaborativa, os erros são encarados com normalidade, o aprendizado é estimulado, o conhecimento é compartilhado, a experiência é dividida. As pessoas podem ter suas especialidades, mas acabam evoluindo em outras disciplinas como consequência da integração com outras áreas. O potencial das pessoas é valorizado, e desenvolvido.

Não adianta ter a colaboração como valor da empresa, estampada em apresentações corporativas, se ela não é adotada na prática, não é vivida. Ela requer o compromisso individual, engajamento, e até proteção. A mudança de hábito não se obtém de um dia para o outro, é um processo, com alto e baixos, mas que precisa de disciplina, pra virar realidade.

O benefício claro da colaboração, além dos resultados nos negócios, é a motivação das pessoas, é a satisfação de fazer parte de um time que agrega valor ao cliente, é o propósito. Cada pessoa sabe a importância do seu trabalho, sabe que sua participação é fundamental para o resultado final. A colaboração empodera as pessoas, as torna mais felizes.

Estamos vivendo uma época em que a colaboração cresce exponencialmente na sociedade. Informação disseminada, redes sociais, economia compartilhada, o indivíduo saiu do anonimato para marcar presença no mundo, para mudar o mundo. As empresas precisam se ajustar à esse novo momento, ou ficarão pra trás.

A figura abaixo foi tirada do post do blog do Tanmay Vora que comenta um excelente post do Aaron Sachs e do Anupam Kundu, da ThoughtWorks, falando justamente da mudança de mentalidade necessária para a transformação das empresas, frente aos desafios atuais. Quanto à colaboração, eu destacaria “from hierarchies to networks” e “from controlling to empowering”.

organization-transformation