Diulia Almada: Bom dia, boa tarde e boa noite. Acho que claramente ninguém vai acreditar que é Szuster. Então para já me apresentar, eu sou a Diulia, head de design aqui na DTI. A gente vai fazer alguns episódios com um teor um pouco mais prático e para conseguir também dar um descanso para o Szuster e para o Vinição, para eles poderem renovar toda aquela lista de leitura que eles ficam falando a cada episódio. E aí eu não estou sozinha também.
Pedro Rangel: Olá, pessoal. Eu sou o Pedro Rangel. Já estive aqui antes também como convidado, então é um prazer enorme está cobrindo aí o descanso do Szuster e do Vinição. Estou na DTI há quatro anos, sou account management e espero que vocês se divertem. E a gente está aqui também com o Felipão. Fala aí, Felipão.
Felipe Silveira: Fala, pessoal. Prazer estar aqui de novo estreando aí episódio com novos hosts, é uma responsabilidade legal aí falar nesse podcast, que temos aí os dois monstros da DTI como hosts, mas estão sendo muito bem representados aqui nessa nova fase de Os Agilistas. Prazer estar com vocês aí.
Pedro Rangel: Estou me achando agora. E o Hammer também. Fala aí, Hammer.
Hammer Lage: Prazer, pessoal, estar aqui de novo. Já não lembro se é o terceiro ou quarto episódio que eu participo aqui. Também é um prazer estar com vocês, novos hosts aí também. E também atuo como acountt aqui na DTI igual ao Pedro, e estou aí para contribuir novamente.
Diulia Almada: Bom demais. E vocês devem ter percebido que o nome do episódio não é exatamente novo, assim, a gente resolveu começar o ano de 2023 com o The F*cking first Step remasterizado assim, um dos episódios que são mais famosos aqui de os Agilistas, mas a gente sabe que o contexto mudou, a gente sabe que a gente está num mundo complexo, então não tem como as coisas se manterem estáticas. E a ideia é a gente conversar um pouquinho, tanto trazendo um pouco mais para a prática desse primeiro passo que a gente precisa dar, como também adaptando para esse novo cenário que a gente tem agora em 2023.
Pedro Rangel: Isso aí. Como diz o Vinição, eu vou invocar um pouco do primeiro episódio aqui só para a gente lembrar, para que não ouviu ou quem não lembra. A gente vai abordar um pouco do first step na prática. E o que é the f*cking first step ou a porra do primeiro do passo? É um convite para a ação, invocando lá o episódio, como um apelo para as organizações que não conseguem agir e que ficam imobilizadas. Então conclamar a ação e o aprendizado a partir da ação, começando a ser agilista de fato. E no último episódio do ano passado o Szuster e o Vinição eles falaram muito desse momento que a gente está agora no mercado, tecnologia, economia, o mundo em geral, e a gente precisar acertar que a gente vai lidar com um cenário de mais incertezas, não é? Então as organizações estão enfrentando desafios históricos, cenário competitivo, força de trabalho mais exausta, pressão para ter mais controle por cursos e tudo mais, isso quer dizer que a barra vai aumentar, não é? E o pior que se pode fazer é ficar parado vendo tudo isso acontecer ao redor. Então dar o f*cking first step agora se torna ainda mais importante do que nunca, e aí não esquecer que a gente está procurando o tempo todo refletir se a gente está avançando independente desse canário, se é de prosperidade ou de austeridade. E aí antes de a gente entrar mais nos casos práticos e falar de exemplos, discutir f*cking first step na prática, acho que a gente podia comentar primeiro um pouquinho. O episódio foi gravado lá em 2019, então o que é que a gente pode perceber que mudou no cenário de tecnologia de 2019 para cá em comparação com o que a gente tem hoje, como é que a gente sente essas mudanças. E aí quem gostaria de comentar aí?
Felipe Silveira: Posso comentar um pouquinho aqui. 2019, o tempo passa rápido demais. Eu lembro quando você traduziu o f*cking first step e deu uma risadinha, eu lembro o Szuster fazendo exatamente a mesma coisa.
Pedro Rangel: A mesma risada.
Felipe Silveira: Quando gravou pela primeira vez o episódio.
Pedro Rangel: Na dúvida, a gente pode falar isso em podcast ou não?
Felipe Silveira: Acho que pode, só por um (inint) [00:04:03] lá e está tudo certo.
Pedro Rangel: Está tudo bem.
Felipe Silveira: Maiores de 18. Mas, enfim, assim, realmente o tempo passou muito rápido, 19 para cá. Assim, eu diria que o que é que mudo no cenário de tecnologia? Tem o óbvio, que a tecnologia não para, o aparato tecnologia evoluiu, as ferramentas que a gente tem para se utilizar evoluíram. Lembro agora, no final de semana agora eu estava tendo uma conversa com o Vinição ali pelo WhatsApp mesmo e ele falando muito daquele chat de EPT, que é uma coisa aí que está aparecendo muito forte aí, a IA por trás do conhecimento. Então isso pode inclusive mudar bastante o paradigma até da tecnologia e do desenvolvimento de software daqui para frente. Então esse é o aspecto óbvio que, obviamente, ele continua evoluindo ali sempre. O segundo mais óbvio: é que de 2019 para cá a gente teve uma f*cking pandemia, e isso mudou…
Diulia Almada: Não, nem notei.
Felipe Silveira: Ninguém percebeu. E eu acho que isso mudou uma coisa que é significativa no ambiente que a gente vivia, o ágil, que é de muita colaboração, e a gente perdeu um aspecto muito importante da colaboração, que é a presença física, a facilidade que a presença física traz em colaborar. Então eu acho que isso foi uma outra mudança gigante de cenário aí de 2019 para cá. A gente teve que aprender a ser ágil não tendo a presença física ao nosso favor. E a terceira coisa, eu acho que é igual, o Pedro já pincelou aí no início, a gente saiu de um cenário que ele era mais de abundância, um mercado talvez vivendo até uma determinada bolha em que estava realmente muito orçamento, muita demanda, para um cenário de agora que é mais de deflação, está sendo mais contido, de cobrar-se mais por produtividade. Então eu acho que tentando resumir, esse é o cenário que a gente está vivendo em 2023 versus o que a gente tinha em 2019, sabe?
Hammer Lage: Eu acho que também traz uma maturidade algumas coisas que aconteceram nesse meio do caminho. A questão do controle, por exemplo, que era uma coisa que o ágil ele é mais de transparência e de visibilidade, não de controle de micro gerenciamento ali de algumas coisas, a gente começa também a perceber uma maior maturidade quanto ao mecanismo de controle, não que a gente esteja sugerindo um micro gerenciamento, mas temos que aumentar um pouco o controle, que estava num cenário de abundância e aí o controle era menos necessário, não é?
Diulia Almada: Pois é. E aí até já emendando a próxima pergunta, aproveitando que você começou a comentar aí, Hammer, é uma pergunta simples. Nesse cenário que a gente tem mais pressão por resultado, uma necessidade de otimização maior, como é que a gente trabalha, conseguindo garantir eficiência, resultado, mesmo diante de um cenário com mais restrição? O que é que significa, de fato, conseguir trabalhar com mais eficiência? O que é que significa entregas? O que é que gente pode de fato levar para os nossos clientes?
Hammer Lage: Até refletindo também hoje no dia a dia, quando a gente volta lá numa coisa que foi provocada lá no episódio original, do squad de verdade, dessas coisas. Quando a gente percebe que a gente criou ali um mecanismo onde as pessoas estavam extremamente pensando em autonomia, que estava refletindo sobre ter mais protagonismo em algumas coisas, (inint) [00:07:08] up de algumas ideias, de algum controle também dentro do próprio time, isso também cria também uma falta de sensação de controle da execução primária, que eu estava sugerindo ali anteriormente. E com isso a gente precisa exagerar no quesito de transparência, do que é que o time está fazendo e de organização também do que é que está ali no fluxo de trabalho desses times também. Então gente, primeiro, começa a refletir no dia a dia dessa operação e o que é que esse turma está de fato priorizando. Então, assim, alguns princípios eles vão… tem que retomar alguns princípios ali na célula do dia a dia, sabe, e ter a marcação de que a gente esteja realmente com esses princípios ali meio que de antemão ali para começar qualquer coisa, quase que voltasse no Manifesto Ágil de novo e falar: “O que é importante para a gente?. Será que algumas coisas criadas a gente não passou por cima do manifesto? Será que a gente perdeu alguns princípios do manifesto no meio do caminho?”.
Felipe Silveira: É princípio, assim, é isso aí a palavra. Eu acho que quando está na abonança a gente vai pescando o ferramental do ágil e vai aportando nos squads. Só que, assim, não dá para ser demagogo aqui de dizer que você não aporta ineficiência também, que é o que a gente estava conversando ali antes de começar a gravação do episódio, não é, Hammer? Eu acho que é hora agora com esse cenário de a gente olhar cada contexto, porque isso a gente já falou em N episódios de Os Agilistas aqui. O contexto ele é soberano, não existe uma regra que se aplica a tudo, não existe uma receita de bolo, mas é voltar e ver se está sendo gasta as energias dos locais corretos, não é? Assim, porque as vezes a gente acha: formar um squad de verdade, igual o Hammer falou. O que é formar um squad de verdade? É eu ter uma formação de caixinha? Eu tiro do bolso ali uma caixinha, um squad de verdade é isso? Talvez no tempo de bonança, se você tiver um squad que tenha todos os papeis, tudo ok, você vai entregar com toda certeza, eu não tenho a menor dúvida disso. Agora é hora de talvez olhar se tem alguns papéis ali que não estejam sendo super dimensionados num cenário em que a gente tem que buscar agora eficiência sem perder a mentalidade, obviamente.
Diulia Almada: E aí só para poder emendar. Então de tudo que a gente está falando aqui, a gente ainda não está falando que é para poder fechar escopo de tudo e…
Felipe Silveira: Pelo amor de Deus.
Diulia Almada: Acho que é legal comentar que as vezes a gente cai na tendência assim de: “Ah, vamos ter mais controle. Precisamos de mais controle”, e a gente acaba esquecendo que a gente continua vivendo num mundo complexo e cada vez mais complexo. Então quando você fala, Hammer, de voltar para o que é o gatilho inicial, os princípios, para além da própria metodologia ágil, enfim, acho que a gente precisa inclusive conseguir responder com muita claridade porque é que aquele time existe, qual que é o valor que se pretende gerar com aquele time. Então acho que isso é uma coisa bem legal de a gente ter em mente também.
Pedro Rangel: É. Lembrando até do… invocando um outro episódio do Vinição e do Szuster falando sobre os momentos de austeridade. A natureza dos problemas não mudou, então mais do que nunca a gente precisa contar com o ágil para de fato gerar valor. E aí lembrar que produtividade não é simplesmente fazer mais rápido, é fazer melhor, fazer na ordem certa. Então quando você fala aí de fechar escopo já me deu um arrepio aqui. Eu como gerente de conta aqui luto diariamente contra esse tipo de coisa, mas a pressão por otimização ela vem aí. E, assim, não sei, talvez o Hammer consiga compartilhar um pouco desse sentimento, mas a gente já observa até as vezes uma certa vontade, um impulso de sair reduzindo alguns papeis essenciais no time, mas por um falso entendimento de que eles não são essenciais, e aí a gente acaba voltando para o modelo mais tradicionalzão, que você fica com o time quase que por engenharia e tem que fazer um detalhamento um pouco mais complexo antes de começar de fato a fazer, então não sei. Você sente isso já, Hammer, hoje?
Hammer Lage: Cara, foi até… parece que as coisas vão casando assim, mas está tendo uma discussão recente até de otimização mesmo da operação que a gente tem, e pensando justamente assim: onde que está o problema? E a gente estava enxergando que existiam alguns problemas que eram de engenharia, porque tinha uma complexidade de sincronizar algumas atividades até de times que eram dependentes entre si, e no primário da reação “Ah, vamos procurar. Que talvez se colocar esses caras no mesmo lugar esse problema se resolver”. E aí a gente começou a refletir, a gente falou assim: “Então, assim, vamos usar agora a ignorância intencional e vamos falar assim: E se a gente estiver errado?”. E aí a gente fez um contive junto com próprio cliente e as pessoas do time e a gente começou a refletir nos motivadores ali, a gente fez quase que uma…
Pedro Rangel: Desconstrução ali.
Hammer Lage: Uma desconstrução, vamos falar assim: “O que é que está aparecendo aqui nas frutas da árvore aqui, o que é que a gente está vendo de podre aqui na árvore, o que é que pode ser a raiz desses problemas. Agora vamos lá na raiz desses problemas e vamos ver o que é que poderiam ser possíveis remédios para essas causas raiz”. E, assim, a gente viu que tinha tanta complexidade antes de alguma coisa chegar na mão do time de engenharia, que gente falou: “Caramba, tem muito trabalho para fazer antes aqui”. É até assim, porque é muito fácil cair na simplificação, que é só botar na esteira para a construção o que está pronto. E até no episódio anterior que o Szuster citou o Taylorismo assim, e nessa reunião com o cliente eu comentei sobre o básico do lean assim, como que o lean surgiu, não quer dizer que a gente vai colocar três pessoas fazendo coisas, tipo assim: não, coloca todo mundo no mesmo lugar, todo mundo vai ficar fazendo as mesmas coisas que vai dar certo. A gente só está aumentando o (inint) [00:12:42] ali e colocando mais complexidade dentro de uma célula única. Então enxergar melhor essa cadeia de produtividade, que ela não é só quando começa o sprint, que as atividades estão definidas, que o escopo está extremamente detalhado e eu sei exatamente o que é que tem que construir, vamos enxergar essa cadeia de uma forma mais expandida. Então a gente chegou assim em cerca de umas 50 causas raízes, poderia estar dando um problema de sincronização, de escopo, que poderia otimizar a eficiência do time como um todo. E essa questão mesmo de, tipo assim: “Vamos tirar alguns papéis ali que talvez não estejam contribuindo tanto”, na verdade a gente viu que precisava dar mais atenção para essas pessoas até terem um pouco mais de ascenção na aproximação com o negócio, de estar mais em contato, ouvindo mesmo o que é o business do cliente, ouvindo mesmo os especialistas da produção para otimizar melhor, para a gente não começar a fazer as coisas sem ter um entendimento melhor do que é que tem que ser feito. Então, assim, eu acho que vamos esquecer as… até descontruir um pouco as certezas e vamos nos perguntar um pouco mais, sabe? E foi muito legal assim, porque o cliente foi extremamente compreensivo e parceiro, se engajou também, igual eu falo assim: “Vamos nos dar o direito da dúvida. Vamos começar a perguntar”. Então eu acho que é importante a gente perguntar também muito assim, sabe? E a gente se tiver errado? É a gente mesmo.
Felipe Silveira: Isso que você narrou aí, cara, isso eu acho interessante para caramba, porque isso mostra que o agilismo ele é recursivo, ele se aplica a ele mesmo, porque o que você acabou de descrever é que vocês aplicaram a mentalidade ágil para resolver a estrutura de um time ágil. Vocês quebraram o problema e tentaram achar onde vocês deveriam começar, qual é a primeira historinha ali que vocês deviam resolver. Então isso é fantástico.
Hammer Lage: E um negócio assim: “Eu dei o primeiro passo, mas eu não projetei muito bem. O que é que me indica que eu vou fazer a coisa certa?”. Lá quando surgiu o lean e tudo, a gente fala muito de kaizen, kaizen de melhoria contínua. Se a gente está começando, talvez não extremamente projetado, quer dizer que eu tenho um compromisso também de estar constantemente otimizando, refletindo e melhorando aquele projeto ali mesmo, que seja desde entender o que é que tem que ser feito até entregar com uma qualidade maior, esse fluxo no meio do caminho se está certo. Então esse kaizen, essa melhoria contínua é algo que tem que ser exagerado, porque pode não, com certeza podemos cometer muitos erros ao longo do caminho, mas o importante é voltar e refletir constantemente, evoluindo.
Pedro Rangel: Esse período já de crise nas big techs, alguns resultados ruins aparecendo por aí, eu já vi algumas vezes no LinkedIn assim: “Será que o discovery está morto?”, e eu ficava… não queria nem ler o texto, eu falava: “Não, pelo amor de Deus. Que mais do que nunca é importante ter clareza do que precisa ser feito”. Então, assim, por mais a gente não possa, talvez nem deva, a qualquer momento ficar fazendo discovery de três meses, mas, cara, você tem que realmente conhecer a dor, descobrir realmente o que precisa ser feito ali.
Diulia Almada: É, senão a gente acaba caindo em fazeção, não é? Você faz um monte de coisa que no final das contas não vai servir para nada, não está atendendo a ninguém, resolvendo problema nenhum. Então, assim, eu acho que a gente reforça a necessidade de conseguir fazer esses ciclos curtos, tanto buscando pela melhoria contínua, e aqui acho que a gente nem estão falando: “Vamos criar novos ritos”, é fazer uma retro bem feita, é conseguir fazer uma análise das entregas bem-feitas, conseguir fazer o processo do entendimento do problema bem feito para a gente poder, ao invés de sair em fazeção, a gente conseguir saber um pouco melhor onde que a gente está pisando, mas entendendo que também não vai ter assim certeza cravada em pedra, que a gente só vai de olho fechado que vai dar certo. A gente ainda vai precisar de muito sense responde, ainda vai precisar de muita atenção ao que está acontecendo ao redor, mas entender que, assim, a gente fazendo esse exercício constante, pelo menos o risco fica um pouco menor.
Pedro Rangel: Não é para deixar de fazer os experimentos, só para ser um pouco mais paranoico com tudo que envolve ele, a transparência e possivelmente…
Diulia Almada: E até a priorização, não é? Priorização, se é o momento para poder fazer, qual que é o nível de risco que existe, enfim.
Pedro Rangel: É isso aí. Bom, a gente falou aí muito de pressão por otimização, produtividade, eficiência, resultado, etc. E um desejo forte que pode surgir nas empresas é justamente ter uma forma de entregar mais rapidamente, não é? Então em ciclos mais curtos como a Diulia comentou, com mais frequência e ainda fazendo isso de forma segura, ou seja, minimizar tempo de implementação, por exemplo, com integração contínua. E aí o que poderia ser um first step em continuous delivery para quem quer adotar essa prática, Felipão?
Felipe Silveira: Então, acho que nessa pegada aí de a gente transformar os episódios de Os Agilistas aí trazendo mais teoria aplicada na prática, muito bem colocado aí. Se o cenário é esse que a gente está descrevendo aqui, de mais austeridade, que todos os aspectos da agilidade continuam sendo válidos, mas eles deveriam, mais do que nunca, serem aplicados, de fato esse tema de continuous delivery e o DevOps, que é o que talvez um dos conceitos que habilitam o continuous delivery. A gente até falou desse conceito em outros episódios de Os Agilistas, mas talvez de uma forma até, vamos dizer assim, superficial. E aí quando vocês me chamaram aí para gravar o episódio eu pensei assim… Já que é para falar na prática, não é? Eu não sou nenhum especialista em DevOps, eu tenho algum conhecimento, mas não sou nenhum especialista, eu falei assim: “Pô, aqui na DTI a gente tem”. Então eu corri atrás de alguns colegas nossos aqui, e aí fazer o papel aqui de representá-los no episódio, eu corri atrás de alguns colegas e fiz essa pergunta assim, eu falei: “Poxa, eu acho que mais do que nunca ter um mecanismo, um aparato que habilite a gente a reduzir tempo de entrega, se os experimentos continuam válidos ou eles… colocar esses experimentos a prova o mais rápido possível, o DevOps é uma das ferramentas. E aí eu fiz essa pergunta para dois colegas nossos aqui que conhecem muito do assunto, que é “Mas qual que é o f*cking first step quando a gente quer falar aí de um cliente que fala assim: “Ah, legal. Eu assisti o episódio de Os Agilistas lá e eles falaram que DevOps é uma saída para eu reduzir o meu tempo de entrega e ter o valor mais rápido”?”. E aí eu vou começar falando sobre a pegadinha, o trap, que é, na verdade, tentar da o second, o (inint) [00:18:56] step antes de dar o primeiro, que é: DevOps. “Não, eu ouvi falar que DevOps vem acompanhando de algumas ferramentas”. Então eu vou contratar aqui um Azure DevOps, um Jira, um Jenkins, vou criar um pipeline bonitão aqui na minha infra e daí eu vou entregar necessariamente mais rápido, porque aí eu vou apertar um botão e vou entregar, não é? Segundo o nosso colega Pablo Goulart, que é um especialista em DevOps, e o Davi Gomes, outro especialista em DevOps que a gente tem, eles falaram: “De forma nenhuma. As vezes até pelo contrário. Às vezes você até deflagra mais ainda um problema que você tem mais na raiz”. E aí o Pablo, de uma forma até bem acadêmica, compartilhou comigo alguns autores, o Gene Kim, que é bem conhecido, que é o autor do Acelerate, que a gente já fez alguns episódios falando sobre o Acelerate, ele também escreveu um livro, que é o Manual de DevOps. E aí no Manual de DevOps ele cita um outro autor, que é doutor (Goldratt) [00:19:43], que escreveu um livro que chama Além da Meta, e aí tem uma frase que eu vou fazer questão de citar aqui, que mostra qual que é o f*cking first step em continous delivery ou pelo menos deflagra esse f*cking first step. A frase é a seguinte: Em qualquer fluxo de valor há sempre uma direção de fluxo e há sempre uma única restrição. Qualquer melhoria que for feita em qualquer outro lugar que não seja essa restrição é mera ilusão. Aí pensando nisso assim, beleza, então me parece que a primeira coisa que se tem que fazer, antes de ficar inventando moda de contratar ferramenta, de criar todo um pipeline automatizado, é entender muito bem o seu fluxo de entrega, e depois de entendido muito… Tem muito a ver com o que o Hammer falou, estava escondido ali no discurso dele. Entender muito bem o seu fluxo de entrega e ficar obstinado por encontrar onde está essa restrição ou esse ponto de falha, e aí direcionar os seus esforços para automatizar ou melhorar algo que resolva esse seu ponto de falha. Qualquer coisa que você fizer em outra direção é um desperdício, e que o momento que a gente está dizendo que estamos agora, não paga mais. E aí bom, ainda ficou pouco prático assim, ficou muito teórico ainda, aí foi que o Davi Gomes trouxe um outro insight, que é totalmente nessa linha, que aí ficou bem prático. Conversando com ele, ele está hoje atuando em time de um dos nossos clientes que deu esses steps em DevOps, automatizou todo o fluxo de entrega e para fazer uma publicação era um botãozinho mesmo que tinha que se apertar. E o time não ganhava produtividade de forma nenhuma, e o cliente reclamava, reclamava, que a gente não conseguia entregar, fazia muito e entregava-se pouco. E aí o Davi chegou e tomou esse tempo para ajudar a mapear o fluxo de entrega, quando mapeou o fluxo de entrega aí a segunda coisa foi entender onde é que estava a principal restrição ou a principal falha, ponto de falha. E aí ele descobriu a seguinte coisa: a principal dificuldade não era no processo de publicação deles, que era manual, e aí depois que automatizou resolveu todos os problemas. A principal falha é que eles não tinham uma expertise muito grande de como retornar o produto no estado anterior para o caso de uma entrega falha, um rollback, mero rollback. Esse time não tinha como fazer rollbacks seguros. E aí o que é que acontecia, a infra, o time de segurança punha impedimentos, porque se você tem medo do que é que pode acontecer se você publicar algo falho, você acaba por evitando publicar. Então a primeira coisa que ele fez não foi revisar toda a estrutura de DevOps, o pipeline, foi melhorar a automação do processo de rollback, do processo de voltar algo que foi entregue errado. Olha que maluquice, não é? Quer dizer, então o que gerou mais valor e depois destravou o time para poder realmente automatizar todo o ciclo de delivery contínuo foi, na verdade, tratar bem o erro, quando você erra, é te habilitar a errar melhor ou pelo menos não ter medo de errar. Então nesse caso, quando eu agora instanciei aí a situação que o Davi Gomes passou, fazendo analogia com o que o Pablo colaborou, de conhecer tão bem o seu fluxo e conhecer o ponto de falha, e trabalhar primeiro no ponto de falha, o f*cking first step é no ponto de falha. Para o caso que o Davi trouxe o ponto de falha estava justamente em quando você publicava algo errado e precisava de fazer um rollback para fazer a segurança de ter mais segurança para entregar com mais frequência. Então corrigindo esse ponto, ele habitou o continuous delivery fluir para os próximos steps da pipeline e tudo mais. Então o f*cking first step nesse caso dele foi automatizar o erro, o que fazer quando errar.
Pedro Rangel: Tem um negócio legal assim que é muito fácil, a gente fala assim: “DevOps e continuous delivery, é muito fácil a gente acreditar que ferramentas vão resolver alguns problemas”, e de fato elas facilitam, elas auxiliam, mas na definição mesmo da nomenclatura, DevOps não é um conjunto de artefatos e ferramentas. DevOps é uma cultura organizacional que você implanta, é um conjunto de mudanças de processos e práticas que você tem. E, consequentemente, quando a gente vai falar de mudança escultural, mudança de processos e práticas você vai se esbarrar em time, em interações entre times. Então eu gosto muito de dar exemplo. Assim, quando a gente tinha empresas muito que era setorizadas assim, eu vou falar, a gente tinha lá da área de banco de dados, quem criava banco de dados era uma área de banco de dados. Como que você faz times saírem de um… que você vai falar, interação entre duas células, você pode ter uma interação, por exemplo: eu sou um squad de desenvolvimento que eu preciso consumir banco de dados. Se eu estou falando que banco de dados é uma área, é um setor, eu posso ter uma interação de colaboração. Eu preciso ir lá, marcar uma reunião, conversar com ele e falar assim: “Cara, como que eu vou fazer para criar tal coisa no banco de dados?”. É uma interação de colaboração e ela tem um custo, que você tem que parar uma estrutura A, uma estrutura B para poder fazer isso. Você também pode ter um tipo de interação entre duas células, vamos falar assim, uma interação de facilitação. Você pode ter um rapaz ali no meio que ele vai perguntar: “Time de desenvolvimento, o que você precisa? Time de banco de dados, como que eu posso fazer isso aqui?”, vai ter alguém facilitando ali no meio. E o Santo Graal, que é economia de desperdício, é (inint) [00:24:47], que você tem princípios bem declarados, regras bem claras do jogo, e que você tem o outro time que consome esses princípios e regras e sabe, por exemplo, que ele tem que criar o banco normalizado dessa maneira X, Y e Z. Então não vai ser só uma mudança de um conjunto de ferramentas, mas nesse caso, por exemplo, que eu estou tentando citar aqui como se fosse uma área de banco de dados que está passando por uma mudança na empresa, de DevOps, ele está mudando também o mecanismo de controle. Porque, assim, “Então a partir de agora cada um cria o seu do jeito que está”. Não, não necessariamente. A gente sabe que controles de qualidade, que são os famosos gate keeper ali, são essenciais para a gente manter boa qualidade de entrega de um produto, cheques de inspeção ao longo desse fluxo, que a gente está falando que não é só no desenvolvimento, na escrita do código. Então quando você vai nesse fluxo expandido você começa a colocar esses gate keepers mais como serviço do que como colaboração, que você tem que entrar lá, garantir que aquilo está feito daquele jeito, que eu preciso de uma interação manual. Como que a gente faz aquilo ficar mais declarado, mais consumível, palatável e que aquilo seja entregue com autonomia, com menos restrição ou que essa restrição esteja declarada, facilmente acessível para ser entregue? Essa é uma coisa que a gente tem que refletir, que muda muito quando a gente vai falar de DevOps, DevOps como cultura. Então a gente está falando não só de ferramentas e controle, mas a gente está falando também de facilitação entre essas estruturas, essas células, esses squads, vamos falar assim, que estão espalhados ao longo das companhias.
Diulia Almada: Caramba. Dá para poder ficar aqui, assim, fazer dois episódios, cinco episódios.
Felipe Silveira: Eu falei com o Pablo. Assim, isso que eu trouxe aqui representando o que ele colaborou comigo, eu falei com ele assim: “Cara, isso tudo que você me falou, e eu condensei aqui na minha fala, daria para fazer uns três episódios super interessantes.
Pedro Rangel: A gente vai ser obrigado a fazer um cross over com o entre chaves e convidar essa turma aí para falar um pouco mais.
Diulia Almada: Exatamente. E existem tendências, não só tendências no sentido de tecnologias avançando, mas também da evolução das disciplinas em todos os pilares que a gente traz aqui na DTI. Então não daria para a gente poder falar de todas as tendências, de todos os cenários, por isso a gente vai ter alguns episódios agora na sequência falando justamente sobre as tendências das disciplinas que a gente tem por aqui. E eu queria agradecer o Hammer, agradecer o Felipão pelo episódio. Foi muito legal, muito bom ter vocês aqui ainda mais num primeiro episódio de 2023.
Pedro Rangel: Ótimos convidados para nossa estreia.
Diulia Almada: Exatamente.
Pedro Rangel: Sim, com certeza.
Felipe Silveira: É um prazer. Eu acho que isso aí que você acabou de falar eu acho que vai trazer muito valor aí para Os Agilistas, sabe? Eu acho que a gente inaugurou aí com o f*cking first step nesse novo ano de Os Agilistas. Tentamos trazer aqui um pouco de coisas na prática, você falando de DevOps, mas você foi perfeita. Eu acho que existe o f*cking first step em várias áreas de conhecimento, produto, engenharia, então vocês têm aí um roadmap aí de episódios que podem auxiliar bastante os nossos ouvintes. E foi um prazer participar aí da nova fase de Os Agilistas.
Hammer Lage: Falando de revoluções ao longo da história, eu acho que a gente está passando por mais uma revolução. E geralmente revoluções elas acontecem, é muito fácil de acontecer depois de eventos que marcam, que marcam e vivem ali. E a gente acabou de passar por um evento que foi assim de realmente quebrar alguns paradigmas e está acontecendo uma nova revolução da tecnologia, e a gente está se aproximando de criar novos princípios, criar novas regras e aprender também o que é esse desafio que foi uma pandemia, o que é esse desafio de um mundo novo que a gente está vivendo, que vai ter que pagar a conta do que foi consumido, onde que a gente quer chegar nesse próximo passo. Então, assim, é a revolução da nossa estratégia de entrega em qualquer âmbito que seja ela, em qualquer um dos pilares.
Diulia Almada: Bom, é isso. Tem muita coisa para ser dita ainda.
Pedro Rangel: Sim, com certeza. Lembrando aí, só se puder deixar um pensando aí que retoma o episódio anterior, lembrar que the f*cking first step não é sobre dar só esse primeiro passo, e nem que esse primeiro passo seja perfeito, mas que a gente consiga extrair algum aprendizado dele e daí poder planejar o que vem pela frente.
Felipe Silveira: Principalmente sair da inércia e não se paralisar, não é?
Pedro Rangel: Isso.
Diulia Almada: Bom, é isso.
Hammer Lage: Obrigado estar aqui de novo, colaborar com vocês.
Pedro Rangel: A gente vai te chamar de volta, com certeza.
Felipe Silveira: Valeu, pessoal. Valeu.
Hammer Lage: É um prazer. Valeu, pessoal.
Pedro Rangel: Até mais.
Diulia Almada: Valeu, gente.
