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?

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 acidentes ocorrem, 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 maneira ideal 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.

“Are you too busy for improvement? Frequently, I am rebuffed by people who say they are too busy and have no time for such activities. I make it a point to respond by telling people, look, you’ll stop being busy either when you die or when the company goes bankrupt.”
— Shigeo Shingo, Pai do Sistema Toyota de Produção