A diferença entre DevOps e “todo o resto”
“Na minha função, chego a frequentar várias conferências, reuniões com clientes, palestras e muitas discussões onde o tema principal é… DevOps. Posso afirmar que, embora tenha havido um declínio na quantidade de pessoas me perguntando: ‘O que é DevOps?’, há uma questão que ainda perdura. Para muitos, a conversa passou a ser os desafios que as pessoas encontraram em suas adaptações DevOps”, conta Curtis Yanko, desenvolvedor da Sonatype.
Para ele, essa mesma questão é frustrante, então busca abordá-la sob uma nova perspectiva: ao invés de tentar “definir” DevOps, ele descreve o que vem a caracterizá-lo como tal. Ou, ainda mais recentemente, Yanko conta que tentou comparar e contrastar o DevOps com todas as outras “balas de prata” da tecnologia que vieram antes disso.
DevOps é mais rápido, mais barato e melhor
Em algum momento da carreira, conta Yanko, ele chegou à conclusão de que tinha custado a justificar tudo na TI com a partir da violação do axioma clássico no qual só se pode escolher dois caminhos. A consequência, segundo ele, é que pedimos continuamente uma nova ferramenta e depois explicamos como ela irá acelerar as coisas e, assim, economizar tempo e dinheiro. Então, descobriríamos como esse novo brinquedo melhoraria a qualidade, adicionando algumas novas capacidades ou tornando-se um processo mais confiável em comparação com o processo atual. Esses argumentos geralmente eram simples e fáceis de emplacar no espaço de entrega de aplicativos, multiplicando essa economia no número de de Devs ou QAs, o que nos permitiria produzir números de grande “benefício” para justificar os custos.
É apenas matemática simples, certo? Ironicamente, tudo isso choca-se com o paradoxo da produtividade – não deixe de ver: Nicole Forsgren, Professora Assistente da Utah State University, no DevOps Enterprise Summit 2014. Em suma, não é possível obter vantagens competitivas desses investimentos porque, basicamente, seu concorrente pode fazer os mesmos investimentos. Portanto, quaisquer ganhos não serão sustentáveis, e em vez disso, você estará apenas “se mantendo“. O que Yanko acrescenta é que muitos desses investimentos foram feitos isoladamente, impactando frequentemente um determinado conjunto de pessoas.
Pessoas, Processos e Ferramentas
Um exemplo simples dessa limitação é o seguinte: investimos em uma ferramenta para melhorar ou adicionar uma habilidade a uma pessoa que, por sua vez, melhora um processo. Grandes esforços são investidos no processo, como agile, e depois são adotadas ferramentas e pessoas são treinadas para as habilidades de que precisam para abranger um conjunto mais amplo de pessoas. O tema recorrente aqui é que as pessoas são todas suas “habilidades“. Elas entendem todas as ferramentas e processos necessários para que possam oferecer valor? Muitos desses investimentos de TI suscitaram preocupações de que as pessoas atualmente não possuíam as habilidades necessárias, então agora precisamos de treinamento ou precisamos contratar de fora.
Depois de um tempo, você começa a ver as pessoas sob a ótica taylorista – em referência ao engenheiro norte-americano Frederick Winslow Taylor, para quem é possível alcançar o máximo de produção e rendimento com o mínimo de tempo e de esforço. Ou seja, elas passam a representar uma coleção de habilidades que lhes permitem fazer seu trabalho em uma pequena seção da cadeia de valor, intencionalmente isolada do restante da cadeia.
DevOps é cultura e cultura são as pessoas
Se você ainda não leu “Lean Enterprise”, o autor recomenda, mesmo que seja apenas o primeiro capítulo, porque este capítulo fala sobre uma joint venture entre a GM e a Toyota. A GM queria aprender TPS e Toyota precisava de um ponto de apoio nos EUA devido ao aumento das tarifas sobre as importações. A GM escolheu sua planta fechada de Fremont, que por sua vez havia sido sua planta com pior desempenho em termos de qualidade e número de carros produzidos, além de relações superficiais entre gerente e trabalhador.
Incrivelmente, a Toyota concordou com um requisito de recontratar os líderes sindicais da Fremont para liderar os trabalhadores na força de trabalho da nova fábrica. Todos os líderes sindicais foram enviados para a Toyota City no Japão para aprender TPS. Em apenas alguns meses, esta nova fábrica produzia carros quase perfeitos a um custo mais baixo e em volumes maiores do que a planta de Fremont já teve. Isso pareceu provar que foi o sistema – e não as pessoas – que contribuiu para o mau desempenho da fábrica de Fremont. Há também histórias emocionantes dos trabalhadores sobre como ter um emprego em que eles se orgulharam de terem suas vidas pessoais afetadas de maneira positiva também.
“Enquanto o taylorismo vê as pessoas como engrenagens em uma máquina paga simplesmente para executar sua tarefa pré-planejada rapidamente, o DevOps coloca as pessoas em uma cultura de alta confiança focada na melhoria contínua (Kaizen) e fornece um ambiente para explorar e aprender. Isso dá orgulho às pessoas em seu trabalho, em vez de dizer o que fazer e depois usar “brindes” ou “prêmios” para motivação. No DevOps, as pessoas podem descobrir um plano para si mesmas, tornando-as envolvidas nesse processo e, por sua vez, naturalmente motivadas.”
O DevOps é holístico
Ao contrário dos investimentos isolados do passado, os investimentos do DevOps são holísticos. O DevOps não se concentra apenas em uma pessoa ou em uma pequena parte do fluxo de valor, em vez disso, toma o fluxo de valor de ponta a ponta e todas as pessoas envolvidas. Em vez de adequar nossas pessoas às ferramentas e processos, estamos criando um ambiente propício para que as pessoas se adequem da forma como desejarem. E talvez seja por isso que os relatórios DevOps agora mostram uma conexão entre os investimentos e a TI, porque no que realmente estamos investindo é nas pessoas e estamos capacitando-as para melhorar o processo e encontrar as ferramentas certas.
Fonte: DZone.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.